Article 10 read as a work programme

Article 10 is the provision that most often turns a confident high-risk project into a six-month archaeology exercise. It is written as a list of practices, and it is best read as a list of things that must have been true while the dataset was being built. Almost none of it can be reconstructed afterwards.

The seven practices in 10(2)

Training, validation and testing datasets must be subject to data governance and management practices appropriate to the intended purpose, covering:

• (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 preparation operations, including annotation, labelling, cleaning, updating, enrichment and aggregation;
• (d) the formulation of assumptions, in particular 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, safety or fundamental rights, or to lead to unlawful discrimination;
• (g) appropriate measures to detect, prevent and mitigate those biases.

Point (d) is the one practitioners underrate. Assumptions about what the data measures are where most insurance and banking models go wrong, and they are almost never written down. A claims dataset does not record fraud; it records fraud that was detected and recorded as such by a process with its own biases. A collections dataset does not record ability to pay; it records who was contacted and how. Writing the assumption down is uncomfortable precisely because it exposes the gap between the label and the thing.

Point (b) has a sharp edge for personal data. The original purpose of collection has to be recorded, which means repurposing a customer dataset collected for policy administration into a training set is a documented decision with a lawful basis question attached, not a data engineering task.

10(3): representativeness, and what "to the best extent possible" actually concedes

Datasets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose, with the appropriate statistical properties, including as regards the persons or groups the system is intended to be used on.

Two things follow. First, representativeness is measured against the population the system will be used on, not against the population that happened to generate the historical data. If a bank is expanding into a segment it has not lent to, its historical data is by definition unrepresentative of the new deployment, and saying so in the record is the correct move.

Second, "to the best extent possible" qualifies errors and completeness, not relevance and representativeness. It is a concession that no real dataset is clean. It is not a general softener for the whole sentence, and reading it as one is how a record ends up saying nothing.

10(4): the setting

Datasets must consider, to the extent required by the intended purpose, the characteristics or elements particular to the specific geographical, contextual, behavioural or functional setting in which the system is to be used.

This is the provision that kills the cross-border model transfer. A fraud model trained on one country's payment behaviour and deployed in another has a setting problem that no amount of accuracy testing on the original data will reveal. The same applies within a country across distribution channels: a model trained on broker-originated business behaves differently on direct business because the population reaching it was filtered differently.

10(5): special category data as a narrow exception

Special category personal data may be processed to the extent strictly necessary for bias detection and correction, subject to appropriate safeguards. This is an exception, not a licence. The practical controls are: collect only what the specific test needs, hold it separately with restricted access, prohibit its use as a model feature, and set a deletion date at the point of collection.

The failure mode is predictable. Ethnicity data is collected for a fairness audit, lands in the general feature store, and eighteen months later appears in an unrelated model because it improved a metric. At that point the exception has become the opposite of the safeguard.

Worked example: an insurer inherits a dataset it cannot document

A health insurer has a claims propensity model built in 2021 by a team that has since dissolved. It works, it is in production, and it is now within Annex III 5(c) because it feeds pricing. The governance team opens the Article 10 record and finds a training table and a notebook.

Points (a), (c) and (d) are gone. Nobody can state the design choices, the cleaning steps or the assumptions, and reconstructing them from the notebook would produce a plausible narrative rather than a record. The honest options are to document what can be evidenced, record explicitly what cannot, and decide whether the gap is acceptable, or to rebuild the dataset with the practices applied from the start.

The insurer does both, in sequence. It writes a record that states the limitation in terms, because an auditor finding an admitted gap forms a different view of the organisation than one finding an invented history. It then rebuilds, and the rebuild surfaces the finding that mattered: a cleaning step dropped claims with missing occupation codes, and occupation was missing far more often for one distribution channel. The 2021 model had been trained on a filtered population for four years.

Nobody would have found that from the model. It was found from point (c).

As of 24 September 2026.