EU AI Act Data Governance: What Article 10 Really Requires From Your Datasets
ℹ️ TL;DR
- Article 10 of the EU AI Act makes dataset quality a legal requirement for high-risk AI systems. It mandates eight data governance practices — covering data sourcing, annotation, bias detection, and gap analysis — plus explicit quality criteria for training, validation, and testing data.
- The Digital Omnibus adopted in June 2026 moved the high-risk deadline to 2 December 2027, but the requirements themselves have not changed by a single word.
- The organisations that will pass their conformity assessments in 2027 are the ones building their dataset governance and training data inventory now.
- This article explains what Article 10 requires, how to operationalise it, and how Innovatiana approaches dataset creation and governance — including Dataset Finder, our dataset governance tool launching at the end of this year.
Introduction
Every serious conversation about AI compliance in Europe eventually arrives at the same place: the data.
Risk management systems, technical documentation, human oversight — these are the visible layers of the EU AI Act. But underneath all of them sits a simpler question that regulators, auditors, and notified bodies will ask first: what data did you train this system on, where did it come from, who touched it, and how do you know it’s fit for purpose?
That question is codified in Article 10 of the EU AI Act, titled Data and Data Governance. It is the most prescriptive obligation in the entire high-risk chapter, and it is the one that reaches furthest down the AI supply chain — to data collection, to annotation and labelling partners, to anyone who prepares training data on a provider’s behalf.
💡 At Innovatiana, we build datasets for a living. We have spent years developing the traceability, documentation, and quality practices that Article 10 now makes mandatory — and we have built an internal tool, Dataset Finder, to govern datasets and maintain a training data inventory at scale. This guide shares what we’ve learned: what the law requires, what it means operationally, and how to get ahead of it.
What Is the EU AI Act? (A 90-Second Refresher)
The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024. It is the world’s first comprehensive AI regulation, and it doesn’t regulate AI as a technology — it regulates AI applications by risk level:
• Unacceptable risk — banned outright (social scoring, untargeted facial recognition scraping, workplace emotion recognition). Enforceable since February 2025, with new prohibitions on non-consensual intimate imagery generation applying from December 2026.
• High risk — heavily regulated. AI in hiring, credit scoring, education, biometrics, critical infrastructure, law enforcement and public services, and medical devices. This is where Article 10 lives.
• Limited risk — transparency obligations under Article 50 (chatbots must disclose they are AI; synthetic content must be machine-readably marked). These apply from 2 August 2026.
• Minimal risk — no specific obligations (spam filters, recommendation engines, most AI in production today).
The Act has extraterritorial reach: if your AI system’s output is used by people in the EU, you are in scope regardless of where your company — or your servers — are located. Penalties reach €35 million or 7% of global annual turnover for the most serious violations, and €15 million or 3% for non-compliance with high-risk requirements, including Article 10.
If your system falls in the high-risk tier, data governance is not one requirement among many. It is the foundation the others are built on: your risk management (Article 9), technical documentation (Article 11), and accuracy claims (Article 15) all depend on being able to demonstrate what your data is and how it was made.
Why Data Governance Is the Heart of the EU AI Act
There’s a reason the legislators placed the data article immediately after risk management and before everything else. Most documented AI failures — discriminatory hiring tools, biased credit models, medical systems that underperform on under-represented populations — trace back not to model architecture but to the data the model learned from.
The EU AI Act internalises this. Recitals 66–70 make the logic explicit: high-quality datasets are treated as a precondition for trustworthy AI, and poor data governance is treated as a source of risk to health, safety, and fundamental rights.
The practical consequence: training data stops being an internal engineering artifact and becomes a regulated, auditable asset. “We scraped it, cleaned it, and it worked on the benchmark” is not a compliance posture. A regulator or notified body will expect a documented answer to where each dataset came from, why it was chosen, how it was prepared and annotated, what biases were checked, and what gaps remain.
This is what “EU AI Act data governance” means in practice — and it is exactly the discipline that most AI teams have never had to formalise.
What Does Article 10 of the EU AI Act Require?
Article 10 applies to training, validation, and testing datasets used to develop high-risk AI systems. It has three layers: governance practices, quality criteria, and a narrow exception for sensitive data. (A useful edge case sits in paragraph 6: even high-risk systems that don’t involve model training — rule-based systems, for example — must still apply these requirements to their testing data.)
The 8 Mandatory Data Governance Practices — Article 10(2)
Datasets must be subject to governance and management practices appropriate for the intended purpose of the system. The Article enumerates eight areas these practices must cover:
1. Design choices — documenting the relevant decisions behind the dataset: what data, in what proportions, structured how, and why.
2. Data collection and origin — where the data came from, how it was collected, and — for personal data — the original purpose of its collection. This is data provenance, made law.
3. Data preparation operations — annotation, labelling, cleaning, updating, enrichment, and aggregation. The Act explicitly names annotation and labelling, which means your labelling workflows, guidelines, and quality controls are now within the regulatory perimeter.
4. Formulation of assumptions — what the data is supposed to measure and represent. If your proxy variables don’t measure what you think they do, this is where it surfaces.
5. Availability, quantity, and suitability assessment — a documented judgement, before development, of whether you actually have the data your intended purpose requires.
6. Bias examination — reviewing datasets for biases likely to affect health and safety, negatively impact fundamental rights, or lead to prohibited discrimination — with special attention to feedback loops where outputs influence future inputs.
7. Bias prevention and mitigation — appropriate measures to detect, prevent, and mitigate the biases identified in point 6. Examining is not enough; you must act, and document the action.
8. Gap and shortcoming identification — identifying data gaps that prevent compliance, and how you will address them.
💡 Notice the pattern: each practice implies evidence. Not a policy PDF sitting in a drive, but records tied to specific datasets — what one might call an audit trail for your data.
The Quality Criteria — Article 10(3) and 10(4)
Beyond governance, the datasets themselves must meet quality standards. Training, validation, and testing data must be:
- Relevant to the intended purpose;
- Sufficiently representative of the people and situations the system will encounter;
- Free of errors and complete — to the best extent possible, in view of the intended purpose (the Act is pragmatic here: perfection isn’t demanded, best effort and documentation are);
- Statistically appropriate for the persons or groups on whom the system will be used — a criterion that can be met at the level of individual datasets or a combination of them;
- Contextually grounded — reflecting the geographical, contextual, behavioural, or functional setting of deployment. A pedestrian-detection model trained only on Californian daylight footage does not satisfy Article 10 for deployment on Northern European winter roads.
The Sensitive Data Exception — Article 10(5)
Here the Act does something unusual: it permits something GDPR normally forbids. To detect and correct bias, providers of high-risk systems may exceptionally process special categories of personal data (ethnicity, health data, sexual orientation, and other GDPR Article 9 categories) — but only under six cumulative conditions, including that no other data (synthetic or anonymised) would do the job, strict access controls and pseudonymisation, no transfer to third parties, deletion once the bias is corrected, and documented justification in the records of processing.
The Digital Omnibus extends this legal basis beyond high-risk providers (via a new Article 4a) to deployers, non-high-risk providers, and GPAI model providers. It removes a genuine legal blocker to fairness testing — but it is a permission wrapped in obligations, not a free pass.
The Updated Timeline: What the Digital Omnibus Changed (and What It Didn’t)
The compliance calendar shifted in 2026, and it’s worth being precise, because half-understood headlines (“the EU delayed the AI Act”) have lulled some teams into a false sense of security.
The Digital Omnibus on AI — provisionally agreed on 7 May 2026, endorsed by Parliament on 16 June, and given the Council’s final green light on 29 June 2026 — amends the AI Act’s application dates:
Three things to internalise:
The requirements didn’t change — only the date did. The Omnibus moved deadlines and streamlined some documentation for SMEs; it did not soften Article 10. Every governance practice and quality criterion described above applies in full from December 2027.
Sixteen months is less than it sounds. Building a dataset inventory, reconstructing provenance for data collected years ago, formalising annotation governance, running bias assessments, and producing conformity-ready documentation is a multi-quarter programme. Organisations that treated GDPR’s two-year runway as a snooze button spent spring 2018 in triage. The same movie is queued up for autumn 2027.
Data decisions made today are regulated tomorrow. Any dataset you collect, annotate, or purchase in 2026 will still be in your training corpus when enforcement begins. Retrofitting provenance onto data whose origin nobody recorded is somewhere between painful and impossible. The cheapest moment to comply with Article 10 is at the moment the dataset is created.
From Legal Text to Engineering Reality: Operationalising Article 10
So what does an Article 10-ready data operation actually look like? In our experience building datasets for AI teams across computer vision, NLP, LLM fine-tuning, and RLHF, compliance decomposes into five operational capabilities.
1. A Training Data Inventory
You cannot govern what you cannot enumerate. The starting point — and the step most organisations discover they’re missing — is a complete inventory of every dataset used to train, validate, and test each AI system: internal data, purchased data, open datasets, scraped corpora, synthetic data, and the annotated layers built on top of them. Each entry needs an owner, a version, a licence, a provenance record, and a link to the systems it feeds. Without this, every other Article 10 practice is built on sand.
2. Provenance and Lineage Records
Article 10(2)(b) demands the origin story of your data. That means recording, per dataset: source, collection method, collection date, original purpose (for personal data), licensing terms, and every transformation applied since — with the ability to trace any training example back through cleaning, filtering, enrichment, and annotation to its source. This is data lineage, but with a legal standard of proof attached.
3. Documented Annotation and Labelling Governance
Because the Act names annotation and labelling as regulated preparation operations, your labelling pipeline becomes evidence. Auditors will expect: written annotation guidelines and their version history, annotator training and qualification records, quality assurance procedures, inter-annotator agreement metrics, and review/escalation workflows. Anonymous crowdsourcing — where nobody can say who labelled what, under which instructions, with what quality control — is structurally difficult to reconcile with this requirement.
4. Bias Assessment and Mitigation Workflows
Points (f) and (g) require a repeatable process: define the protected groups and failure modes relevant to your intended purpose, measure representation and performance across them, document findings, apply mitigations (rebalancing, targeted collection, re-annotation), and re-measure. One-off fairness audits don’t satisfy a lifecycle obligation; this needs to run every time the dataset or the deployment context changes.
5. Gap Analysis and a Living Data Roadmap
Finally, Article 10 asks you to be honest about what your data doesn’t cover — the geographies, demographics, edge cases, and contexts where it falls short — and to document how you’ll close those gaps. Done well, this stops being a compliance exercise and becomes your data acquisition roadmap.
💡 The reframe worth making: none of these five capabilities is regulatory dead weight. Teams with clean inventories, documented annotation processes, and systematic bias workflows ship better models with fewer late-stage surprises. Article 10 is, in essence, mandated ML engineering hygiene. For teams already operating with strong data foundations, compliance means formalising existing practice; for everyone else, it doubles as technical debt reduction.
Article 10 Flows Down the Supply Chain — Choose Your Data Partners Accordingly
Here is the part of Article 10 that isn’t written in the article itself but follows inevitably from it: providers cannot produce this evidence alone.
If a third party collects your data, builds your datasets, or runs your annotation, the provenance records, annotation guidelines, annotator qualifications, and QA metrics that Article 10 requires live — at least partly — with that partner. Providers will therefore push these requirements downstream contractually. Data and annotation vendors that cannot supply audit-ready documentation will become compliance liabilities, and procurement teams are already starting to ask the questions:
- Can you document exactly who annotated each item, under which guideline version?
- Can you provide provenance for sourced or collected data, including licences?
- Can you produce QA and inter-annotator agreement reports per batch?
- Can you demonstrate that your workforce is trained, qualified, and working under traceable conditions?
💡 If your current data supplier answers with silence — or with “we use a global crowd” — you have found an Article 10 gap!
How Innovatiana Crafts Compliance-Ready Datasets
This is precisely the model Innovatiana was built on — years before the AI Act made it a legal expectation.
We are a French company that crafts datasets for AI teams: computer vision, NLP, document processing, generative AI and LLM fine-tuning, and RLHF. And we do it in a way that maps directly onto Article 10’s demands:
- In-house, trained teams — not anonymous crowdsourcing. We recruit and train our own Data Labelers and domain experts. Every annotation is attributable to a known, qualified professional working under documented guidelines. That’s an ethical choice — fair wages, real career paths, decent working conditions — and it is also, it turns out, exactly what regulatory traceability requires. Ethics by design and compliance by design converge.
- Full traceability of the annotation process. Guideline versions, annotator assignments, review layers, QA metrics, disagreement resolution: we document the preparation operations that Article 10(2)(c) regulates, so our clients can drop that evidence directly into their technical documentation under Article 11 and Annex IV.
- Transparent data sourcing. When we collect or source data for a dataset, we disclose where it comes from and under what terms — the provenance record Article 10(2)(b) expects.
- Quality as a measurable property. Representativeness, error rates, coverage of edge cases and deployment contexts: we treat Article 10(3)’s quality criteria as engineering targets with acceptance thresholds, not aspirations — all within a data security and confidentiality framework aligned with GDPR.
💡 In short: when a client trains a high-risk system on a dataset we crafted, the Article 10 paper trail for that dataset already exists. See how we work in our case studies.
Introducing Dataset Finder: Dataset Governance and Training Data Inventory, as a Product
Building hundreds of datasets taught us something else: the hardest part of EU AI Act data governance isn’t any single dataset — it’s the fleet. Most AI teams don’t have one dataset; they have dozens or hundreds, scattered across buckets, drives, and vendor deliveries, with provenance living in people’s heads.
So we built a tool to solve it for ourselves. It’s called Dataset Finder, and it’s how we govern datasets internally today:
- Training data inventory — a single catalogue of every dataset, with ownership, versioning, and the AI systems each dataset feeds. The Article 10 starting point, automated.
- Provenance and lineage tracking — source, licence, collection context, and every preparation step (cleaning, enrichment, annotation) recorded per dataset version.
- Governance metadata mapped to Article 10 — design choices, assumptions, suitability assessments, bias examinations, and identified gaps captured as structured records rather than scattered documents — ready to feed your Annex IV technical documentation.
- Audit-ready exports — because the test of a governance system is whether it can answer a regulator’s question in minutes, not weeks.
👉 Dataset Finder will be released publicly by the end of this year — deliberately timed so that teams have a full runway to build their dataset inventory before the December 2027 high-risk deadline. If you’d like early access, or you want your training data inventory built with expert support rather than from scratch, talk to us.
Our Recommendations: An EU AI Act Data Governance Action Plan
Whether or not you work with us, here is the sequence we recommend to any AI team preparing for Article 10. Realistically, this is a 12–18 month programme — which is exactly the runway left before December 2027.
1. Classify your systems first. Determine which of your AI systems are high-risk under Annex III (or Annex I). Everything else in this plan scales with that answer — and misclassification in either direction is expensive.
2. Build your training data inventory now. Enumerate every training, validation, and testing dataset per system. Expect this to take longer than you think; expect to find datasets nobody remembers creating.
3. Reconstruct provenance while you still can. For each dataset: source, collection method, licence, original purpose. The people who know this leave companies; document it before they do.
4. Formalise annotation governance. Written guidelines, versioning, annotator qualification records, QA metrics. If you outsource labelling, require this evidence contractually — today, for every new project.
5. Run a bias and representativeness baseline. Measure your datasets against your actual deployment context (geography, demographics, conditions). Document findings and mitigations. Make it a recurring process, not an event.
6. Write down your assumptions and gaps. What is each dataset supposed to represent? Where does it fall short? Turn the gap list into a data roadmap with owners and dates.
7. Audit your data supply chain. Send your Article 10 questions to every data and annotation vendor. Replace the ones who can’t answer.
8. Connect data governance to the rest of your compliance stack. Article 10 evidence feeds Article 11 technical documentation, Article 9 risk management, and your conformity assessment. Design the records once, reuse them everywhere.
9. Don’t wait for December 2027. Transparency obligations bite in August 2026, procurement questionnaires are circulating already, and every dataset you create without governance is future rework. The deferral is runway, not a pause.
👉 Get Ahead of Article 10 With Innovatiana
The EU AI Act has turned training data into a regulated asset — and dataset governance into a competitive advantage. Innovatiana crafts high-quality, fully traceable datasets with in-house expert teams, and our product, Dataset Finder, brings that same governance discipline to your entire data estate.
Request a free quote → or talk to an expert → to discuss your datasets, your Article 10 readiness, or early access to Dataset Finder.
________________________________________
This article is provided for general information and does not constitute legal advice. For guidance on your specific obligations under Regulation (EU) 2024/1689, consult qualified legal counsel.
