If your AI system is classified as high-risk under the EU AI Act, you must document your training data. This is not a formality — the Act requires documentation sufficient to demonstrate that your data is relevant, representative, accurate, and evaluated for bias. Without it, you cannot pass a conformity assessment.
This guide explains what the AI Act requires for training data documentation, why it matters, and how to build a documentation process that will hold up to scrutiny.
Why Training Data Documentation Is a Legal Requirement
Article 10 of the EU AI Act sets mandatory data governance requirements for high-risk AI systems. The requirement exists because the quality and composition of training data is one of the most significant drivers of AI failure — including discriminatory outcomes, poor accuracy on underrepresented groups, and systemic errors.
Data documentation serves three purposes under the Act:
- Conformity assessment — you cannot self-certify a high-risk system without demonstrating data governance
- Post-deployment accountability — if a system causes harm, regulators will request training data provenance
- Ongoing monitoring — data drift and distribution shift must be tracked; documentation is the baseline
What the AI Act Requires You to Document
Article 10 requires that training, validation, and testing datasets:
1. Are Relevant to the Intended Purpose
Your data must be appropriate for the task. If you train a job applicant ranking model, the training data must reflect the actual hiring context — not a different job market, industry, or time period that does not apply to your use case.
Document: The source of training data, why it was selected, and its relevance to the intended deployment context.
2. Are Sufficiently Representative
The dataset must represent the diversity of the population the AI system will be used on. For HR AI, this means demographic diversity. For credit scoring AI, this means diversity across income levels, geographic regions, and customer profiles. For medical AI, it means diversity across age, gender, ethnicity, and clinical presentations.
Underrepresentation leads to models that perform poorly on groups not well-represented in training data — often the groups most vulnerable to harm.
Document: The demographic and contextual composition of your training data. If gaps exist, document them and describe how you've mitigated the risk.
3. Are Free from Errors and Biases (as much as reasonably possible)
You must evaluate your training data for errors, noise, and biases — particularly those that could lead to discriminatory outcomes when the AI is applied to protected characteristics.
Document: Your bias evaluation methodology, the bias metrics you assessed, what you found, and what corrections or mitigations you applied.
4. Have Appropriate Provenance
Where did the data come from? Is it collected lawfully? If it includes personal data, what is the GDPR lawful basis for processing it as training data?
Document: Data sources, collection methods, any data licensing agreements, and GDPR lawful basis for any personal data in your training set.
5. Have Been Prepared Appropriately
Preprocessing steps — labelling, anonymisation, sampling, augmentation, balancing — must be documented. How your raw data was transformed into training data affects model behaviour and must be reproducible.
Document: Every preprocessing step, the tools used, the decisions made, and why.
Training Data Documentation Template
For each dataset used in training, validation, or testing:
Dataset name: [name or reference]
Version: [version or date]
Source:
- Origin: [where data was collected or procured]
- Collection method: [how it was gathered]
- Collection period: [dates]
- Licensing / legal basis: [GDPR lawful basis if personal data; licence if third-party]
Relevance:
- Intended use: [the AI system this data trains]
- Why this dataset is appropriate: [justification]
- Geographic scope: [regions represented]
- Time period: [whether data is current for the intended use]
Representativeness:
- Population the system will be used on: [describe]
- Coverage of that population: [how well does data represent it]
- Known gaps: [groups underrepresented or absent]
- Mitigation for gaps: [oversampling, synthetic data, limitations noted]
Bias evaluation:
- Bias metrics assessed: [e.g. demographic parity, equalised odds]
- Protected characteristics evaluated: [gender, ethnicity, age, etc.]
- Findings: [what was identified]
- Mitigations applied: [reweighting, resampling, exclusions, etc.]
Data quality:
- Error rate: [label noise or annotation error rate if applicable]
- Quality controls applied: [validation steps, human review]
Preprocessing:
- Steps applied: [normalization, deduplication, augmentation, anonymisation]
- Tools used: [libraries, platforms]
- Decisions made and rationale: [any non-standard choices]
Dataset size:
- Total records: [number]
- Train / validation / test split: [percentages]
Personal data:
- Contains personal data: Yes / No
- If yes, GDPR lawful basis: [Article 6 and/or 9 basis]
- Anonymisation applied: [method and residual risk assessment]
Ongoing Data Governance (Not Just at Training Time)
The AI Act's data requirements do not end at training. You must:
Monitor for data drift: The population using your system in production may gradually differ from your training population. If model performance degrades on a segment of users, your training data may no longer be representative.
Retrain responsibly: When you retrain or fine-tune your model, the same documentation requirements apply to the new data. Version control your datasets and maintain documentation for each training run.
Respond to feedback: If users or deployers report that the system performs poorly for certain groups, this is a signal that your training data may have a representativeness problem. Investigate and document your response.
Audit trails: High-risk AI systems require logging sufficient for post-deployment monitoring. This includes tracking model versions against deployment periods so that any future investigation can identify which model version was in use at a given time.
The GDPR Intersection
If your training data includes personal data — likely for most HR, health, or financial AI — GDPR applies to that data. Key considerations:
- Purpose limitation: Data collected for one purpose cannot be reused as training data without a compatible purpose assessment or fresh lawful basis
- Data minimisation: Training data should use the minimum personal data necessary — use anonymised or pseudonymised data where possible
- Special categories: Training an AI on health, biometric, or ethnic data requires explicit consent or another Article 9 basis — and the risks are higher
- Data subject rights: If your training data includes identifiable personal data, data subjects may have rights to access, erasure, or objection that apply to training use
Consult your privacy counsel on the GDPR basis for any personal training data before the system goes to market.
What Regulators Will Look For
If your high-risk AI system is audited by a national market surveillance authority, they will typically request:
- Technical documentation under Article 11 (which includes data documentation)
- Evidence of bias evaluation — not just a statement that it was done
- Provenance of training data — legal basis and source
- Ongoing monitoring records — evidence the system has been monitored since deployment
"We evaluated the data" without documented evidence will not pass scrutiny. The documentation must exist, be complete, and be kept current.