Regulation
Article 10 Data Governance and Proving a Training Set Fits
Article 10 of the EU AI Act requires the training, validation and testing data behind a high-risk AI system to be governed, documented and shown to fit the intended purpose. This guide sets out what the duty actually says, why it lands on the provider rather than the deployer, how a deployer can inherit it by fine-tuning or rebranding, what evidence an assessor expects to see, and where the standards are still unfinished.
The awkward conversation usually starts the same way. A model is already in production and performing well. A customer questionnaire, a notified body, or your own internal audit asks a simple question: where did the training data come from, what does it represent, and how do you know it matches the population the system is used on? The data science team can produce a performance metric. What it often cannot produce is a provenance record for the rows, a statement of what the data was originally collected for, a labelling protocol, or any written analysis of who is under-represented in it. The model was built to work, not to be explained.
Article 10 of the EU AI Act closes that gap by making data governance a legal requirement rather than an engineering nicety. It applies to high-risk AI systems that are developed using techniques involving the training of models, and it demands that the training, validation and testing data sets be subject to governance practices appropriate to the system's intended purpose. Critically, it is not a one-off exercise: the outputs of Article 10 feed the technical documentation under Article 11 and Annex IV, and they are the evidence base an assessor works from.
What Article 10 actually requires
The operative content sits in Article 10(2), which lists the governance and management practices that must be applied. In substance these cover: the relevant design choices; the data collection processes and the origin of the data, including, for personal data, the original purpose of collection; data preparation operations such as annotation, labelling, cleaning, updating, enrichment and aggregation; the assumptions made about what the data is supposed to measure and represent; an assessment of the availability, quantity and suitability of the data sets needed; an examination for possible biases likely to affect health and safety, harm fundamental rights, or lead to prohibited discrimination; measures to detect, prevent and mitigate those biases; and the identification of data gaps or shortcomings, with an account of how they can be addressed.
Article 10(3) then sets the quality bar. Data sets must be relevant, sufficiently representative, and, to the best extent possible, free of errors and complete in view of the intended purpose. They must have appropriate statistical properties, including in relation to the persons or groups the system is intended to be used on. Those characteristics may be met at the level of an individual data set or across a combination of them. Article 10(4) adds the contextual test: data must take account of the geographical, contextual, behavioural or functional setting in which the system will actually be used. A model trained on one national population and deployed in another has a live Article 10(4) problem that no accuracy figure resolves.
One point is frequently missed. Article 10(6) provides that where a high-risk system is developed without techniques involving model training, the requirements still apply, but only to the testing data sets. Rules-based and expert systems do not escape.
Who the duty falls on
Article 10 is a provider obligation. It sits in Chapter III, Section 2, among the requirements for high-risk AI systems, and it is the provider that Article 16 makes responsible for ensuring those requirements are met before the system is placed on the market or put into service. A deployer that buys a compliant high-risk system and runs it as instructed does not owe an Article 10 duty over the vendor's training data. It cannot: it has never seen that data.
What the deployer does owe is the narrower duty in Article 26(4). To the extent a deployer exercises control over the input data, it must ensure that input data is relevant and sufficiently representative in view of the system's intended purpose. That is a real obligation with real bite — it covers the historical records you upload, the reference set you configure, the population you point the system at — but it is a different duty from Article 10, and conflating the two produces both over-engineered deployer programmes and under-engineered provider ones.
The point that catches organisations out is Article 25, which converts a deployer into a provider. You become the provider of a high-risk system, with the full Article 10 burden attaching to it, if you put your own name or trade mark on a high-risk system already on the market, if you make a substantial modification to it such that it remains high-risk, or if you change the intended purpose of a system — including a general-purpose AI system — so that it becomes high-risk. When that happens, the original provider ceases to be the provider of that specific system and is required to cooperate and supply the information and technical access reasonably needed. In practice, that cooperation duty is where the pain lands: you now owe an account of training data you did not create, from a vendor whose commercial instinct is to disclose as little as possible. Settle this in the contract before the fine-tune, not after.
Two boundaries are worth stating plainly. Article 10 does not apply to general-purpose AI models as such; providers of those models have separate obligations, including publishing a sufficiently detailed summary of the content used for training in line with a template from the AI Office. And where a downstream party fine-tunes a general-purpose model, the Act's recitals indicate the resulting obligations are expected to be proportionate to the modification rather than to the whole model — but the operative detail here depends on AI Office guidance, and anyone relying on that proportionality should check the current position rather than assume it.
Special category data for bias testing
You cannot test for bias across protected characteristics without data on protected characteristics. Article 10(5) recognises this and permits providers, exceptionally, to process special categories of personal data strictly for bias detection and correction — but it is a permission under the AI Act, not a lawful basis under the GDPR. You still need an Article 6 basis and an Article 9 condition, and in the UK the corresponding Schedule 1 condition under the Data Protection Act 2018. All of the following must also hold:
- Bias detection and correction cannot effectively be achieved by processing other data, including synthetic or anonymised data — and you can show why.
- Technical limitations are in place on re-use of the data, with state-of-the-art security and privacy-preserving measures, including pseudonymisation.
- Access is strictly controlled and documented, restricted to authorised persons under confidentiality obligations.
- The data is not transmitted, transferred or otherwise accessed by other parties.
- The data is deleted once the bias has been corrected or the retention period ends, whichever comes first.
- Your record of processing activities states why this processing was strictly necessary and why the objective could not be met with other data.
That last condition is the one most often skipped, and it is the cheapest to satisfy. Write the reasoning down at the time you make the decision, not when a regulator asks.
The evidence that satisfies the duty
Article 10 is proved through documentation, principally the technical documentation under Article 11 and Annex IV, which expects a description of the training data sets, their provenance, scope and main characteristics, how data was obtained and selected, labelling procedures and cleaning methodologies. Providers must keep that documentation at the disposal of national competent authorities for ten years after the system is placed on the market or put into service.
| Requirement | Evidence that satisfies it | Typical owner |
|---|---|---|
| Origin and collection purpose | Dataset provenance register: source, licence or contract, collection date, original purpose for any personal data | Data engineering with DPO sign-off |
| Preparation operations | Versioned labelling guideline, annotator instructions and inter-annotator agreement, cleaning and exclusion log | Data science |
| Assumptions and suitability | Written statement of what each feature is assumed to measure, plus the sufficiency assessment for volume and coverage | Model owner |
| Representativeness | Distribution comparison between the training set and the deployment population, by segment and geography | Data science with business owner |
| Bias examination and mitigation | Bias test report naming the groups tested, the metrics used, results, and the mitigation applied or the reason for accepting the result | Risk or model validation |
| Gaps and shortcomings | Register of known data gaps, the residual risk each creates, and the remediation plan | Risk, feeding the Article 9 risk management system |
The limits of this guidance
Three areas remain genuinely unsettled, and it is more useful to say so than to invent certainty. First, timing: under the Act as adopted, the high-risk requirements apply to Annex III systems from 2 August 2026 and to systems that are safety components of products under Annex I from 2 August 2027, but the Commission has proposed changes to that timetable linked to the availability of harmonised standards. Verify the position as finally adopted before planning to a date. Second, the technical detail: harmonised standards under the Act are still being developed by CEN-CENELEC, and until they are cited in the Official Journal there is no presumption of conformity to rely on. In the interim, ISO/IEC 42001 for AI management systems and the ISO/IEC 5259 series on data quality for machine learning are reasonable scaffolding, but they are not a compliance shortcut. Third, thresholds: the Act does not state how representative is representative enough, or which bias metric to use. That judgement is yours to make, document and defend.
Nothing here is legal advice on your specific systems. Take specialist advice where you are considering a fine-tune or rebrand that could make you the provider, where you intend to process special category data for bias testing, where a system may fall inside Annex III but you plan to rely on the Article 6(3) exemption, or where a UK organisation is uncertain whether it is caught at all — the AI Act can reach UK entities that place systems on the EU market or whose system output is used in the Union, while UK-only operations answer instead to UK GDPR, the Equality Act 2010 and sectoral regulators. The stakes justify the advice: non-compliance with the provider requirements can attract administrative fines of up to 3% of global annual turnover, with prohibited practices exposed to up to 7%, and a data governance failure involving personal data can draw a separate GDPR penalty of up to 4% on the same facts.
- EU AI Act
- Article 10
- Data Governance
- High-Risk AI
- Training Data
- Bias Testing