EU AI Act Article 10 Data and Data Governance Guide

Article 10 of the EU AI Act makes the quality and governance of training, validation and test data a legal requirement for high-risk AI systems, and the Digital Omnibus on AI has changed how bias work involving sensitive personal data is permitted. Many teams still read Article 10 as written in 2024, including the old paragraph 5 on special categories of personal data, which the Commission's AI Act Service Desk now shows as deleted and replaced by a new Article 4a. This guide takes the current text paragraph by paragraph, explains the governance practices points (a) to (h) require, shows how to examine and correct bias lawfully, and lists the evidence an assessor will look for. It is for data science, data governance, privacy and security teams working on high-risk systems, and for deployers checking a provider's claims. For the wider regime, start with the EU AI Act High-Risk AI Systems Guide.

Source note: this page summarises the official text and the sources listed at the end. Confirm against the official text before relying on it.

Key takeaways

Eight governance practices, all documented. Article 10(2) lists design choices, collection and origin, preparation, assumptions, availability and suitability, bias examination, bias mitigation, and data gaps. Each needs a record, not just a practice.
Quality is measured against the intended purpose. Article 10(3) and 10(4) require data that is relevant, sufficiently representative, as free of errors and complete as possible, and reflective of the geographical, contextual, behavioural or functional setting of use.
Paragraph 5 has moved. According to the AI Act Service Desk text as amended by the Digital Omnibus on AI, Article 10(5) is deleted and new Article 4a sets six conditions for processing special categories of personal data for bias detection and correction.
No training does not mean no Article 10. Under Article 10(6), systems that do not train models must still apply paragraphs 2 to 4 and Article 4a(1) to their testing data sets.
Data access is a data quality control. Poisoned or silently altered data breaks every quality claim, so the identities that can write to datasets and labelling pipelines belong in the Article 10 evidence.

Article 10 as it now reads

The table paraphrases each paragraph from the Commission's AI Act Service Desk text, which states it is based on the EUR-Lex consolidated text as at 27 July 2026, including Digital Omnibus amendments. Checked in November 2026. High-risk obligations in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, according to the same source's Article 113. See the EU AI Act Implementation Timeline Tracker for later changes.

Paragraph	What it requires	Status	Evidence that answers it
10(1)	High-risk systems that use techniques involving the training of AI models are developed on training, validation and testing data sets meeting the quality criteria in paragraphs 2 to 4 and Article 4a(1), where such data sets are used.	Amended (adds Article 4a(1))	Dataset register showing each set's role (train, validation, test) and the criteria applied
10(2)	Data sets are subject to data governance and management practices appropriate for the intended purpose, covering points (a) to (h).	Unchanged	Data governance procedure and per-dataset records for each point
10(3)	Data sets are relevant, sufficiently representative and, to the best extent possible, free of errors and complete for the intended purpose, with appropriate statistical properties, including for the persons or groups on whom the system is intended to be used. These may be met per data set or in combination.	Unchanged	Quality metrics, representativeness analysis against the target population
10(4)	Data sets take into account, to the extent required by the intended purpose, the characteristics particular to the specific geographical, contextual, behavioural or functional setting of use.	Unchanged	Deployment context analysis and the data features that cover it
10(5)	Former basis for processing special categories of personal data for bias detection and correction.	Deleted; see Article 4a	Records under Article 4a instead
10(6)	For systems not using techniques involving training of AI models, paragraphs 2 to 4 and Article 4a(1) apply only to testing data sets.	Amended (adds Article 4a(1))	Testing dataset governance records

The governance practices in Article 10(2)

Each point needs a short, dated record per dataset. A datasheet per dataset, kept under version control next to the data, is the simplest way to hold them. Annex IV point 2(d) separately requires the technical documentation to describe datasets, their provenance, scope and main characteristics, how they were obtained and selected, labelling procedures and data cleaning methodologies, so the same records serve both.

