What Article 10 regulates
Article 10 of the AI Act, titled "Data and data governance," requires providers of high-risk AI systems to apply governance and quality management practices to their training, validation and test datasets. This isn't a best-practice recommendation — it's a legal obligation with documentary evidence required during conformity assessment.
The four quality criteria it requires
Article 10 requires that datasets be, to the extent the system's purpose allows, relevant, sufficiently representative, free of errors to the best extent possible, and complete. These four criteria connect directly to the data quality dimensions you should already be measuring in any data quality management program — except here they stop being an internal best practice and become an auditable requirement.
| AI Act criterion | What it requires in practice |
|---|---|
| Relevance | The data used must correspond to the system's actual purpose, not to whatever was easiest to obtain |
| Representativeness | The dataset must reflect the real geographic, behavioral and functional context of deployment, not a sample skewed toward one segment |
| Free of errors | Measurable accuracy thresholds, not a generic claim that "the data is clean" |
| Completeness | Sufficient coverage of the cases and variables needed for the system to work as declared |
An important nuance built into Article 10 itself: these criteria are defined in relation to the system's intended purpose and the generally acknowledged state of the art. There's no single standard for "representativeness" — what's sufficient for one system changes depending on its context of use. A credit-scoring model trained mostly on non-EU data, for example, can fail precisely at representing the socioeconomic patterns of the European market where it's deployed.
Governance of the data preparation process
Beyond the characteristics of the final dataset, Article 10 requires documenting the preparation process itself: relevant design choices, data collection processes and origin, processing operations such as annotation, labeling, cleaning, updating, enrichment and aggregation, and the assumptions made along the way. In other words, it's not enough to deliver a dataset that meets the four criteria — you need to be able to reconstruct the path that led to it.
Bias detection and mitigation
Article 10 requires examining data for possible biases that could affect people's health or safety, negatively impact fundamental rights, or lead to discrimination — especially when a system's outputs feed into future inputs. Where strictly necessary, and with appropriate safeguards, the regulation allows processing special categories of personal data for the sole purpose of detecting and correcting those biases.
This is exactly where the Digital Omnibus introduces a substantive change: the proposal broadens this legal basis, replacing the current Article 10(5), to also let providers and deployers of non-high-risk systems use special categories of data to detect and correct bias, and it softens the "strictly necessary" threshold to simply "necessary." If your organization has been blocked from fairness testing by restrictions on sensitive data, this is the legal path opening up — it's worth building the governed, minimized testing pipeline now rather than waiting for formal adoption.
What companies need to document
- Dataset inventory and provenance: source of each dataset, capture date, owner, and legal basis when personal data is involved.
- Preparation record: which transformations, cleaning and enrichment steps were applied, and who approved them.
- Representativeness evidence: concrete metrics, not claims, about coverage of segments relevant to the system's purpose.
- Bias analysis: methodology used to detect bias, results, and mitigation measures applied.
- Quality thresholds and their justification: why those thresholds are appropriate for the system's purpose and context, not just that they exist.
How this connects to your data quality management program
If you already have a data quality management framework running, with profiling, defined rules and monitored KPIs, most of the Article 10 compliance work is already done. What's usually missing is the traceability layer specific to high-risk systems: linking each training dataset to its bias analysis, its representativeness justification, and its lineage documentation, so an auditor can follow the full thread without depending on someone remembering it.
Common mistakes when justifying it
- Claiming representativeness without metrics to back it up: a statement of intent doesn't survive an audit in 2026.
- Treating bias analysis as a one-off exercise instead of a repeatable process every time the dataset changes.
- Assuming the timeline moving to December 2027 means there's no rush: system classification, inventory and provenance documentation don't depend on technical standards being finalized, and starting early avoids rushed work in the final quarter.
The timeline moved, but the substance of Article 10 didn't: training data quality stopped being a purely technical matter and became a legal requirement with evidence you can be asked to produce. The sooner you connect your data quality work to that documentation layer, the less last-minute work you'll have as the final deadline approaches.