EU AI Act Article 10: Data Governance for High-Risk AI Systems

Article 10 of Regulation (EU) 2024/1689 sets out the data governance obligations that apply to high-risk AI systems trained on data. It covers training, validation, and testing datasets — the quality of the data a model learns from, not the competence of the people who operate it. Staff competence and AI literacy sit in Article 4, which has applied since 2 February 2025. The two are often conflated in compliance planning; they address entirely different obligations.

If your organisation develops or places on the market a high-risk AI system that uses machine learning, Article 10 governs the data decisions made before a single weight is trained. Getting those decisions right — and documenting them — is not optional. The fine ceiling for non-compliance with high-risk requirements is €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99). The deadline for stand-alone Annex III systems, under the Digital Omnibus agreed in May 2026, is 2 December 2027.

---

What Article 10 Actually Regulates

The obligation is precise: high-risk AI systems that are trained with data must use training, validation, and testing datasets that meet specific quality criteria. The Article does not apply to rule-based or deterministic systems that contain no learned parameters — those fall under the other Articles 9–15 obligations without the dataset-specific layer.

For systems that do use learned models, the requirements cluster around six areas:

1. Design choices — document the design decisions that drove dataset selection.
2. Data collection and origin — record where data came from and how it was gathered.
3. Data preparation — document annotation, labelling, cleaning, updating, enrichment, and aggregation.
4. Assumptions — state explicitly what the data is supposed to measure or represent.
5. Availability, quantity, and suitability — assess whether the data is adequate for the intended purpose.
6. Bias examination — identify biases likely to affect health or safety or to cause discrimination, and put in place measures to detect, prevent, and mitigate them.

Across all of these, datasets must be relevant, sufficiently representative, as free of errors as possible, and complete for their intended purpose — taking into account the geographic, contextual, behavioural, and functional setting in which the system will be used (Article 10(3)).

---

Article 10 Is About Data, Not Training People

This distinction matters enough to state plainly. The old compliance guidance in this space frequently confuses Article 10's dataset requirements with the obligation to train staff on AI use. Those are separate:

• Article 4 (AI literacy) requires providers and deployers to take measures to ensure staff have sufficient AI literacy. It applies since 2 February 2025.
• Article 10 (data and data governance) requires that the datasets used to train, validate, and test a high-risk AI system meet quality and governance standards. It is a technical and documentation obligation, not a people-management one.

A company that has fully trained its employees on AI tools but has no documented bias assessment for its recruitment model is not compliant with Article 10. The two obligations do not substitute for each other.

---

The Six Data Governance Requirements in Detail

Relevant design choices (Article 10(2)(a))

Before data collection begins, the design decisions shaping the dataset — what variables to include, what to exclude, what proxy measures to use — must be made consciously and recorded. Regulators examining a model after the fact should be able to trace why the dataset was constructed as it was.

For a credit-scoring model, this means documenting why income was used as a feature, why rental payment history was included or excluded, and why the temporal window covers 2018–2023 rather than a different period. These are not afterthoughts; they shape what the model learns to optimise.

Data collection processes and origin (Article 10(2)(b))

The provenance chain needs to be complete: where did the raw data originate, who collected it, by what method, and under what legal basis? Third-party data sources require licensing records. Public datasets require source documentation and a check on the licence terms. Internal data requires confirmation that the collection was lawful.

This requirement overlaps with GDPR obligations. Where training data includes personal data, the legal basis for collection (Article 6 GDPR) and, for special-category data, the additional condition (Article 9 GDPR) must be documented. Article 10 data governance records and GDPR records should be maintained consistently; inconsistencies will surface in an audit.

Data preparation (Article 10(2)(c))

Every step that transforms raw data into training-ready format must be recorded: annotation instructions and annotator qualifications, labelling methodology, deduplication rules, outlier handling, missing-value imputation strategy, normalisation and scaling decisions, and any data enrichment or aggregation from additional sources.

In practice, this is where most organisations' documentation falls short. The preprocessing pipeline is often treated as an engineering implementation detail rather than a compliance deliverable. Under Article 10 it is both.

Formulation of assumptions (Article 10(2)(d))

What does the data represent? What real-world phenomenon is it a proxy for? These assumptions must be stated explicitly, because a model optimised for a proxy can diverge from the real-world outcome in ways that cause harm.

A recruitment screening model trained on historical hiring decisions does not measure "who will succeed in this role." It measures "who was historically selected, and by whom." If historical hiring was biased, the proxy encodes that bias. Articulating and documenting this assumption is the step that forces honest engagement with what the data can and cannot support.

Assessment of availability, quantity, and suitability (Article 10(2)(e))