Point	Practice	What a good record contains
(a)	Relevant design choices	Why this data, this granularity and these features were chosen for the intended purpose; alternatives rejected
(b)	Data collection processes and origin; for personal data, the original purpose of collection	Source, licence or legal basis, collection dates, original purpose, chain of custody
(c)	Data preparation operations such as annotation, labelling, cleaning, updating, enrichment and aggregation	Labelling guidelines, annotator agreement, cleaning rules, transformation code version
(d)	Formulation of assumptions about what the data measure and represent	Proxy variables named, for example "prior arrests" as a proxy, and the limits of each
(e)	Assessment of availability, quantity and suitability of the data sets	Volume per class and subgroup, coverage gaps, fitness decision
(f)	Examination for possible biases likely to affect health and safety, negatively impact fundamental rights or lead to prohibited discrimination, especially where outputs influence future inputs	Bias hypotheses, tests run, subgroups, results
(g)	Measures to detect, prevent and mitigate the biases identified under (f)	Mitigation chosen (reweighting, resampling, relabelling, constraints), before and after results
(h)	Identification of relevant data gaps or shortcomings that prevent compliance, and how they can be addressed	Gap list with owner and plan, and the residual risk fed into Article 9

For point (b), training data provenance also carries copyright and licensing exposure. See the AI Training Data Provenance and Copyright Exposure Guide.

Representativeness, errors and completeness in practice

Article 10(3) uses qualified language: "sufficiently" representative, free of errors "to the best extent possible". That makes the measurement and the rationale the evidence. Set the measures in advance, consistent with the Article 9(8) requirement to test against prior defined metrics.

Relevance: map each feature to the intended purpose; drop features that only add discrimination risk. Record removals.
Representativeness: compare the distribution of relevant attributes in the data with the population the system will be used on, per deployment setting under 10(4). A model trained on one country's applicants and sold across the EU needs evidence for each market or a stated limit in the instructions for use.
Error rate: sample and re-label a fixed share of each dataset to estimate label error, and record the estimate with its confidence.
Completeness: measure missing values per feature and subgroup; missingness that clusters in one group is a bias signal for point (f).
Separation of sets: show that validation and test data are independent of training data, with no leakage of the same individuals or near duplicates.

Draft European standards are being written to support this: prEN 18284 on quality and governance of datasets in AI (shown as under drafting in October 2026 on StandICT.eu) and prEN 18283 on managing bias in AI systems (a working draft in 2026, according to CEN-CENELEC). Neither is final; ISO/IEC TR 24027:2021 on bias in AI systems and AI aided decision making is published and usable as guidance now.

Bias examination and special category data under Article 4a

Bias testing often needs the very attributes the law protects, such as ethnic origin or health. Article 4a now governs that processing. According to the AI Act Service Desk text, Article 4a(1) allows providers of high-risk systems, exceptionally and to the extent strictly necessary for bias detection and correction under Article 10(2)(f) and (g), to process special categories of personal data, subject to safeguards and to the GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680 as applicable. All of these conditions must be met:

Article 4a(1) condition	Control that evidences it
(a) Bias detection and correction cannot be effectively fulfilled by processing other data, including synthetic or anonymised data	Written necessity test showing synthetic and anonymised options were tried or ruled out
(b) Technical limitations on re-use and state of the art security and privacy measures, including pseudonymisation	Pseudonymised working copy, purpose-bound environment, no export path
(c) Strict controls and documentation of access; only authorised persons with confidentiality obligations	Named access list, just-in-time access, access logs reviewed
(d) Not transmitted, transferred or otherwise accessed by other parties	Egress controls on the environment, contract terms with processors
(e) Deleted once the bias is corrected or the retention period ends, whichever comes first	Deletion record with date and method
(f) Records of processing explain why the processing was strictly necessary and why other data could not achieve the objective	Entry in the GDPR Article 30 record of processing with the necessity rationale

Article 4a(2) extends the same option, under the same conditions, to providers and deployers of other AI systems and models and to deployers of high-risk systems, and the Service Desk text notes that it creates no obligation to carry out bias detection. Article 4a does not replace the GDPR: a lawful basis and an Article 9 GDPR condition are still needed, and a DPIA will usually be required. See the AI and GDPR Guide and the DPIA Guide.

Where identity fits

Article 10 quality claims hold only if the data cannot be changed without trace. Training data poisoning (MITRE ATLAS AML.T0020) and publication of poisoned datasets (AML.T0019) are integrity attacks, and most succeed through write access held by a pipeline service account, a labelling vendor's API token or a shared storage key. Treat dataset write access like production access: separate identities for ingestion, labelling and training, read-only access for training jobs, short-lived credentials, and hashes of each dataset version recorded in the datasheet. Article 4a(1)(c) already demands strict, documented access for sensitive data; applying the same discipline to every training set costs little more. See the AI Data Poisoning and Backdoors Guide and the Data Governance and Data Catalogue Security Guide.

Deciding the approach

The following is NHI Mgmt Group's recommendation, not a requirement of the Act.

