EU AI Act Article 10 — Data and Data Governance

What Article 10 actually requires

Article 10 of Regulation (EU) 2024/1689 sets quality and governance obligations for the training, validation and testing data sets used to develop high-risk AI systems. It applies to all data-driven high-risk systems — and in practice, most are.

Reg text — Article 10(2): "Training, validation and testing data sets shall be subject to data governance and management practices appropriate for the intended purpose of the high-risk AI system."

The term "data governance" carries weight here. Article 10 does not just want clean data — it wants documented, defensible, group-aware decisions about how the data was collected, processed, split, and validated.

The eight Article 10(2) practices

Article 10(2) lists data-governance practices that are appropriate to the intended purpose. The full list (paraphrased; consult the consolidated text for the normative wording):

• (a) Relevant design choices (e.g., the targets the data is meant to support).
• (b) Data collection processes and origin; for personal data, the original purpose of the collection.
• (c) Relevant data preparation processing operations: annotation, labelling, cleaning, updating, enrichment, aggregation.
• (d) Formulation of relevant assumptions, particularly with respect to what the data is supposed to measure and represent.
• (e) An assessment of the availability, quantity and suitability of the data sets that are needed.
• (f) Examination of possible biases that are likely to affect the health and safety of natural persons, have a negative impact on fundamental rights, or lead to discrimination prohibited under EU law, especially where data outputs influence inputs for future operations.
• (g) Appropriate measures to detect, prevent and mitigate possible biases identified under point (f).
• (h) Identification of relevant data gaps or shortcomings that prevent compliance with the Regulation, and how those gaps can be addressed.

Article 10(3) — the data quality criteria

Article 10(3) requires that training, validation and testing data sets are relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose. They must have the appropriate statistical properties, including, where applicable, as regards the persons or groups of persons in relation to whom the high-risk system is intended to be used.

Two phrases to underline: "sufficiently representative" and "as regards the persons or groups." The Regulation does not require perfectly representative data. It requires sufficient representativeness for the intended persons and groups. The bar is operational, not theoretical.

Article 10(4) — context awareness

Article 10(4) requires consideration, to the extent required by the intended purpose, of the characteristics or elements particular to the specific geographical, contextual, behavioural or functional setting in which the system is intended to be used.

A medical-imaging model trained on US patient data and deployed in an EU paediatric hospital is in scope of Article 10(4): demographic distributions differ, imaging-protocol variants differ, equipment models differ. The provider must address these context-specific factors — through retraining, calibration, or explicit documentation that limits the deployable scope.

Article 10(5) — the special-category derogation

Article 10(5) is one of the most-asked-about paragraphs. To the extent strictly necessary to ensure bias detection and correction in high-risk AI systems, providers may process special categories of personal data (Article 9 GDPR — race, health, sexual orientation, etc.).

The derogation has strict conditions:

• Bias detection and correction cannot effectively be fulfilled by processing other data, including synthetic or anonymised data.
• The data is subject to appropriate safeguards (technical limitations on re-use, state-of-the-art security and privacy-preserving measures including pseudonymisation).
• The data is subject to measures ensuring it is secured, protected, and only authorised persons can access it.
• The data is not transmitted, transferred, or otherwise accessed by other parties.
• The data is deleted once the bias has been corrected or the personal data has reached the end of its retention period, whichever comes first.
• Documentation includes the reasons why processing of special categories was strictly necessary to detect and correct biases.

Practically: if you process special-category data under Article 10(5), you owe a documented justification, retention timeline, security measures, and deletion record. This is not a free pass on GDPR — it is a permission carved within strict bounds.

Who is covered

Article 10 is a provider obligation. A deployer who provides input data is covered by Article 26(4) (deployer-controlled input data must be relevant and representative) but does not owe full Article 10 governance. A deployer who fine-tunes the model on their own data is, under Article 25, likely to be a provider for that fine-tuned variant — and inherits Article 10.

GPAI model providers operate under a parallel regime in Article 53 + Annex XI (training data summary) but a high-risk system that integrates a GPAI model still owes Article 10 at the integrated-system level.

What to do — the data documentation

A defensible Article 10 evidence pack contains:

