EU AI Act Article 10: an engineering checklist.

Article 10 of the EU AI Act is the data-governance clause: if you provide a high-risk AI system that is trained on data, you must run documented data-governance practices covering how your training data was collected, where it came from, how it was prepared, what biases you examined, and what gaps you found. This post translates that legal text into the checklist of records an engineering team actually has to produce.

Two things make this worth reading now. First, most Article 10 explainers restate the law and stop; almost none of them say what to build. Second, the compliance dates just moved. The EU reached final agreement on its Digital Omnibus package in early July 2026, which pushed the main high-risk deadlines back, so much of the published guidance on this topic now shows outdated dates.

One disclaimer before the checklist: we build data-integrity tooling, not legal advice. Read the actual text of Article 10 and talk to your counsel; use this as the engineering map.

Does Article 10 apply to you?

Article 10 binds providers of high-risk AI systems, and nobody else. Not every AI company, not deployers who buy and operate a system, and not general-purpose model providers as such.

A system is high-risk through one of two doors. The first is the product-safety door: your AI is a product, or a safety component of a product, that EU product legislation already requires third-party conformity assessment for. The second is the use-case door: your system falls into the Annex III list, which covers biometrics, critical infrastructure, education, employment and HR screening, credit scoring and access to essential services, law enforcement, migration, and the administration of justice. There is a narrow derogation for Annex III systems that only perform preparatory or procedural tasks, but any system that profiles natural persons stays high-risk regardless.

Two boundary cases cause most of the confusion:

• General-purpose AI models are a different regime. GPAI providers owe the Article 53 obligations, including a “sufficiently detailed summary” of training content. That is a transparency duty. It is not Article 10’s quality, representativeness, and bias regime. If your GPAI model is later placed inside a high-risk system, Article 10 arrives through that system’s provider.
• Only trained systems owe the full article. Article 10 applies to systems “which make use of techniques involving the training of AI models with data.” A high-risk system that is not trained owes the data duties only for its testing data.

The deadlines just moved

The Digital Omnibus package received the Council’s final green light on 29 June 2026 and was signed on 8 July 2026. At the time of writing it awaits publication in the Official Journal. What it changes for Article 10 timing:

• Stand-alone high-risk systems (the Annex III door): 2 December 2027, moved from 2 August 2026.
• Product-embedded high-risk systems (the Annex I door): 2 August 2028.
• These are fixed dates. An earlier proposal tied the delay to the availability of harmonised standards; that conditional mechanism was dropped.

What did not move: the prohibited-practices and AI-literacy rules have applied since 2 February 2025, and the general-purpose model obligations have applied since 2 August 2025.

The penalty frame is worth knowing even with the extra time. Breaching provider obligations, which is the bucket Article 10 non-compliance falls into, carries fines up to 15 million euros or 3 percent of total worldwide annual turnover, whichever is higher, under Article 99. For small and medium-sized enterprises, each cap reads as whichever is lower.

What Article 10 actually requires

The core of the article is 10(2): training, validation, and testing data must be governed by documented practices “appropriate for the intended purpose.” The article then lists what those practices must cover. In plain terms:

• (a) Design choices. Record the relevant design decisions about your data.
• (b) Origin. Record the data collection processes and the origin of the data, and for personal data, the original purpose it was collected for.
• (c) Preparation. Record the data-preparation operations: annotation, labelling, cleaning, updating, enrichment, aggregation.
• (d) Assumptions. Write down what you assume the data measures and represents.
• (e) Suitability. Assess whether the data you need is available, sufficient in quantity, and suitable.
• (f) Bias examination. Examine the data for biases likely to affect health and safety, negatively impact fundamental rights, or lead to unlawful discrimination.
• (g) Bias mitigation. Take appropriate measures to detect, prevent, and mitigate the biases you found.
• (h) Gaps. Identify data gaps or shortcomings that stand in the way of compliance, and how you will address them.

Then 10(3) sets the quality bar, and it is the most misquoted sentence in the article. The text says data sets shall be “relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose.” Read it carefully: the softening qualifier “to the best extent possible” attaches only to “free of errors and complete.” Relevance and sufficient representativeness are not softened. The law does not demand perfect data; it does demand representative data, judged against your intended purpose.