The dataset must be adequate for the use case. Inadequacy can arise from size (too few examples of a class), temporal staleness (training on pre-pandemic behaviour for a post-pandemic product), geographic mismatch (training on US data, deploying in Central Europe), or functional mismatch (training on professional-context decisions, deploying in consumer contexts).

This assessment must be documented and revisited when the intended purpose or deployment context changes. A model re-used in a new geography or sector inherits its predecessor's data suitability assessment, which may no longer be valid.

Examination for bias (Article 10(2)(f))

This is the requirement that attracts the most regulatory attention. Providers must identify and examine training, validation, and testing datasets for possible biases that are likely to affect health or safety, or to cause a situation of discrimination prohibited under Union law — in particular discrimination on grounds of race, ethnic origin, colour, sex, language, religion, political opinion, nationality, social origin, property, birth, disability, age, or sexual orientation.

Where such biases are identified, the provider must implement measures to detect, prevent, and mitigate them. "Implemented measures" means documented measures: what was found, what was done about it, and what residual disparity (if any) remains and on what grounds it is considered acceptable.

The Article does not require that all disparity be eliminated — that is often technically impossible. It requires that bias be genuinely examined and that mitigation measures be designed and applied. The documentation of that process is the compliance deliverable.

Identification of data gaps and shortcomings (Article 10(2)(f), continued)

Beyond active bias, providers must identify data gaps and shortcomings and document how these are addressed. A dataset that underrepresents a demographic group has a gap; one that uses inaccurate proxy variables has a shortcoming. Both require documentation and a considered response — whether that response is additional data collection, restricted intended use, or a documented limitation flagged to deployers.

---

Article 10(5): Processing Special-Category Personal Data for Bias Detection

One provision of Article 10 is frequently overlooked. Article 10(5) creates a narrow, conditional permission to process special-category personal data under GDPR Article 9 — including racial or ethnic origin, health data, sexual orientation, and similar categories — strictly for the purpose of detecting and correcting biases in training data.

This permission applies only where:

• processing is strictly necessary for the bias detection purpose;
• appropriate safeguards for the fundamental rights and interests of the data subjects are in place;
• technical limitations on re-use apply;
• state-of-the-art security measures are implemented;
• the data has been anonymised or, where that is not possible, pseudonymised and protected; and
• the data is not transmitted to third parties or used for any other purpose.

This is not a general licence to collect sensitive data. It is a tightly scoped exemption to allow providers to measure demographic disparity in outcomes — which is otherwise difficult to do without the underlying demographic attributes. Using it requires the full GDPR Article 9 governance apparatus (Data Protection Impact Assessment, appropriate legal basis, DPO involvement where required) on top of the Article 10 safeguards.

In practice, a recruitment technology provider that wants to measure whether its model produces different outcomes for candidates of different ethnic backgrounds can, under Article 10(5), process ethnic-origin data for that limited purpose — provided the safeguards are met. It cannot retain or re-use that data for any other purpose.

---

Article 10 and GDPR: Where the Two Regimes Intersect

High-risk AI systems typically train on personal data. That means Article 10 compliance and GDPR compliance run in parallel, and the documentation obligations overlap in ways that can trip up organisations that treat them as separate workstreams.

Legal basis for training. GDPR requires a valid legal basis for every processing activity (GDPR Article 6). Training a model on employee records, customer transactions, or health data is a processing activity. If the original data collection lacked a legal basis adequate for model-training purposes, using that data under Article 10 creates a compounding violation — a GDPR breach embedded in your AI Act compliance pack.

Purpose limitation. GDPR's purpose limitation principle (Article 5(1)(b)) restricts re-use of personal data for purposes incompatible with the original collection purpose. Training a recruitment model on payroll data collected for payroll purposes may fall outside the original purpose. Providers must analyse this before including any data in a training set, and document the analysis. "Compatible purpose" assessments should sit alongside the Article 10 origin documentation.

Data minimisation and retention. GDPR Article 5(1)(c) and (e) require that personal data be adequate, relevant, not excessive, and not retained longer than necessary. Article 10 pulls in the other direction: better representativeness generally means more data over longer time periods. The tension is real. Providers must show they considered minimisation — that the dataset was no larger than necessary for the stated training purpose — and that retention periods for training data align with a documented policy. Destruction schedules for training sets should be specified in the Article 10 origin record.

Data subjects' rights. GDPR grants rights of access, erasure, and objection. A data subject exercising an erasure right after their data has been used to train a model creates a compliance question the Article 10 record must be able to address: was the data deleted from the training set before training, and if not, can it be erased from a deployed model? The answer is usually that it cannot. Document this limitation and the compensating measures — typically anonymisation, differential privacy, or epoch-based training limits — before training begins.