1. Data sheets (one per training, validation, test set) describing source, collection process, license/legal basis, demographic distribution, known biases, error rates, completeness.
2. Data lineage diagram — source → ingestion → cleaning → labelling → split → training. With version-control identifiers per stage.
3. Bias examination report — per protected attribute (where lawful to identify), per intended-use sub-group: representativeness analysis, statistical-parity / equal-opportunity / calibration-by-group metrics, hot-spot analysis.
4. Bias mitigation log — for every bias identified, the mitigation tried (re-balancing, re-weighting, threshold adjustment, post-processing, model architecture change), with before/after metrics.
5. Article 10(5) justification dossier if special-category data is processed — the strict-necessity argument, the safeguards, the deletion timeline.
6. Article 10(4) context analysis — how the deployment context differs from the training context, and what was done about the gap.

A worked example

A Spanish HR-tech vendor builds a CV-screening model (Annex III §4(a)) trained on 380,000 anonymised CVs collected with employer consent over 2022–2025. Their Article 10 evidence pack includes:

• A data sheet documenting the 380K corpus: 67% male / 33% female, 72% Spanish nationals / 28% other EU, age distribution, sector distribution.
• A bias examination showing a 4.1pp lower shortlist rate for women in tech roles, after correcting for years-of-experience.
• A mitigation: re-weighting under-represented groups in the loss function, after which the gap drops to 1.3pp. They document this is an Article 10(2)(g) mitigation under "post-training calibration."
• A residual-risk note: 1.3pp gap remains; flagged as a row in the Article 9 register; deployers are warned via Article 13 instructions for use; quarterly re-validation.
• A context analysis: model is not validated for deployment outside Spain or for non-Spanish-language CVs; instructions for use restrict the deployable scope accordingly.

What regulators look at first

1. The data sheets. No data sheets, no Article 10 compliance — full stop.
2. The bias examination by sub-group. Article 15(3) requires accuracy reported across groups, and Article 10(2)(f) requires examination of biases. Show the metrics.
3. The Article 10(5) dossier if you process special-category data. The strict-necessity test is exacting.
4. The Article 10(4) context analysis for any deployment outside the training context.

Inline crosswalk to ISO 42001 and NIST AI RMF

• ISO/IEC 42001:2023 Annex A.7.4 — Quality of data for AI systems. Article 10(3) error-rate, completeness and representativeness criteria.
• ISO/IEC 42001:2023 Annex A.7.5 — Data acquisition and preparation. Bias detection per protected attribute.
• ISO/IEC 42001:2023 Annex A.7.6 — Data provenance. End-to-end source-to-training data lineage.
• NIST AI RMF MEASURE 2.2 — Evaluations involving human subjects meet applicable requirements; representativeness of data is examined.
• NIST AI RMF MEASURE 2.11 — Fairness and bias as identified in the MAP function are evaluated and results are documented.
• NIST AI RMF MAP 2.3 — Scientific integrity and TEVV considerations are identified and documented, including data and modelling approach.

Penalties

Article 99(4) sets non-compliance with Article 10 at up to €15 million or 3% of worldwide annual turnover. Note that Article 10 violations are also frequently dual-tracked with GDPR violations under Article 83 of GDPR — a poorly-justified Article 10(5) special-category processing can attract both AI Act and GDPR enforcement.

Common mistakes

1. No data sheets. The single most common Article 10 failure.
2. "We didn't have time to check for bias." Article 10(2)(f) is mandatory.
3. Article 10(5) used as a blanket permission. It is not; it is a strict-necessity carve-out with deletion duties.
4. Ignoring Article 10(4) context. Deploying a model trained in one jurisdiction into another without context analysis is a documented failure.
5. Missing data lineage. Reproducibility under Article 74 inspection requires it.

Internal links

• Annex IV §2(d) — data documentation for the technical-file rendering of Article 10 evidence.
• Article 9 risk management for how identified biases enter the risk register.
• Article 15 accuracy for the disaggregated metrics that complete the bias picture.

---

Disclaimer. This page is a reference summary of EU AI Act Article 10. It is not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text quoted from the Official Journal version of Regulation (EU) 2024/1689.