10(4) adds that data must fit the deployment context: the “geographical, contextual, behavioural or functional setting” the system is intended for, to the extent the purpose requires. A model trained on one region’s data and deployed in another is exactly what this paragraph exists for.

10(5) is a narrow and interesting exception: providers may “exceptionally process special categories of personal data” (the GDPR-sensitive categories) when that is “strictly necessary” for detecting and correcting bias. The price is six cumulative safeguards, including proof that synthetic or anonymised data would not do the job, technical limits on re-use with pseudonymisation, strict and documented access controls, no transmission to other parties, deletion once the bias is corrected, and a written record of why the processing was strictly necessary. GDPR compliance and Article 10 compliance are neither substitutes nor supersets of each other; this paragraph is its own regime.

The records an auditor will ask for

Translating 10(2) into artifacts, a provider needs to be able to produce:

1. A data-governance document that maps your actual practices to points (a) through (h).
2. Provenance and origin records per data source, including collection process and, for personal data, original purpose.
3. Preparation logs covering annotation, labelling, cleaning, updating, enrichment, and aggregation.
4. An assumptions register and a suitability assessment for the data sets used.
5. Bias examination records and the mitigation measures taken.
6. A gap register with remediation plans.
7. Representativeness and statistical-properties evidence for the intended purpose and deployment setting.
8. If you used the 10(5) exception: the full package of necessity rationale, access logs, and deletion records.

These records have a designated home. Annex IV point 2(d) requires technical documentation to include datasheets “describing the training methodologies and techniques and the training data sets used,” including provenance, scope, main characteristics, how the data was obtained and selected, labelling procedures, and cleaning methodologies. Article 11 requires that documentation to exist before the system is placed on the market and to be kept up to date.

One trap worth naming: Article 12, the record-keeping article, is about runtime event logging over the system’s life, for traceability and post-market monitoring. It is not about training data. Good training-data records do not discharge Article 12, and runtime logs do not discharge Article 10.

The engineering consequence of all this is simple. Every artifact on the list is cheap if your pipeline emits it as a side effect of running, and expensive if a team has to reconstruct it afterwards. The provenance records are the extreme case: where data came from and what you knew about the source at the time is not reconstructable after the fact. Either it was captured at ingestion or it does not exist.

Five misreadings to avoid

1. “All training data must be error-free.” No. “Free of errors” is qualified by “to the best extent possible” and judged against intended purpose. The unqualified requirements are relevance and sufficient representativeness.
2. “Article 10 applies to every AI company.” It binds providers of high-risk systems, through the two doors above, and only for trained systems in full.
3. “We publish a GPAI training-content summary, so we are covered.” Different regime. The Article 53 summary is a transparency duty; Article 10 is a quality and governance regime that arrives via high-risk systems.
4. “We are GDPR-compliant, so Article 10 is handled.” Orthogonal. Article 10(5) permits processing GDPR would otherwise bar, under its own six safeguards, and the rest of Article 10 asks questions GDPR never asks.
5. “Deadline is August 2026.” Moved by the Digital Omnibus: December 2027 for stand-alone high-risk, August 2028 for product-embedded.

Where tooling fits, and where it does not

No tool makes you Article 10 compliant. Compliance is a property of your whole conformity assessment and your process, not of any product you install, and any vendor who says otherwise is selling something the law does not recognize.

What tooling can honestly do is generate evidence classes as your pipeline runs. The record-keeping half of the checklist, points (b), (c), and the detection side of (h) in particular, is automatable at ingestion time: per-source provenance and origin records, preparation and lineage logs, gap and anomaly detection, and datasheet assembly from pipeline metadata instead of after-the-fact archaeology. The judgment half is not automatable and stays with you: what counts as representative for your intended purpose, how to design the bias examination, and whether the 10(5) exception is strictly necessary.

That division is where we sit. Agentiks runs inside your own cluster and produces per-source provenance, trust, and preparation evidence with a tamper-evident audit trail, which supports the record-keeping half of this checklist. We wrote about why source-level records are the right unit in Trust the source, not the snapshot.

If you provide, or expect to provide, a high-risk system: the dates moved, but the artifacts on this list take the longest to build retroactively. Start emitting them now, while they are a side effect instead of a project.