None of these interactions mean that Article 10 and GDPR are redundant with each other. They are parallel frameworks with different purposes, different enforcement bodies (national market surveillance authorities for the AI Act; data protection authorities for GDPR), and different remedies. But a technical file that is silent on GDPR interaction will not satisfy a sophisticated regulator, and for AI systems that process personal data, the two compliance workstreams must be co-designed from the start.

---

Common Compliance Gaps to Fix Before 2027

Most data governance failures under Article 10 are not failures of intent. They are failures of documentation. The data decisions were made — they just were not recorded in a way that survives regulatory scrutiny.

Gap: No written assumption statements. Engineering teams make proxy choices implicitly. The recruitment model that treats "years in role" as a skill signal has made an assumption about what that variable measures; it just was not written down. Regulators expect to find explicit written statements. If they are absent, the inference is that the assumptions were not examined.

Gap: Bias assessment conducted only post-training. Article 10 requires examination of the datasets themselves, not merely of model outputs. A fairness evaluation run on model predictions after the fact does not substitute for a dataset-level bias examination. Both are necessary; only dataset-level examination satisfies Article 10 directly.

Gap: Version control absent for training datasets. When a system is investigated after an incident, the investigating authority will ask which version of the dataset was used to train the deployed model. If the answer is "we do not know" or "we cannot reconstruct it," the investigation starts badly and gets worse. Dataset versioning — tagging each training run with the exact dataset version used — is a basic engineering control that most compliance programmes underestimate.

Gap: Suitability assessment not updated after scope changes. A model trained for use in Germany and later deployed in Romania has a suitability assessment written for German context. Geographic expansion is not a neutral change. A new suitability assessment is required before the expanded deployment, and the Article 10 record must reflect it. Providers often treat deployment expansion as a commercial decision when it is also a compliance decision.

Gap: GDPR and Article 10 documentation maintained separately and inconsistently. A data protection officer who documents a training dataset one way and an engineering team that documents the same dataset differently in the Annex IV file create a discrepancy that will be noticed. Harmonise the records from the start.

---

How Article 10 Connects to the Rest of the High-Risk Framework

Article 10 does not operate in isolation. Its outputs feed directly into three other requirements:

Article 9 (risk management system): Data quality deficiencies are risk inputs. The risk management system must identify foreseeable risks, and poor or biased training data is a foreseeable source of harm. The risk management record should cross-reference the Article 10 bias assessment findings.

Article 11 (technical documentation, Annex IV): Annex IV, section 2 requires the technical file to contain a description of training methodologies, techniques, datasets used, and data governance measures. The Article 10 documentation pack feeds directly into this section of the Annex IV file. If the technical documentation is incomplete, the conformity assessment under Article 43 will fail.

Article 15 (accuracy, robustness, cybersecurity): Data quality is the upstream determinant of model accuracy and performance consistency across subgroups. Poor representativeness or systematic labelling errors will surface as accuracy failures in subpopulations — a risk that Article 15 independently addresses.

A compliance programme that treats Articles 9, 10, 11, and 15 as separate to-do items rather than an integrated system will generate documentation that is internally inconsistent. Regulators read the whole file.

---

Worked Example: Recruitment Model Dataset Review

Consider a 60-person HR-tech company that builds a CV-screening model for use by mid-size employers across the EU. The model is trained on historical hiring records: applications, screening decisions, and subsequent employment outcomes over five years.

The system falls under Annex III, section 4 (employment and workers management), which includes AI used for recruitment and screening of natural persons. Under Article 6, if it influences hiring decisions for individuals, it is high-risk. Article 10 obligations apply from development.

Step 1 — Design choices. The company decides to use job-posting category, years of relevant experience, highest qualification level, and skills keywords as features. It explicitly decides not to use candidate name, graduation institution, or residential postcode — and records why (name and postcode carry proxies for ethnicity and socioeconomic background; graduation institution is a poor proxy for skill in this context). That decision and its rationale is documented.

Step 2 — Origin. Training data comes from five employer clients who provided anonymised historical records under data processing agreements. The agreements specify that data can be used for model development. The legal basis for processing (legitimate interests, with a balancing test) is documented.

