EU AI Act Article 10: What Deployers Must Understand About Data Governance for High-Risk AI

When regulators and insurers assess a high-risk AI incident, the first question they ask is not whether the model was accurate. It is whether the data used to train, validate, and test the system was subject to documented governance. Article 10 of the EU AI Act is the provision that answers that question. Deployers who have never read it are carrying a compliance and underwriting exposure they may not have priced.

The Scope of Article 10: Training, Validation, and Testing Together

Article 10(1) of Regulation (EU) 2024/1689 states that high-risk AI systems that are trained on data must be developed on the basis of training, validation, and testing data sets that are subject to appropriate data governance and management practices. This framing is deliberate: the obligation attaches to all three dataset types, not merely the training corpus. A system that was trained responsibly but validated on a narrow or unrepresentative dataset fails the standard just as surely as one trained on contaminated data.

The provision addresses providers, meaning those who develop or place on the market a high-risk AI system under their own name or trade mark. This covers both original model developers and entities that substantially modify a third-party model before deploying it. The distinction between provider and deployer is not semantic formality; it determines who bears primary responsibility for the data governance record. But as this analysis will show, deployers who rely on that distinction as a shield misunderstand the regulation's structure.

The practical scope of Article 10 extends to every system listed in Annex III of the Regulation. The eight Annex III categories include biometric identification systems, safety components in critical infrastructure, educational and vocational training systems, employment and worker management tools, access to essential private services and public services and benefits, law enforcement, migration and border management, and administration of justice. Each category represents a domain where biased or poorly governed training data can produce discriminatory outputs affecting individuals' fundamental rights.

Article 10(2): The Six Governance Practices

Article 10(2) enumerates the data management practices that must be addressed. The list includes data collection, data preparation operations (preprocessing, labelling, annotation), storage, filtration, and enrichment. Together, these six elements constitute the data lineage record that any serious compliance or underwriting review will request.

Data collection governance covers the provenance of the datasets: where the data was sourced, under what legal basis (particularly relevant for personal data under GDPR), and whether collection conditions were documented at the time of acquisition. Gaps here are common in systems trained on web-scraped corpora or third-party licensed datasets, where provenance trails frequently break down.

Preprocessing and labelling governance requires documentation of the methodological choices made during data preparation. Annotation guidelines, inter-annotator agreement scores, and quality assurance protocols all fall within this requirement. The omission of annotation guidelines is one of the most frequent deficiencies identified in technical audits of commercial AI systems, because organisations tend to treat data preparation as an operational activity rather than a compliance-relevant one.

Storage and filtration governance address the conditions under which data is retained, accessed, and excluded. Filtration is particularly important: the decisions about what data to remove from a training corpus are as consequential as decisions about what to include. If a provider filtered out demographic subgroups to reduce noise, that decision must be documented and its effect on representativeness assessed.

Enrichment governance covers any synthetic augmentation or external data integration applied to expand or balance a dataset. Providers who used generative models to produce synthetic training examples must document that fact and demonstrate that the synthetic data did not introduce or amplify the biases present in the original corpus.

ISO/IEC 42001:2023, the international standard for AI management systems, provides a complementary framework for implementing these practices. While the standard is not mandated by the Regulation, conformance to ISO/IEC 42001:2023 is increasingly referenced by supervisory authorities and insurers as evidence of systematic data governance capability. Providers and deployers who have implemented ISO/IEC 42001:2023 are better positioned to produce the documentation Article 10 requires because the standard makes data governance a managed process rather than an ad hoc activity.

Article 10(3): The Bias Examination Requirement

Article 10(3) requires that training, validation, and testing data be examined for possible biases that could lead to risks to health and safety or fundamental rights violations, including discrimination under Union or national law. The examination is not optional and must be documented.

The phrase "discrimination under Union or national law" is significant. It anchors the bias examination to the existing body of EU non-discrimination law, including Directive 2000/43/EC (race and ethnic origin), Directive 2006/54/EC (sex and gender), and Charter rights under Articles 20 and 21. Bias that would not constitute actionable discrimination under any of these instruments does not necessarily trigger Article 10(3), but providers must be able to demonstrate that they conducted the examination and formed a reasoned conclusion. Absence of documentation is not equivalent to absence of bias; it is treated as a governance failure in its own right.