Situation	Approach	Trade-off
Provider trains its own model	Full 10(2) records per dataset, representativeness per market, bias tests per release	Highest effort, strongest position in conformity assessment
Provider fine-tunes a third-party model	Full records for fine-tuning and test data; obtain the upstream provider's documentation for pre-training data and record its gaps under (h)	Upstream evidence may be thin; contract for it early
System does not train models (rules, retrieval, fixed model)	Apply 10(2) to 10(4) to testing data sets as 10(6) requires	Lighter, but the test set must represent the deployment setting
Bias test needs special category data	Try synthetic or proxy-free methods first; if strictly necessary, use an Article 4a enclave with deletion on completion	Privacy risk and GDPR work against better bias evidence
Small provider	One datasheet template, one bias test suite, quarterly review	Simple and auditable; add tooling as datasets grow

Implementing Article 10 in phases

Inventory: list every training, validation and test dataset for each high-risk system, with owner, location, version and role.
Template: adopt a datasheet that has a field for each of points (a) to (h) and for the Annex IV point 2(d) items.
Baseline: fill datasheets for the current datasets, measure representativeness, error and completeness, and record gaps under (h).
Bias suite: define bias hypotheses and subgroup metrics with thresholds before running them; decide whether Article 4a processing is needed and, if so, complete the necessity test and DPIA first.
Lock down: restrict write access, hash dataset versions, and log changes to data and labels.
Integrate: make a current datasheet and passing bias report a release gate, and feed unresolved gaps into the Article 9 register.
Test and roll back: pilot on one system; if a new dataset version fails quality or bias thresholds, retrain from the last approved version and record the decision.

Detection and measurement

Datasheet coverage: share of datasets in use with a complete, current record for points (a) to (h).
Subgroup gap: largest difference in error rate between relevant subgroups, per release, against the threshold.
Label error estimate: sampled label error rate per dataset version.
Integrity: unexplained changes to dataset hashes or labels (target zero), from storage and pipeline logs.
Article 4a hygiene: days special category data was retained beyond bias correction (target zero).
Drift: distance between production input distributions and training data, reviewed through post-market monitoring.

Framework mapping

Article 10 element	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Other
Dataset inventory and metadata, 10(2)(a) to (c)	ID.AM-07	CM-8	Annex IV point 2(d)
Data integrity and access	PR.DS-01	SI-7, AC-6	MITRE ATLAS AML.T0020, AML.T0019
Bias examination and mitigation, 10(2)(f) and (g)	ID.RA-05	RA-3	ISO/IEC TR 24027:2021; prEN 18283 (draft)
Quality criteria, 10(3) and 10(4)	ID.RA-05	SA-11	prEN 18284 (draft)
Special category data, Article 4a	GV.OC-03	PT-2, PT-3	GDPR Articles 9, 30 and 35

Common failure patterns

Working from the 2024 text: privacy and data teams still citing Article 10(5) as the legal route for sensitive data, when the current text routes it through Article 4a.
Overall accuracy as evidence of quality: strong aggregate results that hide poor performance for small subgroups, which 10(3) addresses through statistical properties for the persons or groups concerned.
Undocumented proxies: postcode or employment gaps used as features without the assumption recorded under point (d).
Leaky test sets: the same individuals in training and test data, inflating every reported metric.
Keeping sensitive data "for next time": special category data held after correction, breaching Article 4a(1)(e).
Open write access to training data: shared storage keys and broad pipeline roles that make any quality claim unprovable.

Practitioner checklist

Confirm which text your programme uses and update references from Article 10(5) to Article 4a.
Keep a versioned datasheet per dataset covering points (a) to (h).
Measure representativeness against each deployment setting named in the intended purpose.
Estimate label error and completeness per subgroup, with thresholds set before measurement.
Run a necessity test, DPIA and Article 4a controls before using special category data for bias work.
Delete special category data on completion of bias correction and keep the deletion record.
Restrict and log write access to datasets and labels, and hash every approved version.
Feed data gaps from point (h) into the Article 9 risk register.
Track prEN 18284 and prEN 18283 until their references are published.

Standards and references

Related NHI Mgmt Group resources: EU AI Act Article 9 Risk Management System Guide · EU AI Act Article 15 Guide · EU AI Act Provider vs Deployer Obligations Guide · AI Governance Guide. This guide summarises Article 10 of the EU AI Act and is not legal advice.

EU AI Act Article 10 Data and Data Governance Guide: Training, Validation and Test Data, Bias Examination and Evidence