Data Governance Requirements for High-Risk AI (Article 10)

Article 10 is usually paraphrased as “use good data”. It is considerably more specific than that: eight named governance practices, four named quality criteria, a contextual-setting requirement, and an express and heavily conditioned permission to process special category data for bias correction.

Which systems it binds, including untrained ones

Article 10(1) of Regulation (EU) 2024/1689 applies to high-risk systems which make use of techniques involving the training of AI models with data: those must be developed on the basis of training, validation and testing data sets meeting the criteria in paragraphs 2 to 5.

Article 10(6) then handles the case everybody forgets. For high-risk systems not developed using techniques involving the training of models, paragraphs 2 to 5 apply only to the testing data sets. A rule-based expert system in a high-risk domain is not outside Article 10; it owes the governance and quality duties in respect of the data it is tested on. That is a smaller obligation but not a nil one, and the assumption that Article 10 is a machine learning provision is wrong.

The obligation attaches to the provider of the high-risk system. Where the system is built on a general-purpose model obtained from someone else, the provider of the high-risk system still owes Article 10 in respect of the data sets used to develop and test their system, while the upstream model provider owes the separate Chapter V duties. The two do not substitute for each other, and the practical difficulty of satisfying Article 10 about data you did not collect is real — it is one reason the Chapter V documentation duties exist.

The eight governance practices

Article 10(2) requires that the data sets be subject to data governance and management practices appropriate for the intended purpose, concerning in particular eight named items. This is the checklist, and it maps almost directly onto document sections.

• (a) The relevant design choices.
• (b) Data collection processes and the origin of the data, and in the case of personal data, the original purpose of collection. Provenance is an express requirement, not an inferred one, and the original-purpose element ties directly to GDPR purpose limitation.
• (c) Relevant data preparation operations — the article names annotation, labelling, cleaning, updating, enrichment and aggregation.
• (d) The formulation of assumptions, notably with respect to the information the data are supposed to measure and represent. This is the most intellectually demanding item on the list: it asks you to write down what you believe your proxy is a proxy for.
• (e) An assessment of the availability, quantity and suitability of the data sets needed.
• (f) Examination in view of possible biases likely to affect health and safety of persons, to have a negative impact on fundamental rights, or to lead to discrimination prohibited under Union law — especially where data outputs influence inputs for future operations. That final clause is a feedback-loop requirement, and it is directly relevant to any system whose own decisions generate its next training set.
• (g) Appropriate measures to detect, prevent and mitigate the biases identified under (f).
• (h) Identification of relevant data gaps or shortcomings that prevent compliance, and how those gaps can be addressed.

Item (h) deserves attention because it is an obligation to record what you could not do. A file that documents only successes has not satisfied it.

The four quality criteria in Article 10(3)

Article 10(3) requires training, validation and testing data sets to be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Each criterion carries its own qualifier, and the qualifiers are the point.

• Relevant — unqualified.
• Sufficiently representative — sufficiency is judged against the intended purpose, not in the abstract.
• To the best extent possible free of errors and complete — an effort standard rather than an absolute one. Perfect data is not required; demonstrating that you did what was possible is.

The paragraph continues that the data sets shall have the appropriate statistical properties, including, where applicable, as regards the persons or groups of persons in relation to whom the high-risk system is intended to be used. And it adds a practical concession: those characteristics may be met at the level of individual data sets or at the level of a combination thereof. A single unrepresentative constituent set is not automatically a breach if the combination is sound, which matters for anyone assembling from multiple sources.

The geographic and contextual requirement

Article 10(4) requires that data sets take into account, to the extent required by the intended purpose, the characteristics or elements particular to the specific geographical, contextual, behavioural or functional setting within which the system is intended to be used.

This is the provision that bites hardest on imported systems. A creditworthiness model trained on one country’s population and deployed in another, a triage tool trained on one health system’s coding conventions and used under another, a document classifier trained on one legal tradition’s drafting — each has a live Article 10(4) problem that no amount of aggregate accuracy answers. It is also the provision most naturally satisfied by narrowing the stated intended purpose, since the requirement is scoped to what that purpose requires. Narrowing the intended purpose narrows the obligation, and it simultaneously narrows what the provider may market the system for. That trade is a genuine design decision rather than a paperwork one.

The special-category permission in Article 10(5)

Article 10(5) addresses the tension the rest of the article creates: you cannot examine for bias against a protected characteristic without data about that characteristic, and such data is a special category under GDPR Article 9. The paragraph permits providers exceptionally to process special categories of personal data to the extent strictly necessary for the purpose of ensuring bias detection and correction, subject to appropriate safeguards including a list of conditions.

The conditions are cumulative and they are demanding. Bias detection must not be effectively achievable by processing other data, including synthetic or anonymised data. Technical limitations on re-use and state-of-the-art security and privacy-preserving measures, including pseudonymisation, must apply. Access must be strictly controlled and documented. The data must not be transmitted, transferred or otherwise accessed by other parties. It must be deleted once the bias has been corrected or the retention period ends, whichever is first. And the record of processing activities must state why the processing was strictly necessary.

Read those together and Article 10(5) is a narrow, auditable, deletable permission, not a general licence to collect demographics. The synthetic-and-anonymised-alternatives condition in particular means the file has to show that the alternatives were considered and were inadequate.

Article 5(1)(g)’s carve-out for labelling and filtering of lawfully acquired biometric datasets operates alongside this, and the two are designed to interlock: see the biometric categorisation prohibition. On the GDPR side, the same activity has to survive data minimisation applied to training data. Everything documented here also has to appear in the technical file: Annex IV point 2(d) requires datasheets describing the training methodologies and data sets, their provenance, scope and main characteristics, how the data was obtained and selected, labelling procedures and cleaning methodologies. See the Article 11 and Annex IV requirements.