EU AI Act Article 10: Data Governance Requirements for Training Data

Cleaning data and governing it answer two different questions, and Article 10 only cares about the second one. A pipeline can deduplicate records, validate formats, and handle missing values — the standard pass most ML teams already run — without ever documenting where the data came from, what it's assumed to represent, or whether anyone actually looked for bias in it. That gap is where Article 10 compliance most often fails: not from bad data, but from an undocumented process wrapped around good-enough data.

What data governance practices Article 10 actually requires

The Act names specific practices that have to apply to training, validation, and testing data sets, proportionate to the system's intended purpose:

Relevant design choices — decisions made about what the data needed to capture and why, documented rather than left implicit in whoever happened to build the pipeline.

Data collection processes and origin, including, for personal data, the original purpose it was collected for — provenance has to be traceable, not assumed.

Relevant data-preparation operations — annotation, labelling, cleaning, updating, enrichment, aggregation — documented as a governed process, not an undocumented series of ad hoc scripts.

The assumptions the data is supposed to represent — what the data is actually meant to measure or stand in for, made explicit rather than left as an unstated premise everyone on the team happens to share until someone new joins and doesn't.

Assessment of availability, quantity, and suitability of the data sets needed for the system's intended purpose — before building on top of them, not discovered as a gap after the system underperforms in production.

Examination for possible bias likely to affect health, safety, or fundamental rights, or to lead to discrimination prohibited under EU law — with particular attention to systems where outputs can feed back into future training data, compounding an initial bias.

Detection, prevention, and mitigation measures for whatever biases that examination actually surfaces.

Identification of data gaps and shortcomings, and how they're being addressed — an honest account of what the data doesn't cover, not a document that only describes what it does.

It applies separately to training, validation, and testing data

This is a detail worth being explicit about: the governance obligation runs across all three data sets, not just the training set. Validation and testing data exist specifically to catch problems the training process introduces — and a testing set with the same provenance gaps, the same underrepresented populations, and the same unexamined assumptions as the training set can't do that job. A team that governs its training data carefully and treats validation/testing data as an afterthought has quietly undermined the part of the pipeline whose entire purpose is independent verification.

The bias-examination requirement, concretely

"Examine for possible biases" sounds abstract until it's translated into what a real examination actually produces. A generic disclaimer — "the model may reflect biases present in the training data" — is not an examination; it's a hedge. A documented examination looks more like: a breakdown of the data's demographic or contextual composition relative to the population the system will actually be used on, a comparison flagging where that composition diverges meaningfully, specific tests of model behavior across the identified subgroups rather than only aggregate accuracy, and a written record of what was found — including biases that were identified but only partially mitigated, with the reasoning for why. The output is a paper trail showing the question was actually asked and answered, not just gestured at.

The tenant-screening case

Take an AI tool used to screen tenant applications for a property management company. A generic data governance write-up might note the training data came from "historical rental applications" and stop there. Article 10-adequate governance documents where those applications came from geographically and over what time period, whether the historical approval decisions the model learned from were themselves shaped by discriminatory practices the system risks reproducing, whether renters in protected categories are proportionally represented in both the training set and the smaller validation set used to check performance, and what happens for applicant profiles — a specific age range, a specific income structure, a specific geography — that the historical data barely covers. Some of those gaps might be judged acceptable for the system's intended purpose; the requirement isn't that every gap gets closed, but that it was identified, assessed, and written down rather than discovered for the first time when a rejected applicant asks why.

Where this fits with the rest of the high-risk obligations

Article 10 findings aren't a standalone deliverable — they're a direct input into the Article 9 risk management process, which is supposed to evaluate risks including those tied to the data the system was built on, and they get referenced (not fully reproduced) in the technical documentation file Article 11 requires. A data governance write-up that exists only inside the ML team's internal wiki, disconnected from the risk management process and the technical documentation, isn't doing the job Article 10 assigns it — the whole point is that this evidence flows into the rest of the compliance picture, not that it exists in isolation as proof the exercise was performed once.

For the classification step that triggers this and the other high-risk obligations, see how Article 6 high-risk classification actually works.