The required bias examination encompasses both statistical bias (where the dataset is not representative of the population the system will be applied to) and label bias (where the annotation choices embedded in the dataset reflect historical discriminatory patterns). A hiring system trained on historical acceptance decisions may exhibit both forms simultaneously: the accepted candidates may not be demographically representative, and the acceptance labels may reflect the prior discrimination embedded in the historical data.

Providers must document the bias examination methodology, the metrics used, the subgroups assessed, and the measures taken in response to identified biases. Where bias was identified and addressed through rebalancing or reweighting, the documentation must record both the original and post-correction distributions. Where bias was identified but could not be fully corrected, the residual risk must be disclosed in the technical documentation and the instructions for use provided to deployers.

For deployers, this disclosure is operationally important. Article 13(3)(b)(iii) requires that the instructions for use include information about the characteristics, capabilities, and limitations of the system, including biases that have been identified and are known to affect outputs. A deployer who receives this information and ignores it when configuring the system or defining use cases has failed their own Article 26 obligations.

Article 10(4): The Narrow Window for Personal Data in Bias Testing

Article 10(4) creates a carefully bounded exception to the general prohibition on processing special categories of personal data. It permits the processing of sensitive personal data, including data revealing racial or ethnic origin, health data, and biometric data, strictly for the purpose of detecting and correcting biases in high-risk AI systems.

The conditions are cumulative. First, the processing must be strictly necessary for the bias detection purpose; there must be no way to achieve the same bias assessment result without processing the sensitive data. Second, the data must be subject to state-of-the-art security measures, including pseudonymisation where that is technically feasible. Third, the data may not be transmitted to third parties, used for any secondary purpose, or retained beyond the period necessary for the bias correction exercise. Fourth, full documentation of the legal basis and safeguards must be maintained and made available to supervisory authorities on request.

This exception does not override GDPR. It operates as an additional legal basis within the AI Act framework, but controllers relying on it must still satisfy the GDPR requirements applicable to the processing of special categories data under Article 9 GDPR. In practice, this means maintaining a lawful basis under Article 9(2) GDPR in parallel, most commonly legitimate interests subject to a documented balancing test, or an explicit consent regime where the data subjects are identifiable.

The exception is relevant primarily to providers who are conducting post-deployment bias monitoring on live operational data. Deployers who are involved in providing operational data back to providers for bias correction exercises must understand whether the Article 10(4) pathway applies, and if so, whether the safeguards described above are in place. Data sharing agreements between providers and deployers for bias correction purposes should be reviewed by legal counsel against both the AI Act exception and the applicable GDPR framework.

Article 10(5): Statistical Properties and Representativeness

Article 10(5) addresses the statistical properties that training, validation, and test datasets must meet. The datasets must be, to the best extent possible, relevant, sufficiently representative, and free of errors, and complete in view of the intended purpose. This standard applies to both the training corpus and the validation and test splits used to evaluate system performance before deployment.

The phrase "to the best extent possible" acknowledges a practical constraint: in many deployment contexts, perfectly representative datasets do not exist, either because the target population is difficult to sample or because certain subgroups are systematically underrepresented in available data sources. The standard does not demand the impossible, but it does require that providers document the gap between available data and ideal coverage, assess the implications for system behaviour, and disclose the resulting limitations to deployers.

Representativeness under Article 10(5) must be assessed against the intended purpose and the specific population the system will be applied to. A credit scoring system deployed in one EU member state may be trained on a dataset that is representative of national credit applicants but not of cross-border applicants or recent immigrants. If the deployer operates in a context that includes those populations, the representativeness gap becomes a deployment risk that must be assessed and mitigated at the deployer level, not only at the provider level.

The "complete" requirement addresses missingness and truncation. Datasets that contain systematic gaps, for example because certain categories of outcome were not recorded, or because data collection was discontinued for a subgroup, fail the completeness standard if those gaps affect the system's ability to perform its intended function fairly across the relevant population. Documentation must record known completeness issues and their expected effect on system outputs.

Why Deployers Cannot Treat Article 10 as Someone Else's Obligation

Article 10 is addressed to providers, and this allocation of formal responsibility is not contested here. However, the practical exposure of deployers to Article 10 deficiencies is substantial and operates through at least three distinct mechanisms.

