A generative AI system produces its answers from data, and nearly all of the data an organisation would want it to use was collected years earlier for some other purpose. Whether that data can serve a model depends upon a small number of properties, some describing the data itself and some describing the organisation's access to it. The Generative AI Leader exam treats those properties as a business matter, so a question names a data problem and asks what it will cost the project.
The sections below set out the two divisions that classify any dataset, then the six characteristics of data quality the exam guide names, then accessibility and the consent question sitting underneath it, and end with the four questions worth answering before a project starts.
Structured and unstructured data
Structure is a question about schema. Structured data has defined fields with consistent meaning, which covers database tables, transaction records, sensor readings and anything else arranged in rows and columns. Unstructured data has no such schema, which covers documents, email, images, audio, video and free text.
The division matters commercially because most of what an organisation knows is unstructured, and until foundation models arrived that knowledge was largely unusable at any scale. This is where the value in a generative AI project usually sits.
Labelled and unlabelled data
A label is an answer attached to an example. A support ticket tagged with the resolution that closed it is labelled, and the same ticket with nothing attached is unlabelled. Labels are expensive because people have to produce them one at a time, and a supervised learning project spends a large part of its budget there.
Generative AI changed the economics of labelling. A foundation model learns from enormous quantities of unlabelled text, so a task that once required a labelled dataset now often requires only a prompt. Labels still matter for evaluating a model and for fine tuning one, since both need examples whose answers are already known.
The six characteristics of data quality
Labels are one property of a dataset, and the exam guide names six characteristics that describe the rest. Each of the six is a way a dataset can fail the organisation counting on it.
Completeness is whether the fields that matter are filled in. A model cannot reason about what is absent, and gaps concentrated in one group of customers produce a system that works badly for that group alone.
Consistency is whether the same thing is recorded the same way everywhere. Dates in three formats, one customer under two identifiers and a product renamed midway through the archive all make one entity look like several.
Relevance is whether the data describes the situation the organisation is asking about. Five years of records from a market the company has since left is volume without value.
Availability is whether anybody can actually reach the data. A dataset held inside a system with no export path is unavailable whatever it contains.
Cost covers acquisition, storage, movement and the licensing of anything bought in. Cost is a live constraint on retrieval systems in particular, where both storage and embedding scale with the size of the corpus.
Format is whether the data arrives in a shape the tooling can read. A decade of scanned paper is a document processing project before it is an AI one.
An exam question names the symptom and expects the characteristic, so a scenario about one customer appearing under two identifiers is a consistency question and a scenario about scanned paper is a format question.
Accessibility as the real constraint
Availability, cost and format all describe an organisation's access to a dataset, and access stops more projects than quality does. The data exists, and it sits behind a system with no interface, or in a jurisdiction where the model cannot run, or under an agreement that never anticipated this use.
Consent is the access problem that comes up most often. When data collected to run a service is later used to train or ground a model, it is serving a new purpose, and the consent given for the original purpose frequently does not reach that far.
The questions to answer before a generative AI project
Consent, access, relevance and quality all reduce to four questions about the data. A project that cannot answer them is not ready to start.
- Does the data that would answer the question exist at all?
- Is the organisation permitted to use it for this purpose?
- Can the organisation reach it, in the format and the place the system needs?
- Is it consistent enough to be worth reaching?
A team that can answer all four has done the difficult part of a generative AI project. The choice of model, which is where most teams want to begin, is a far smaller decision than any of the four.