Article 10 is the part of the EU AI Act that turns "we train on good data" from a claim into an evidence problem. Providers of high-risk AI systems must show, not assert, where training, validation, and testing data came from, what was done to it, and how bias was examined. This guide maps each duty in the article to engineering artifacts you can generate as a side effect of normal MLOps work, so the audit file builds itself instead of consuming a quarter.
What does Article 10 of the EU AI Act actually require?
Article 10 requires providers of high-risk AI systems to apply documented data-governance practices to training, validation, and testing datasets: recorded design choices, data origin and collection processes, preparation steps such as labelling and cleaning, bias examination and mitigation, and an assessment that the data is relevant, representative, and as error-free and complete as possible for the intended purpose.
Paraphrasing the article (verify the exact text on EUR-Lex before you build controls against it), the governance practices in Article 10(2) must cover:
- ▸Design choices, why this data, for this intended purpose.
- ▸Origin and collection, how each dataset was collected and, for personal data, the original purpose of collection.
- ▸Preparation operations, annotation, labelling, cleaning, updating, enrichment, and aggregation, recorded per dataset.
- ▸Assumptions, what the data is supposed to measure and represent.
- ▸Suitability assessment, availability, quantity, and fit of the datasets.
- ▸Bias examination, biases likely to affect health, safety, or fundamental rights, plus measures to detect, prevent, and mitigate them.
- ▸Gaps and shortcomings, what is missing and how you compensated.
Article 10(3) and 10(4) add that datasets must be relevant, sufficiently representative, and, to the best extent possible, free of errors and complete in view of the intended purpose, with statistical properties appropriate to the persons affected and to the specific geographical, contextual, behavioural, or functional setting where the system will be used. Note the hedge the legislators wrote in: "to the best extent possible". Perfection is not the standard, documented diligence is.
Who is in scope, and when does Article 10 start to apply?
Article 10 binds providers of high-risk AI systems: the Annex III use cases (employment screening, credit scoring, education, access to essential services, and others) and AI safety components of regulated products. The original application date for Annex III systems was 2 August 2026, but the Digital Omnibus package has put parts of that timeline in motion, verify against primary EU sources before committing a roadmap.
Two traps catch engineering teams here:
- ▸You can become a provider without training a model. Fine-tune a foundation model, put your name on a system, or substantially modify one, then use it for an Annex III purpose, provider obligations, including Article 10, can attach to you.
- ▸The deferral debate changes dates, not duties. The Digital Omnibus proposals discussed in late 2025 would link high-risk obligations to the readiness of harmonised standards and could shift application into 2027 or later for some categories. Nothing in that debate rewrites what Article 10 asks for. Teams that pause data-lineage work while waiting for legal certainty are betting they can reconstruct provenance retroactively, usually the most expensive way to obtain it.
For the wider picture of what applies now versus what was deferred, see EU AI Act, August 2026: What Actually Applies Now (and What the Digital Omnibus Deferred).
What counts as data-lineage evidence in practice?
Usable lineage evidence is machine-generated and regenerable: dataset manifests with content hashes, versioned transformation logs, annotation guidelines with reviewer statistics, and run records binding each model version to the exact dataset versions it was trained and evaluated on. A narrative written after the fact, with no way to re-derive it, is weak evidence.
A minimal evidence set per dataset:
- ▸A manifest: dataset ID, version, content hash, source systems, licence or legal basis, collection window, and a named owner.
- ▸A datasheet: the "Datasheets for Datasets" template covers most of the Article 10(2) prose requirements in one structured document.
- ▸A transformation log: every cleaning, labelling, and enrichment step, ideally expressed as code in version control rather than prose.
- ▸Split records: how train, validation, and test sets were derived, plus the leakage checks between them.
- ▸Run linkage: the training and evaluation runs that consumed those versions, with metrics, stored in your experiment tracker.
The test to apply: if an auditor asked "show me the data behind the model currently in production", could you produce all of this within days, from systems, without interviewing whoever left the company last year?
How do you record provenance without a dedicated compliance team?
Choose tools that emit lineage while pipelines run instead of forms filled in afterwards: DVC or lakeFS for dataset versioning, OpenLineage events from Airflow, Dagster, or Spark jobs, dbt lineage for warehouse transforms, Great Expectations or Soda for data-quality assertions, and MLflow or Weights and Biases to bind model runs to dataset hashes.
- ▸Version data like code. DVC and lakeFS give you immutable, hash-addressed dataset versions; Delta Lake or Iceberg time travel works too if you live in a lakehouse.
- ▸Let orchestrators talk. OpenLineage integrations for Airflow, Dagster, and Spark emit provenance events into Marquez or a warehouse table with minimal code.
- ▸Make quality checks assertions. Great Expectations or Soda suites produce timestamped pass-fail artifacts, exactly the examination evidence Article 10 wants, on every pipeline run.
- ▸Bind runs to data. Log the dataset hash as a run parameter in MLflow; the link from deployed model to data version becomes a query, not an archaeology project.
This is the same philosophy we argued in Data Governance Engineers Will Actually Use: governance that lives in the pipeline survives; governance that lives in a wiki decays.
How do you evidence bias examination and mitigation?
Define the cohorts relevant to your context of use, compute fairness metrics, demographic parity difference, equalized odds difference, subgroup error rates, for every dataset and model version, and record both the findings and the mitigation decisions taken. The evidence is the versioned report plus the decision log, regenerated automatically, not a one-time PDF.
Practically:
- ▸Wire Fairlearn or AIF360 into the evaluation pipeline so per-cohort metrics are computed on every candidate model, not on request.
- ▸Keep a mitigation decision log: what the analysis found, which options were weighed (reweighting, threshold adjustment, data collection), what shipped, and why.
- ▸Article 10(5) narrowly permits processing special categories of personal data (health, ethnicity, and similar) strictly where necessary for bias detection and correction, under conditions including security safeguards, access restriction, and deletion once the purpose is served. GDPR Article 9 applies in parallel, treat this as a legal review item with your DPO, never as an engineering default.
How does Article 10 interact with the GDPR work you already did?
Article 10 layers on top of the GDPR rather than replacing it: legal basis, purpose limitation, minimization, and DPIA duties still govern any personal data in training sets. The efficient pattern is one dataset inventory serving both regimes, your ROPA entries, DPIA references, and AI Act lineage should all point at the same dataset versions.
Where a record of processing names a dataset, name the version. Where a DPIA assesses training-data risk, reference the manifest hash it assessed. When a subject-rights request or a regulator question arrives, both trails resolve to the same artifact instead of two contradicting spreadsheets. Our guide Privacy Engineering in 2026: Data Minimization, Consent, and Cross-Border Data covers the GDPR side of the same datasets.
What will an auditor or market-surveillance authority ask for first?
Expect a request to produce the data-governance section of your Annex IV technical documentation on short notice: the dataset inventory with versions and origins, the bias analyses tied to those versions, quality-assertion results, and proof that the model in production traces to exactly those datasets. Teams that have rehearsed the export answer in days; teams that have not, in months.
Rehearse it like a restore drill: once a quarter, run the export end to end and have someone who did not build the pipeline check that the story holds together. For models and datasets you did not build, the equivalent questions flow up your supply chain, that is AIBOM territory, covered in Securing the AI Supply Chain: AIBOM, Provenance, and Model Governance.
How TuniCyberLabs helps
TuniCyberLabs builds the pipelines that make Article 10 a by-product of engineering rather than a documentation project: dataset versioning and lineage capture wired into your existing orchestrators, fairness evaluation in CI, and a technical-documentation export you can run on demand. We run gap assessments against your actual stack, not a policy template, for teams shipping high-risk AI into the EU. If a regulator-ready data-lineage trail is on your backlog, talk to our engineers.