Step 3 — Preparation. Annotations were applied by three in-house reviewers using a defined rubric. Inter-annotator agreement (measured by Cohen's kappa) was 0.78, which the company documents as adequate. Duplicate applications, records with missing mandatory fields, and records pre-dating 2019 (company judges earlier data unrepresentative post-COVID restructuring) were removed. All of this is logged.

Step 4 — Assumptions. The company explicitly documents that the training labels ("selected for interview" / "not selected") reflect past human hiring decisions, not ground truth about candidate quality. It notes that this introduces the risk of encoding historical human bias and flags this as the primary bias risk requiring examination.

Step 5 — Suitability assessment. The company reviews demographic composition. Of 40,000 training records, 31% relate to women, 69% to men. This is noted as reflecting the gender distribution of applicants in the historical data for the sectors covered, but the company notes it as a data characteristic to consider in interpreting bias findings.

Step 6 — Bias examination. The company runs disparate impact analysis across gender and age. It finds that female candidates with equivalent experience levels were selected at 0.84× the rate of male candidates. It also finds that candidates over 50 were selected at 0.71× the rate of candidates aged 30–40 with equivalent experience. Both findings are documented. The company removes tenure-based features that correlated with age and re-weights the training set to equalise gender representation. Post-mitigation, the gender ratio improves to 0.97×; the age ratio improves to 0.89×. The residual age disparity is investigated further and attributed to experience-field interactions in job categories with age-skewed applicant pools; the company documents this finding and flags it to deployers as a known limitation requiring human review oversight.

Step 7 — Article 10(5). The company does not have ethnic-origin data in its training records and cannot therefore run an ethnic-origin disparate impact analysis. This gap is documented explicitly, with a note that deployers are advised to conduct their own demographic monitoring in production.

The output of this process — seven documented artefacts — becomes section 2 of the Annex IV technical file and feeds the Article 9 risk management record. The conformity assessment under Article 43 can proceed on this basis.

---

The Provider / Deployer Boundary Under Article 10

Article 10 obligations fall on providers — organisations that develop high-risk AI systems and place them on the market or put them into service under their own name (Article 16). The HR-tech company in the example above is a provider; its employer customers are deployers.

Deployers are not exempt from data-related obligations, but their obligations flow from different Articles. Deployers must follow the provider's instructions (Article 26), ensure human oversight (Article 14 implementation), and monitor operation — but they are not required to re-conduct the provider's Article 10 dataset governance. That burden sits with the provider.

Where the boundary matters is role shift under Article 25. A deployer that substantially modifies a high-risk system, or that trains a base model on its own data for its own purposes, may become a provider and inherit the Article 10 obligations accordingly. The same applies if a deployer changes the intended purpose of a system.

For a company buying a third-party recruitment tool: verify that the vendor has completed Article 10 documentation and can provide an extract of it. That extract feeds your own Article 26 due diligence and your FRIA under Article 27 if your organisation qualifies as a public body or uses the system in a way that triggers a fundamental rights assessment.

---

How Confir Helps

Article 10 compliance generates documentation that must eventually land inside the Annex IV technical file. Confir's AITR compliance area (Data & Technical Robustness, covering Articles 10, 11, and 15) structures the data governance assessment as a series of documented controls: dataset origin and preparation records, bias examination findings, assumption statements, and suitability assessments. Each control maps to a specific Article 10 sub-paragraph so the resulting record is auditable by reference.

The Annex IV documentation pack Confir generates includes a pre-formatted data governance section. Providers fill it in; the output is a print-ready record rather than a blank-page drafting exercise. For deployers, the AITR assessment includes a supplier verification checklist covering what Article 10 evidence to request from the provider.

Article 10 compliance is one piece of the high-risk stack. The full picture — Article 9 risk management, Article 11 technical documentation, Article 14 human oversight, Article 15 accuracy, and Article 43 conformity assessment — runs through the same structured assessment in Confir.

---

Practical Steps for the 2 December 2027 Deadline

The digital Omnibus agreement of May 2026 moved the high-risk Annex III deadline from August 2026 to 2 December 2027 for stand-alone systems. That shift is breathing room for implementation, not a signal to defer. Article 10 documentation is upstream of everything else: you cannot produce a complete Annex IV technical file without it, and you cannot complete a conformity assessment under Article 43 without a complete technical file.

The realistic sequencing:

1. Classify first. Confirm whether your system falls under Annex III via the Article 6 analysis, including the Article 6(3) filter (narrow procedural tasks, no profiling of natural persons, etc.). If it does not, Article 10 dataset obligations do not apply in their full form.

2. Identify the role. Provider, deployer, or a role-shifted deployer under Article 25? The obligation holder changes accordingly.

3. Audit existing datasets. For systems already in development or deployed, trace back through the six Article 10 requirements and document what exists and what is missing.

4. Address the bias examination gap first. This is the most resource-intensive requirement and the one most likely to require re-work of the dataset or the model.

5. Build the Annex IV data section in parallel with the rest of the technical documentation. Do not treat them as sequential phases.

Companies that have not started should start now. The documentation is not short, and the bias assessment requires access to the original training data — which may be harder to retrieve the longer the delay.

---

Related guides

• AI governance compliance platform
• AI system inventory documentation
• AI governance software solutions
• EU AI Act compliance software solutions