Module 4 — Data Governance You Can Evidence (Art. 10)

Module 4 of AI Risk Management Pro: Art. 10 as evidence — provenance, collection purpose, representativeness against the intended population, error and completeness, bias examination and mitigation, and the narrow Art. 10(5) permission for special-category data.

Art. 10 is the obligation that cannot be retrofitted. A risk register can be written after the fact; an Annex IV file can be assembled from artefacts that already exist; but data governance evidence for a dataset assembled two years ago without provenance records is not a writing exercise, it is an archaeology project that frequently fails. This is why Module 1 insisted that a programme begun in late 2027 does not arrive in time for December 2027.

What Art. 10 actually asks

Art. 10(1) applies to high-risk systems that involve the training of models with data: training, validation and testing datasets must be subject to the data governance and management practices appropriate for the intended purpose.

Art. 10(2) lists what those practices concern. Read as a checklist of things you must be able to describe:

• (a) the relevant design choices;
• (b) data collection processes and the origin of the data, and for personal data the original purpose of collection;
• (c) relevant data preparation operations — annotation, labelling, cleaning, updating, enrichment, aggregation;
• (d) the formulation of assumptions, notably about what the data is supposed to measure and represent;
• (e) an assessment of the availability, quantity and suitability of the datasets needed;
• (f) examination in view of possible biases likely to affect health and safety, have a negative impact on fundamental rights, or lead to prohibited discrimination — especially where outputs influence future inputs;
• (g) appropriate measures to detect, prevent and mitigate those possible biases;
• (h) identification of relevant data gaps or shortcomings that prevent compliance, and how they can be addressed.

Then Art. 10(3): datasets shall be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Art. 10(4): account shall be taken, as appropriate, of the geographical, contextual, behavioural or functional setting in which the system is to be used.

Note the two qualifiers in 10(3). The obligation is not a guarantee of perfect data. It is a duty to be relevant and representative, and to pursue accuracy and completeness as far as reasonably achievable for the stated purpose. A programme that claims error-free data is claiming something it cannot evidence and that the law does not ask for.

Representativeness is a claim about a population

This is the single most useful reframing in the module. "Representative" is meaningless without naming what the data is meant to represent. So the evidence has to begin with a declared intended population, and then compare.

Worked example. A system screens applications for a graduate programme across the EU. The intended population is EU-resident applicants with a first degree, across all 27 member states. The training data is five years of the firm's own applications. The comparison surfaces immediately:

None of those rows is a failure of the organisation. Every one of them is Art. 10(2)(h) — identified gaps — and Art. 10(2)(d) — assumptions about what the data represents — done correctly. The gaps become rows in the Module 3 register with mitigations and owners. An honest gap analysis is compliance; an absent one is the finding.

Bias examination with a result

Art. 10(2)(f) requires examination; (g) requires measures. Practitioners get two things wrong.

First, examination needs a protected attribute to examine against — which is exactly what you usually do not hold, and often must not hold. That is the problem Art. 10(5) exists to solve, and it is covered below.

Second, "we checked for bias" is not a result. A result names the metric, the groups compared, the threshold applied and the outcome. Pick a small number of measures and state them:

• Selection rate parity across groups (and the ratio between them).
• Error rate parity — false positive and false negative rates by group, which is usually the one that matters for a decision that denies something.
• Calibration — does a score of 0.7 mean the same thing for each group.

These measures conflict with one another mathematically; you cannot satisfy all of them at once except in degenerate cases. That is not a loophole, it is a design decision, and the defensible move is to state which measure you optimised for and why, given the intended purpose. A credit decision and a medical triage have different answers.

Also from (f): "especially where outputs influence future inputs". Feedback loops deserve their own register row. A screening model whose accepted candidates become next year's training data will amplify whatever it started with.

Art. 10(5), read strictly

To examine bias you may need special-category data under Art. 9 GDPR. Art. 10(5) permits processing it, and the permission is narrow enough that the conditions are the substance:

• only to the extent strictly necessary for the purpose of ensuring bias detection and correction;
• only where other means cannot suffice, including synthetic or anonymised data;
• subject to technical limitations on re-use and state-of-the-art security and privacy measures;
• pseudonymisation, or anonymisation where that allows the purpose to be achieved;
• strict controls and documentation of access, so that the data is accessed only by authorised persons with appropriate confidentiality obligations;
• no transmission, transfer or other access by third parties;
• deletion once the bias has been corrected or the personal data has reached the end of its retention period.

Operationally this means: a documented necessity assessment including why synthetic or anonymised alternatives were rejected, a named and time-boxed access list, a separated environment, and a deletion record. Art. 10(5) is not a reason to start collecting protected attributes broadly; it is a controlled, evidenced exception for a specific examination. And it does not displace the GDPR — you still need a lawful basis and, in practice, a DPIA.

What a deployer should demand instead

If you did not train the model, Art. 10 is not yours. What is yours is the evidence you need for Art. 26 and for your own register. Ask the provider for:

1. The intended purpose and intended population as the provider defines them — then compare against your population. A system representative of its intended population may be unrepresentative of yours, and that is your risk, not a provider defect.
2. The performance characteristics and limitations under Art. 13(3)(b), including accuracy metrics and, where available, by relevant subgroup.
3. The known gaps and shortcomings the provider identified under Art. 10(2)(h).
4. Input data specification under Art. 13(3)(b)(vi) — Art. 26(4) obliges you to ensure input data is relevant and sufficiently representative, which you cannot do without knowing what the system expects.

A vendor who cannot answer 1 and 2 is a register row, not a blocker to be argued about internally.

What the file has to contain

The Data Governance Checklist template included with this track lays out one sheet per Art. 10(2) limb with an evidence location and a completeness state, plus the intended-population comparison and the Art. 10(5) necessity record. The structure matters more than the tool: Annex IV element 2(d) will ask for the data requirements, the datasheets describing training methodologies and techniques and the datasets used, including provenance, scope and main characteristics. Module 5 assembles exactly that.

Check yourself

1. Art. 10 requires error-free data. — No. Art. 10(3) says "to the best extent possible... in view of the intended purpose". The duty is relevance, representativeness and reasonable pursuit of accuracy.
2. We have no protected attributes, so we cannot examine bias. — Art. 10(5) exists for this, under strict conditions and with the necessity documented. Not examining at all is not an option Art. 10(2)(f) leaves open.
3. We satisfied all three fairness metrics. — Mathematically unlikely. State which you optimised for, and why, given the intended purpose.
4. We buy the model, so Art. 10 is the vendor's problem. — True, and insufficient. You still owe Art. 26(4) on input data, and a vendor who cannot describe performance against your population is a risk row.

Next: Module 5 — The Annex IV technical file →