Documenting Training Data Bias Examination for High-Risk Clinical AI Under the EU AI Act

What Article 10 requires of the examination

Article 10(1) applies to high-risk AI systems that train models with data. They must be developed on training, validation and testing datasets that meet the Article 10 quality criteria whenever such datasets are used. Article 10(2) adds that these datasets must be subject to data governance and management practices appropriate for the intended purpose of the system.

The practices must concern, in particular, data collection processes and the origin of data, including the original purpose of collection for personal data. They also cover data-preparation operations such as annotation, labelling, cleaning, updating, enrichment and aggregation, the formulation of assumptions about what the data are supposed to measure and represent, and an assessment of the availability, quantity and suitability of the datasets needed.

Three points matter most for bias. Point (f) requires examination in view of possible biases likely to affect the health and safety of persons, have a negative impact on fundamental rights or lead to prohibited discrimination under Union law. It stresses cases where data outputs influence inputs for future operations. Point (g) requires appropriate measures to detect, prevent and mitigate the biases identified under point (f). Point (h) requires identification of relevant data gaps or shortcomings that prevent compliance, and how they can be addressed.

For clinical AI, the Commission's guidance describes false positives or negatives that disproportionately affect groups defined by racial or ethnic origin, sex, age and other protected characteristics as a bias concern. That is a useful framing for the examination: the question is whether the data could lead the system to perform worse for some patients.

The elements of a defensible examination record

Treat the examination as an evidence artifact, not a one-time analysis. Organise it around the questions a regulator or auditor would ask, and map each element to the relevant Article 10(2) point so the link is visible without interpretation.

The structure below follows the points of Article 10(2) and adds the sign-off that makes the record defensible. The sign-off is a drafting recommendation, not a quoted legal requirement.

• 1. Scope and intended purpose: Identify the system, the clinical intended purpose and the training, validation and testing datasets covered. Article 10(2) requires practices appropriate to the intended purpose, so every later judgement refers back to it.
• 2. Origin, collection and preparation (points b and c): Record where the data came from, the original purpose of collection for personal data, and the annotation, labelling, cleaning, enrichment and aggregation applied.
• 3. Assumptions, availability and suitability (points d and e): State what the data are assumed to measure and represent, and assess the quantity and suitability of the datasets for the intended population and setting.
• 4. Bias risks examined (point f): List which risks were considered: health and safety, fundamental rights and prohibited discrimination. Note any feedback effects where system outputs are reused as data, and where the dataset boundary sits.
• 5. Mitigation and data gaps (points g and h): Document the measures to detect, prevent and mitigate each identified bias, the data gaps found, and how each will be addressed.
• 6. Residual risk and sign-off: Record what risk remains after mitigation, who accepted it, on what date, and against which version of the datasets.

Placing the record in the technical documentation

Technical documentation must be drawn up before the system is placed on the market or put into service, and it must be kept up to date. The examination record therefore has two timing consequences. It must exist in finished form before market placement, and it must change when the datasets change.

The practical approach is to hold the examination record as a controlled document that the technical documentation references by version. When a dataset is refreshed, relabelled or extended, the record is reopened, the affected elements are re-examined, and a new sign-off is issued. This avoids a common failure, in which the documentation describes a dataset that no longer matches the one in use.

For clinical AI that is also a medical device, teams will want one coherent file rather than parallel sets of documents. Align the examination record with existing quality and risk management files so reviewers see consistent statements about intended purpose, population and residual risk. Each regime keeps its own requirements, so confirm with regulatory counsel how the records should be cross-referenced.

Ownership, cadence and special category data

Assign a named owner for each Article 10(2) element rather than one owner for the whole record. The provider owns dataset documentation. A deployer that supplies input data has a documented responsibility for making sure that data is relevant and sufficiently representative for the intended purpose, and it should record how it assessed this.

Tie the review cadence to the duty to keep technical documentation up to date. A scheduled periodic review is useful, but the stronger control is an event trigger: any change to a training, validation or testing dataset reopens the record.

Special category data needs its own entry. The consolidated text of the Regulation dated 27 July 2026 states that, to the extent strictly necessary for bias detection and correction under Article 10(2) points (f) and (g), providers may exceptionally process special categories of personal data, subject to appropriate safeguards for fundamental rights and freedoms. If your examination relied on such data, the record should explain why it was strictly necessary and what safeguards applied. Health data is the most likely case in clinical AI, so legal review of this entry is worthwhile.

On timing, the Digital Omnibus on AI proposes delayed high-risk application dates. The Commission proposed fixed deadlines of 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for systems embedded in products, and Council and Parliament reached a provisional agreement on 7 May 2026. As of November 2026, plan against the dates in the final adopted text, and do not let the possible delay stop the examination work, since the record takes time to build.

Where dataset documentation ends and runtime evidence begins

The examination record describes the data used to build and test the system before it is deployed. It shows that the provider looked for bias, decided what to do about it and accepted a residual risk. It cannot show what the deployed system did in a given clinical workflow, because that depends on live inputs, configuration and the actions the system attempted.

The Commission's guidance says high-risk systems must be traceable and auditable, with documentation that includes the data used to train the algorithm, which is key in ex-post investigations. Both halves matter in an investigation: the dataset record explains how the system was built, and runtime evidence explains what happened in operation.

Keeping the two artifacts separate also keeps ownership clear. The provider's data governance process produces the first. The second comes from controls running in the deployed environment. Neither should be presented as a substitute for the other, and an auditor will test the boundary between them.

What policy enforcement adds at runtime

Trussed does not provide dataset provenance or lineage and does not perform bias testing. Origin, preparation and bias examination evidence must come from the provider's own data governance process, and nothing in this guide implies otherwise.

What Trussed provides begins after deployment. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Each interaction can be allowed, redacted, blocked, rate limited or escalated for human approval, enforced at runtime, not reviewed after the fact. That enforcement produces audit-ready evidence, mapped to the EU AI Act among other regimes, of what an AI system was allowed to do and what it did.

For a clinical AI provider or deployer, this complements the dataset record. The examination record shows how the data was assessed. Runtime evidence shows how the system behaved under the policies that applied to it, including which actions were escalated for human approval. Trussed runs in production with healthcare and pharma organizations, deployed self-managed in the customer cloud with configurable retention and data residency.