EU AI Act Article 10: what it requires of your training data

Who Article 10 applies to, and from when

Article 10 of Regulation (EU) 2024/1689 sits in Chapter III, Section 2, among the requirements for high-risk AI systems: those listed by use case in Annex III, such as recruitment, credit scoring or education, and those that are safety components of products covered by the legislation in Annex I. The obligation falls on the provider, the organisation that develops the system and places it on the market. Deployers have a narrower duty under Article 26(4): to the extent they control the input data, they must ensure it is “relevant and sufficiently representative in view of the intended purpose”.

The dates moved this year. The Commission proposed the Digital Omnibus on AI in November 2025; after a political agreement on 7 May 2026, according to the Commission’s AI Act page, it was adopted as Regulation (EU) 2026/1744 of 8 July 2026 and entered into force on 27 July 2026. It postponed the high-risk requirements, including Article 10, from their original dates (2 August 2026 for Annex III systems, 2 August 2027 for Annex I products) to the dates below. Those dates are now law, not a proposal.

The table follows Article 113 as amended in the consolidated text published by the Commission’s AI Act Service Desk.

Paragraph by paragraph

The table reads the consolidated Article 10 as published by the Service Desk, with the Omnibus amendments marked there: paragraphs 1 and 6 were replaced, paragraph 5 was deleted and its substance moved to a new Article 4a, and paragraphs 2 to 4 are unchanged. The right-hand column is our suggestion of the record that answers each point; the Regulation does not prescribe the format.

Paragraph 2 is the core. Its eight points describe practices, not outcomes, which means the evidence is a set of documents produced while the data is built, not a certificate issued afterwards.

‘Free of errors and complete’, and representative

Does the AI Act require training data to be error-free? No. Paragraph 3 asks for data sets that are “relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose”. The qualifier carries the weight. It sets an obligation of effort that you can evidence, not a property you could ever prove.

Perfection is not available even to curated benchmarks. Northcutt, Athalye and Mueller estimated an average of at least 3.3% label errors across the test sets of ten widely used datasets, and at least 6% in the ImageNet validation set. The defensible position is a measured error rate: an independent audit of a random sample, the method written down, and the residual rate set against what the intended purpose can tolerate. Completeness can be treated the same way: missing values, missing classes and unlabelled objects, each counted.

The same paragraph asks for appropriate statistical properties, “including, where applicable, as regards the persons or groups of persons” on whom the system will be used, and adds that the characteristics “may be met at the level of individual data sets or at the level of a combination thereof”. A gap in one set can be covered by another, provided the combination is documented.

Paragraph 4 makes representativeness concrete: data must reflect the “geographical, contextual, behavioural or functional setting” of use. That is a real constraint. Celi and colleagues reviewed 7,314 clinical AI papers published in 2019 and, in a hand-tagged sample of 600 of them, found that the United States supplied 40.8% of the datasets and China 13.7%. A model trained on such data and sold into a European hospital needs a written comparison between the population it learned from and the one it will meet.

Annotation and labelling as named operations

Point 2(c) names labelling explicitly: governance must cover “relevant data-preparation processing operations, such as annotation, labelling, cleaning, updating, enrichment and aggregation”. For anyone who builds or buys labelled data, that sentence turns the annotation project into part of the regulated system.

The technical documentation in Annex IV confirms it. Point 2(d) asks for datasheets describing the training data, “information about their provenance, scope and main characteristics”, “how the data was obtained and selected”, and “labelling procedures (e.g. for supervised learning), data cleaning methodologies (e.g. outliers detection)”. A labelling protocol is therefore a document you may be asked for, and the Data Cards framework from Google Research is one published structure for it: its template has a section for annotations, with a sub-section on the human annotators involved.

Outsourcing does not move the obligation. If a vendor labels your data, the provider still needs the records, so the contract should require them as deliverables:

• the guideline, in every version used, with the date each took effect (our annotation guidelines template gives a structure);
• who labelled, with their qualifications and training, and how many people labelled each item;
• agreement statistics on a double-labelled sample, which our Cohen’s kappa calculator computes;
• review and rework rates, the acceptance test applied, and the results of each batch;
• every cleaning, relabelling or filtering step, with the reason, so that the final set can be traced back to the raw data.

Bias examination and special-category data

Points 2(f) and 2(g) require an “examination in view of possible biases that are likely to affect the health and safety of persons”, harm fundamental rights or lead to unlawful discrimination, “especially where data outputs influence inputs for future operations”, and measures to detect, prevent and mitigate what is found. The last clause matters for systems that learn from their own decisions, such as credit or hiring models whose approvals shape the next training set. Our bias audit guide covers the method: describe first, compare with the deployment population rather than with uniformity, and test performance by subgroup.

Checking performance by ethnicity or health status needs that data, which the GDPR restricts. The original Article 10(5) allowed providers to process special categories of personal data for this purpose under conditions; the Omnibus deleted it and moved the exception to Article 4a, which keeps the conditions for providers of high-risk systems, extends a similar exception to other AI systems and to deployers, and adds that this extension “does not create any obligation” to run such checks. The GDPR still applies alongside it; our GDPR and training data piece covers the questions on that side. Under Article 4a(1), processing is allowed only to the extent strictly necessary and only if all of these hold:

• bias detection and correction “cannot be effectively fulfilled by processing other data”, including synthetic or anonymised data;
• re-use of the data is technically limited, with state-of-the-art security and privacy measures such as pseudonymisation;
• access is strictly controlled, documented and limited to authorised people under confidentiality duties;
• the data is not transmitted, transferred or otherwise accessed by other parties;
• it is deleted once the bias has been corrected or its retention period ends, whichever is first;
• the records of processing explain why the special-category data was strictly necessary.

Standards, and the evidence pack

Harmonised standards will define what compliance looks like in practice, because following one gives a presumption of conformity. The Commission’s standardisation request to CEN and CENELEC covers ten areas, “governance and quality of datasets” among them, and CEN-CENELEC JTC 21 is drafting them. The first to be cited, EN 18286 on quality management systems, was referenced by Implementing Decision (EU) 2026/2274 of 12 October 2026. No harmonised standard for dataset governance had been cited when we checked on 31 October 2026.

Until one is, the ISO/IEC 5259 series is the most complete vocabulary: parts 1 to 4, published in 2024 and adopted as European standards in 2025, cover terminology, data quality measures, management requirements and a process framework, and part 5 (2025) a governance framework. They are not harmonised under the AI Act and give no presumption of conformity, but their measures map well onto paragraph 3.

For each dataset, the pack below answers Article 10 point by point. Most of it overlaps with a good provenance record and our dataset card checklist; our free AI Act datasheet tool turns the same fields into a structured document.

1. A register entry: name, version, role (training, validation or test), and the system it feeds.
2. A provenance record: sources, collection method, dates, licences, and the original purpose of any personal data.
3. A preparation log: labelling protocol and guideline versions, annotator details, agreement and QA results, cleaning steps.
4. An assumptions statement: what each label and field is meant to measure, and what it does not.
5. A sufficiency and representativeness assessment: volume, coverage by relevant group and setting, compared with deployment.
6. An error and completeness audit: sampled error rate with its method, and counts of missing data.
7. A bias examination, the mitigations applied, and an Article 4a necessity record if special-category data was used.
8. A gap analysis: known shortcomings, their effect on the intended purpose, and who will close them by when.

Questions people ask