EU AI Act Article 10: Data Governance
Article 10 governs the data used to build high-risk AI systems. Training, validation and testing datasets must meet quality criteria, be examined for bias, and be handled under strict conditions when special-category data is involved. This page explains what data governance the Act requires and where the responsibility sits.
EU AI Act Article 10: Data Governance
Article 10 governs the data used to build high-risk AI systems. Training, validation and testing datasets must meet quality criteria, be examined for bias, and be handled under strict conditions when special-category data is involved. This page explains what data governance the Act requires and where the responsibility sits.
সর্বশেষ আপডেট করা হয়েছে: ৪ জুলাই, ২০২৬
What Article 10 Requires
High-risk AI systems that are trained with data must be developed on the basis of training, validation and testing datasets that meet the quality criteria set out in Article 10 whenever such datasets are used.
The obligation is on the provider, and it applies to appropriate data governance and management practices across the full data lifecycle — from design choices and collection through preparation, examination and mitigation. Data governance under Article 10 is one of the requirements the Annex IV technical documentation and the Article 17 QMS must in turn describe and control.
Data Quality Criteria
Training, validation and testing datasets must be subject to data governance practices appropriate to the intended purpose, addressing in particular:
- Relevance and representativeness — datasets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose
- Appropriate statistical properties — including, where applicable, as regards the persons or groups of persons on whom the system is intended to be used
- Design choices and provenance — the relevant design assumptions, and how the data was collected, its origin and, for personal data, the original purpose of collection
- Data preparation — annotation, labelling, cleaning, updating, enrichment and aggregation operations must be documented
- Contextual coverage — the data must account for the geographical, contextual, behavioural or functional setting in which the high-risk system is intended to be used
Bias Examination, Mitigation and Data Gaps
Article 10 explicitly requires providers to look for and address bias and gaps in the data:
- Examine for biases that are likely to affect health and safety, have a negative impact on fundamental rights, or lead to prohibited discrimination — especially where outputs influence inputs for future operations (feedback loops)
- Apply appropriate mitigation measures for any biases identified during that examination
- Identify and address data gaps and shortcomings that could prevent compliance, and document how they are handled
- Document the reasoning so that bias examination and mitigation are auditable, not just performed
Special-Category Data Conditions
Article 10 permits the processing of special categories of personal data, but only to the strict extent necessary to detect and correct bias, and subject to safeguards.
That means the exception applies only when bias detection and correction cannot be effectively achieved with synthetic, anonymised or other non-special-category data. Where special-category data is used, it must be subject to appropriate safeguards for the rights and freedoms of individuals — including technical limits on re-use, state-of-the-art security and privacy-preserving measures, strict access controls and documentation, and deletion once the bias has been corrected or the data reaches the end of its retention period.
Article 10's special-category-data allowance operates alongside the GDPR, not instead of it — the GDPR's own conditions for processing special categories still apply.
How AIAgentree helps
AIAgentree complements dataset and MLOps tooling rather than replacing it: it records the decisions and exceptions around data handling as auditable evidence, so the judgement calls Article 10 requires are captured and defensible:
- Tamper-evident decision records preserve why a data source was accepted, a bias-mitigation step was taken, or a data gap was accepted as residual — the reasoning Article 10 expects you to be able to show
- Human-oversight and approval workflows capture sign-off on sensitive data-handling decisions, including special-category-data justifications, with who-decided-what recorded automatically
- Audit-fit retention and exports over REST, MCP, A2A and OpenTelemetry (Python and TypeScript SDKs, EU data residency in Germany) keep that governance trail available for inspection — start on the 25-trace free tier
Frequently Asked Questions
Does Article 10 apply to every high-risk AI system?
It applies to high-risk systems that are developed using data-training techniques. The data quality and governance criteria apply whenever training, validation and testing datasets are used; systems not trained on data are addressed by the Act's other requirements.
Does data have to be perfectly error-free?
No. Article 10 requires datasets to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. It sets a best-efforts, purpose-proportionate standard rather than an absolute guarantee of perfection.
Can we use sensitive personal data to check for bias?
Only exceptionally. Article 10 allows processing special categories of personal data strictly for detecting and correcting bias, when this cannot be done with other data, and only under strong safeguards such as access controls, security measures and deletion once the purpose is met. GDPR conditions still apply on top.
Who is responsible for Article 10 compliance?
The provider of the high-risk AI system. Deployers who control input data have a related duty under Article 26 to ensure that input data is relevant and sufficiently representative for the intended purpose, but the core data governance obligation sits with the provider.
What has to be documented under Article 10?
The data governance choices — collection and origin, preparation operations such as labelling and cleaning, assumptions made, the bias examination and any mitigation applied, and how identified data gaps were handled. This documentation feeds the Annex IV technical documentation and the Article 17 quality management system.
Continue exploring the EU AI Act guide
EU AI Act Compliance Guide
The complete guide to EU AI Act compliance for AI agents — start here.
Article 12 — Record-Keeping & Logging
What every high-risk AI system must log, and how to capture it.
Article 14 — Human Oversight
Designing effective human-in-the-loop controls for AI decisions.
Annex III — High-Risk AI Systems
Which AI use cases the Act classifies as high-risk.
EU AI Act Compliance Checklist
A step-by-step checklist to reach and document compliance.
Compliance Cost Calculator
Estimate your EU AI Act compliance effort and cost.
Deadlines & Timeline
Key enforcement dates, including the August 2, 2026 deadline.
Fines & Penalties
Penalty tiers up to €35M or 7% of global annual turnover.
Transparency Obligations (Art. 13 & 50)
Disclosure duties for AI systems and their outputs.
Risk Management & Conformity Assessment
Build a risk management system and assess conformity.
GPAI Obligations
Rules for providers of general-purpose AI models.
EU AI Act for US Companies
Extraterritorial scope and what US providers must do.
Omnibus Update
The latest changes to the EU AI Act timeline and rules.
Penalty Calculator
Estimate your maximum fine under the Article 99 tiers.
Article 11 + Annex IV
What technical documentation the EU AI Act requires.
Article 26: Deployer Obligations
What deployers of high-risk AI must do, including log retention.
Article 17: Quality Management
The QMS providers of high-risk AI must document.
Article 4: AI Literacy
The staff AI-literacy duty in force since February 2025.
Deployer vs Provider
Who bears which obligation — and when a deployer becomes a provider.
FRIA (Article 27)
Who must run a Fundamental Rights Impact Assessment, and how.
Who Does It Apply To?
Scope, operators, and the extraterritorial reach of the EU AI Act.
Post-Market Monitoring
Articles 72–73: ongoing monitoring and incident reporting.
ISO 42001 vs EU AI Act
How the voluntary standard and the binding law fit together.
NIST AI RMF vs EU AI Act
A practical crosswalk between the framework and the law.
EU AI Act for Healthcare
High-risk medical AI, MDR/IVDR interplay, and clinician oversight.
EU AI Act for Financial Services
Credit scoring, insurance pricing, and existing financial regulation.
EU AI Act for HR & Employment
Hiring AI as high-risk, plus NYC LL144 and EEOC overlap.