Data before models. Most AI pilots fail on ownership, not accuracy.
Control what you can control: the data, not the model.
The model is the part of an AI system that changes fastest and that you control least. A provider ships a new version; an open model is superseded within months. The data is the opposite. Which sources count, who owns them, who may see them and how long they are kept are decisions your organization makes and lives with.
That is also the part most pilots skip. A prototype is built on a folder someone exported, it works on the demo, and the questions of ownership arrive only when the system is about to be used for real. This guide sets out the data work that should come first.
Four classes, as a design heuristic.
Sorting data into four classes makes design conversations faster. It is a design heuristic, not a legal classification: "personal data" has a precise legal meaning under the GDPR, and "restricted" here simply means constrained by contract, secrecy or a sector rule.
| Class | Examples | Default handling in an AI design |
|---|---|---|
| Public | Published reports, public registers, your own website. | Few constraints. Check licensing and accuracy. |
| Internal | Procedures, templates, internal reports without personal data. | Access limited to staff; provider terms checked for training use and retention. |
| Personal | CVs, customer files, emails, anything relating to an identifiable person. | Legal basis, minimization, processor agreement, impact screening, retention set by purpose. |
| Restricted | Material under NDA, trade secrets, specially regulated records. | Read the constraint itself before any design. Often excluded from scope at first. |
Classes overlap. An internal procedure may quote a named case. Classify a document by its most sensitive element, or split it.
Nine facts for every source.
Before a source is connected to anything, record:
- Its owner: the person who decides what it contains and answers for it.
- Where it lives: system, folder, database.
- Format and structure.
- Volume and rate of change.
- Data class.
- Constraints: legal basis, contract terms, sector rules.
- Known quality issues: duplicates, outdated versions, gaps.
- Who may access it today.
- Retention: how long it is kept, and why.
Quality means fitness for the task, not perfection. For retrieval, the main problems are duplicates and superseded versions that compete with the current one. For extraction, it is whether the sample covers the real variety of layouts. For evaluation, it is whether the labelled cases include the hard ones.
Inference, retrieval, training, evaluation: four jobs, four rule sets.
"The data for the AI project" usually means four different things, each with its own risks.
Data before models · Datasets
One set of sources, four datasets with different jobs.
Scroll the diagram sideways to see all of it.
Read the diagram as text
- Sources are inventoried first: owner, location, data class, quality and retention for each.
- The retrieval corpus is a curated, versioned and permission-aware selection of documents, indexed for search.
- Inference inputs are the fields sent to the model with each request, reduced to what the task needs.
- The evaluation set is a held-out collection of labelled cases, rerun at every change to prompts, models, rules or the index.
- Training or fine-tuning data is rarely needed and carries the strictest controls when it is.
- Corrections made by reviewers during live use become new labelled cases in the evaluation set.
Inference inputs are what the model sees at run time: the fields of this invoice, this request. They should be minimized, because they leave your application on every call. The retrieval corpus is the curated document set a search step draws from; it needs versioning and permission filtering. Training or fine-tuning data changes the model itself, is rarely needed for SME workflows, and is the hardest to undo. The evaluation set is a held-out collection of labelled cases used to measure the system at every change. It is the one dataset almost every project needs and almost none budgets for.
An index must not become a way around permissions.
A retrieval system that indexes every shared drive can answer questions with passages the person asking was never allowed to open. Retrieval must filter by the permissions of the user, not of the service account that built the index. Test it with real test users before launch.
Minimal access also applies to the model. Send the fields the task needs. An extraction step needs the invoice, not the supplier's bank history. A drafting assistant needs the case summary, not the full customer file. Minimization is cheaper to design in than to retrofit, and it shrinks every other risk in this guide.
Every dataset needs a named owner.
For each source and each of the four datasets, name an owner who decides what goes in, approves updates, removes what is obsolete and answers for quality. Set retention by purpose: inference logs needed for audit for one period, evaluation sets for as long as the system runs, nothing kept "just in case". Data protection authorities such as the CNIL treat purpose limitation and storage limitation as design requirements for AI systems, not as afterthoughts.
Human review closes the loop. Review the corpus before launch. Review a sample of outputs every week at first. Store every reviewer correction, because each one is a free, labelled test case.
The model answered faithfully. The data had no owner.
Illustrative
A synthetic but familiar story. A company launches an internal assistant that answers staff questions about policies. The demo is impressive. In week three, an employee is told the old travel allowance; the current policy sat in a different folder, and both were indexed. Human resources says the assistant belongs to IT. IT says the content belongs to human resources. Nobody removes the outdated file, because nobody is sure who is allowed to. Staff stop trusting the answers, and usage falls away.
Nothing about the model changed, and nothing was wrong with it. It answered from what it was given. The fix was never a better model. It was a content owner, a single source of truth per policy, versioning, a removal process and a feedback button that reaches someone.
What this guide does not do.
- The four classes are a working heuristic and do not replace a legal analysis of your data.
- It does not cover model training at scale, which raises questions beyond the scope of most SME projects.
- It does not set retention periods; those depend on your purposes and obligations.
- CNILIntelligence artificielle : le guide. Guidance on personal data in AI systems: purpose, legal basis, minimization, retention and the rights of the people concerned.
- NISTAI Risk Management Framework, AI RMF 1.0, released 26 January 2023. Its Map function covers the context, data and intended use that this guide treats as prerequisites.
Engineer with a doctorate in IT and systems from Sorbonne University. Leads the Applied AI practice. Full profile.