The first mechanism is Article 26(1). Deployers are required to use high-risk AI systems in accordance with the instructions for use provided by the provider. Those instructions are the output of the provider's compliance work under Articles 9 through 15, including the data governance work under Article 10. A deployer who uses a system outside its documented intended purpose has violated Article 26(1) regardless of whether they were aware of the Article 10 documentation underlying those use conditions. The chain of accountability runs from provider to deployer through the instructions, not directly through Article 10.

The second mechanism is Article 26(5), which requires deployers to inform the provider when they have reason to believe that an incident or malfunction of the system constitutes a serious risk. If a deployer observes outputs that suggest bias or distributional shift, they have a reporting obligation that only makes sense if they have some familiarity with what the provider's Article 10 documentation said about bias risks and residual limitations. A deployer who cannot identify an Article 10-relevant incident because they never requested the relevant documentation is in a worse position when supervisors conduct their post-incident review.

The third mechanism is civil liability. The AI Liability Directive, still progressing through the legislative process at the time of publication, is expected to establish a rebuttable presumption of causation where a defendant has failed to comply with a duty of care that was specifically designed to prevent the harm that materialised. Deployers who failed to obtain and act on Article 10 disclosures in a domain involving discrimination or fundamental rights may find that presumption difficult to rebut.

Deployers should therefore treat Article 10 documentation as a procurement requirement, not a technical nicety. Before deploying any high-risk AI system in an Annex III category, they should request from the provider a summary of the bias examination conducted under Article 10(3), the statistical representativeness assessment conducted under Article 10(5), a description of any residual biases disclosed in the instructions for use, and the data lineage record required under Article 10(2). Where the provider cannot produce this documentation, the deployer should record that gap and assess whether it affects the conditions under which the system can be safely operated. For the methodology by which FP Certified assesses data governance across these dimensions, see agentcertified.eu/methodology.html.

The Insurance Dimension: Data Governance as Underwriting Evidence

AI liability insurers do not assess risk by reading model architecture papers. They assess it by evaluating the quality of the documentation trail that would allow them to reconstruct the causal pathway from a training or deployment decision to a harmful outcome. Article 10 documentation is central to that assessment for any high-risk AI system.

EIOPA's August 2025 opinion on the governance and risk management of AI in insurance identified training data quality and bias documentation as two of the five foundational risk indicators for AI system underwriting. The opinion noted that systems operating in Annex III categories without documented bias testing expose insurers to outcome uncertainty that cannot be priced because the counterfactual distribution of outputs under fair data conditions is unknown. This information gap is treated as a risk factor in its own right, separate from any demonstrated harm.

For Annex III systems in the employment, creditworthiness, and public service access categories, the consequences of undocumented training data bias are particularly acute from an insurance perspective. These are the categories where an AI output directly determines whether a named individual receives a job, a loan, or a benefit. When that determination is later challenged as discriminatory, the first legal question is whether the system's training data was examined for the bias that the claimant alleges. If the answer is that no such examination was documented, the insurer faces a coverage decision under conditions of factual uncertainty that they did not price when the policy was written.

Underwriting submissions for high-risk AI coverage in these categories increasingly include a data governance section that requires disclosure of the Article 10 documentation status. Deployers who cannot produce this information because their provider did not supply it face higher premiums, sublimits on discrimination-related claims, or exclusions for losses arising from undocumented data governance failures. The commercial incentive to obtain Article 10 documentation from providers before deploying a high-risk system is therefore not only regulatory but financial. For a practical overview of how to prepare an underwriting submission for AI agent coverage in Europe, see agentinsured.eu: preparing an AI agent underwriting submission in Europe.

The connection between Article 10 compliance and insurance pricing is likely to strengthen as the high-risk application deadlines approach and supervisory bodies accumulate enforcement experience. Deployers who establish Article 10 documentation practices now will be better positioned in the underwriting market than those who treat data governance as a provider-only concern. The regulatory and commercial trajectories point in the same direction: documented data governance is a condition of operating high-risk AI in Europe, and the absence of that documentation carries costs that manifest in both compliance proceedings and insurance terms.

For broader context on how deployer obligations are structured across Articles 9 through 29, see our companion guide on Article 26 and the complete set of deployer duties. For the risk management system obligations that run in parallel with the data governance requirements, see our analysis of Article 9 and the risk management system. For the text of the Regulation and its Annexes, see The Act, in plain sequence.

Frequently asked questions