EU AI Act Article 10: What the Training Data Requirements Mean for Pharma Data Teams

What Article 10 Says, and When It Actually Applies

Article 10 is titled “Data and data governance.” It is short, roughly one page of legal text, and it is the single most operationally demanding clause in the high-risk chapter of the EU AI Act for anyone who owns data pipelines. Risk management (Article 9), technical documentation (Article 11), record-keeping (Article 12), and human oversight (Article 14) all have recognizable analogues in a pharma quality system. Article 10 does not.

The clause in plain terms

Paragraph 1 sets the trigger: high-risk AI systems that involve training models with data must be developed on the basis of training, validation, and testing datasets that meet the quality criteria in paragraphs 2 through 5.² That framing matters. The obligation attaches to the datasets, not to the model, and it attaches to all three splits, not only the training set.

Paragraph 2 requires that those datasets be subject to data governance and management practices appropriate to the intended purpose, and then lists eight specific practices those governance arrangements must cover: design choices; data collection processes and the origin of the data; data preparation operations such as annotation, labeling, cleaning, updating, enrichment, and aggregation; the assumptions made about what the data measures and represents; an assessment of the availability, quantity, and suitability of the datasets needed; an examination for possible biases likely to affect health and safety, negatively affect fundamental rights, or lead to discrimination prohibited under Union law; measures to detect, prevent, and mitigate those biases; and the identification of relevant data gaps or shortcomings that prevent compliance, together with how those gaps can be addressed.²

Paragraph 3 is the sentence that gets quoted most often and understood least: datasets shall be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Paragraph 4 adds that datasets must account for characteristics particular to the specific geographical, contextual, behavioral, or functional setting in which the system is intended to be used. Paragraph 5 gives providers a narrow, safeguarded legal basis to process special categories of personal data where that is strictly necessary to detect and correct bias. Paragraph 6 confirms that for high-risk systems that do not involve training a model, the data governance requirements apply to the testing datasets only.²

Recital 67 puts the intent plainly: data quality is essential for high-risk AI to perform safely, and the requirements are meant to make sure the datasets are good enough for the specific purpose the system is being placed on the market for.⁷ The legislator did not attempt to define an absolute quality bar. Everything is anchored to intended purpose. That is both the flexibility and the trap, because a purpose defined loosely produces acceptance criteria that cannot be tested.

The date most people still have wrong

Through 2025 and into 2026, the working assumption across life sciences was that the high-risk obligations, Article 10 among them, would apply from 2 August 2026. That is no longer correct.

The Commission proposed a simplification package in November 2025. The Council and the European Parliament reached political agreement on the AI-related part of that package in May 2026, and the Digital Omnibus on AI was formally adopted by the Council on 29 June 2026 and entered into force on 27 July 2026, just before the original date.¹⁸ The effect on timing is straightforward:

What did not move is worth naming, because several teams have read “delay” as “nothing happens in 2026.” The transparency obligations stayed on their original schedule, with a limited grace period into December 2026 for marking machine-generated content in systems already on the market. The prohibitions and the AI literacy duty have applied since February 2025. General-purpose AI model obligations have applied since August 2025. The governance and penalties provisions, including the role of the AI Office and the national market surveillance authorities, have applied since 2 August 2025.¹ The supervisory machinery is live. Only the substantive high-risk requirements moved.

The one substantive change to Article 10 itself

The Omnibus left the data quality criteria in Article 10 alone. What it changed was paragraph 5. The permission to process special categories of personal data for the purpose of detecting and correcting bias, which previously sat only with providers of high-risk AI systems, now extends more broadly, subject to a strict necessity standard and a set of safeguards: preference for non-sensitive or synthetic data where that would work, pseudonymization, access controls, no onward transmission, and deletion once the bias work is done.¹⁰¹¹

Read that carefully, because it cuts both ways. It removes a genuine legal obstacle that had made bias examination difficult for teams working with health data under the GDPR. It does not create an obligation to perform bias detection where none existed. And it does not relieve anyone of the Article 10(2)(f) duty where the system is high-risk. For a pharma data team, the practical reading is: the legal basis you were told you did not have for holding protected attributes long enough to test for bias is now clearer, and the safeguards you must wrap around that processing are now specified.

Which Pharma AI Systems Are Actually High-Risk

This is the question that should be answered before a single acceptance criterion is written, and in most organizations it has not been. Data teams are being handed a compliance mandate for a population of systems nobody has enumerated. The result is either paralysis or the opposite failure, where a team applies Article 10 rigor to every model in the estate and exhausts itself producing evidence for systems that were never in scope.

There are exactly two routes into high-risk classification, and a filter that can pull a system back out.

Route one: AI inside a regulated product

Under Article 6(1), an AI system is high-risk when it is a safety component of a product, or is itself a product, covered by the Union harmonization legislation listed in Annex I, and that product must undergo a third-party conformity assessment before being placed on the market.³ For life sciences this is mostly the Medical Devices Regulation and the In Vitro Diagnostic Regulation. The Machinery Regulation was moved from Section A to Section B of Annex I by the Omnibus, so AI performing a safety function on production equipment no longer triggers the substantive high-risk regime through that route.

The Omnibus narrowed the definition of “safety component” by adding that the component must have the intended purpose of preventing or mitigating risks to health and safety.⁹ That is a meaningful tightening. A model that optimizes throughput on a filling line is not a safety component simply because it runs on equipment that has safety functions. A model that decides when to halt a line to prevent harm probably is.

For a pharma or biotech company, this route usually bites in one of three places: a companion diagnostic or a diagnostic algorithm the company owns; software the company develops that meets the definition of a medical device; and AI performing a safety function on machinery covered by the Machinery Regulation. The Omnibus also empowers the Commission to adopt delegated acts limiting AI Act requirements where sectoral product legislation already provides equivalent protection, with the Machinery Regulation called out specifically.⁹

Route two: the Annex III list

Article 6(2) makes any system falling within Annex III high-risk by default. Annex III has eight headings: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private services and public services and benefits; law enforcement; migration, asylum, and border control; and administration of justice and democratic processes.⁴

Notice what is not there. There is no heading for drug discovery, clinical development, manufacturing, supply chain, pharmacovigilance, or regulatory affairs. Annex III is organized around AI that makes consequential decisions about individual people, not around AI that supports the development of a product.

Three Annex III entries do reach into life sciences organizations, and two of them catch companies that assume they are outside the Act entirely:

• Employment and worker management. AI used to place job advertisements, filter applications, evaluate candidates, allocate tasks, monitor performance, or influence promotion and termination decisions is high-risk.⁴ Almost every large pharma company runs one of these. It is usually owned by human resources, procured from a vendor, and entirely absent from the AI inventory that IT or quality maintains.
• Life and health insurance risk assessment and pricing. Relevant to any group in the organization doing this, and directly relevant if the company operates a health benefits or patient support arrangement with underwriting characteristics.⁴
• Emergency call classification, dispatch priority, and patient triage systems. This is the entry that catches patient-facing services. A medical information line that classifies incoming contacts by urgency, or a patient support program that triages symptom reports, needs a careful read against this heading.⁴

The Article 6(3) filter, and the paperwork it still creates

Article 6(3) lets a system that falls under an Annex III heading escape high-risk status if it does not pose a significant risk of harm to health, safety, or fundamental rights, and if it meets one of four conditions: it performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision-making patterns or deviations from prior patterns without replacing or influencing the earlier human assessment absent proper human review; or it performs a preparatory task to an assessment relevant to the Annex III use case. A system that performs profiling of natural persons is always high-risk regardless.³

The filter is real and it is useful. It is also not free. Article 6(4) requires the provider to document that assessment before the system is placed on the market, and to make that documentation available to national authorities on request. In other words, deciding that a system is out of scope is itself a documented decision with an evidence trail. Teams that quietly conclude “this one is fine” without recording the reasoning have created an audit finding, not an exemption.

Provider or deployer changes what you owe

Most pharma and biotech companies are deployers, not providers. They buy AI systems and put them into use rather than developing and placing them on the market under their own name. Article 10 in full applies to providers. Deployers get a shorter but pointed obligation in Article 26(4): where the deployer exercises control over the input data, it must ensure that input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system.⁵ Deployers also have to use the system according to the instructions, monitor its operation, suspend use and notify the provider where they suspect a risk, and keep the system’s automatically generated logs for at least six months.

“Relevant and sufficiently representative” appears in both Article 10(3) and Article 26(4). The words are the same, the scope is narrower for the deployer, and the measurement problem is identical. A deployer that fine-tunes a purchased model on its own data, or that supplies the reference data the model reads at inference time, is squarely inside this obligation. A deployer that materially modifies a high-risk system, or puts it on the market under its own name, can become a provider and inherit the whole of Article 10.

A working scoping table

The table below is a starting position, not a legal opinion. Classification depends on the specific intended purpose written into the system’s documentation, and reasonable people disagree at the margins. Industry has pressed this point directly: EFPIA has argued that the majority of AI used in medicines research and development is neither regulated under Annex I nor listed in Annex III, and therefore cannot qualify as high-risk under the Act.¹²¹³ Commentators have noted that the sector has been waiting some time for clearer guidance on exactly where the boundary sits.¹⁴

Article 10 Clause by Clause: From Legal Text to Acceptance Criteria

Here is the practical problem. Article 10 is written in the register of European product safety law. It says datasets shall be “relevant,” “sufficiently representative,” and “to the best extent possible, free of errors and complete.” A data engineer cannot run “sufficiently representative.” A quality reviewer cannot approve it. An inspector cannot verify it. Somebody has to convert each phrase into a number, a threshold, and a document.

That conversion is the work. The table below does it clause by clause. For each provision it names the data quality dimension being measured, a testable acceptance criterion of the kind a team can actually write into a data validation plan, and the evidence artifact that demonstrates the criterion was met. The thresholds shown are illustrative placeholders. The right values come from the intended purpose and the risk assessment for the specific system, and setting them is a decision that should be made and recorded before testing begins, not fitted afterward.

Annex IV, which sets out what the technical documentation must contain, closes the loop. It requires a description of the training, validation, and testing datasets, their provenance, scope and main characteristics, how the data was obtained and selected, and the labeling and cleaning methods used.⁶ The artifacts in the right-hand column are not extra work invented for the sake of tidiness. They are the source material for a documentation pack you will have to produce anyway.

Where Article 10 Meets ALCOA+, and Where It Does Not

Pharma data teams do not start from zero here. They start with two decades of muscle memory built on ALCOA+ and 21 CFR Part 11. The instinct to map Article 10 onto that existing frame is correct, and it will get a team most of the way. It is the remainder that causes trouble, because the gap is not small and it is not the kind of gap that closes by working harder at things you already do well.

The overlap is real and worth claiming

ALCOA is attributable, legible, contemporaneous, original, and accurate. The plus adds complete, consistent, enduring, and available, and the MHRA’s GxP data integrity guidance sets out what each means in a regulated setting.¹⁷ A pharma organization that genuinely meets these across its data estate has already built much of what Article 10(2)(a) through (e) asks for, though it has usually built it for records rather than for datasets.

The two demands ALCOA+ never made

Strip the table down and two genuinely new obligations remain. Both are about the relationship between the data and the world, and neither can be satisfied by better record-keeping.

Representativeness. ALCOA+ is a set of properties of a record. A record can be perfectly attributable, contemporaneous, original, and accurate, and still describe a population that looks nothing like the population the model will be used on. A dataset assembled from three European sites can be flawless by every data integrity measure and still be unfit for a system intended for use across twenty countries. Article 10(3) and 10(4) ask a question data integrity has never asked: compared to what? Answering it requires naming a reference population, which is a scientific and commercial judgment, not a data engineering task. This is the single most common reason a representativeness statement stalls. Nobody wants to own the definition.

Bias examination. Article 10(2)(f) requires examining datasets for biases likely to affect health and safety, negatively affect fundamental rights, or lead to prohibited discrimination. There is no GxP analogue at all. Twenty-one CFR Part 11 governs electronic records and electronic signatures: it is concerned with authenticity, integrity, and, where appropriate, confidentiality.¹⁸ A system can be fully Part 11 compliant and systematically underperform for a subgroup, and nothing in Part 11 would surface that. The examination Article 10 asks for is a different discipline with different methods and, usually, different people.

Regulators outside the AI Act are converging on the same point

This is not only a European product safety concern. The EMA’s reflection paper on the use of AI in the medicinal product lifecycle flags data quality and representativeness for small populations directly, noting that the need to over-sample rare populations should be considered and warning of risks of bias and other discrimination against non-majority genotypes and phenotypes, and expecting data sources and processing to be documented in a way that supports traceability consistent with GxP.¹⁹²³ Draft Annex 22 of the EU GMP guide asks for a characterization of the model’s input data sample space, an assessment of limitations and possible biases, and division into subgroups where relevant so that each is sufficiently represented in the test data.¹⁵²⁰

The FDA has taken a parallel route through its draft guidance on using AI to support regulatory decision-making for drug and biological products, which sets out a risk-based credibility assessment framework tied to a specific context of use, informed by the agency’s review of more than 300 submissions containing AI or machine learning components.²¹²⁴ Different legal instrument, different vocabulary, same underlying demand: state what the model is for, show the data fits that purpose, and produce the evidence.

The Evidence Package a Data Team Can Actually Produce

Compliance conversations tend to end at principles. What survives an inspection is a set of documents that exist, are versioned, and can be produced within an hour. Below are the six artifacts that carry most of the weight for Article 10. They are deliberately small. Six documents that are current and honest are worth more than a thirty-document framework that is eighteen months stale.

Two practices make these documents hold up better than they otherwise would.

The first is independence between the people who build the training data and the people who evaluate the test results. Draft Annex 22 is unusually specific about this, describing access controls, audit trails, and a requirement that staff involved in developing and training the model have never had access to the test data, with a four-eyes review by a colleague who has not had that access where separation is not possible.¹⁵ Article 10 does not spell it out, but the requirement that testing datasets meet the same quality criteria as training data points the same way. If the same person assembles the training set and decides whether the test result is acceptable, the test is not independent and the evidence is weak.

The second is treating dataset versions as controlled items. A dataset is not a file. It is a specific extraction, at a specific time, transformed by a specific version of a pipeline. If a regulator asks in 2029 why a model behaved the way it did in 2027, the answer requires reconstructing the exact dataset. Teams that version code but not data discover this late and cannot recover.

One Evidence Set, Two Regulators

The strongest practical argument for doing this work now, rather than waiting for December 2027, is that almost none of it is unique to the AI Act.

A pharma organization deploying AI in a GMP setting is already heading toward draft Annex 22, which asks for a characterized input sample space, predefined metrics, independent test data, subgroup performance, change control, and ongoing monitoring of both performance and the input space.¹⁵²⁰ The same organization submitting AI-derived evidence to the FDA is heading toward the credibility assessment framework, which asks it to state the context of use, assess model risk, and gather credibility evidence proportionate to that risk.²¹ The same organization operating a high-risk system in the EU is heading toward Article 10.

Three regulatory instruments, three vocabularies, one underlying evidence set. The dataset specification, lineage record, preparation protocol, representativeness statement, bias report, and gap register serve all three. What differs is the wrapper and the audience, not the substance.

Where the instruments genuinely diverge is worth knowing so nothing is missed:

• Fundamental rights. Article 10(2)(f) explicitly names fundamental rights and prohibited discrimination as harms to examine for. Annex 22 and the FDA framework are concerned with product quality, patient safety, and the reliability of evidence. A bias examination built only for GMP purposes will look at clinical subgroups and miss protected characteristics.
• Scope of models covered. Draft Annex 22 is aimed at static, deterministic models in critical GMP applications, and the draft itself states that it does not apply to generative AI and large language models, and that such models should not be used in critical GMP applications.¹⁵ The AI Act draws no such line. A high-risk system built on a general-purpose model is fully in scope.
• Who owes the evidence. GxP obligations sit with the regulated company. AI Act obligations split between provider and deployer, and the split is not intuitive. A company can be a GMP-regulated manufacturer and an AI Act deployer at the same time, owing different evidence under each.

A Sequence for the Runway You Now Have

The deferral to December 2027 is genuinely useful, but only for organizations that use it. The sequence below is ordered by dependency, not by ease. Each step produces something the next one needs.

One practical note on standards. Because none of the harmonized standards supporting the high-risk requirements have been published and cited in the Official Journal yet, no organization can rely on the presumption of conformity today.¹⁶ That is not a reason to wait. It is a reason to build on the closest published international standards, ISO/IEC 5259 for data quality among them, so that when the harmonized standards arrive the mapping is a translation job rather than a rebuild.

Failure Modes Worth Naming Early

The patterns below come up repeatedly in organizations that are doing serious work and still going wrong. Naming them early is cheaper than finding them in an assessment.

Treating the deferral as a pause

The most common response to the December 2027 date has been to move the work down the priority list. The pipeline remediation that Article 10 requires runs on a multi-quarter clock. Provenance that was never captured cannot be captured retrospectively. Subgroup attributes that were never collected cannot be recovered from a warehouse. The organizations that will be ready in December 2027 are the ones that started in 2026.

Scoping by anxiety instead of by rule

Two opposite errors, both driven by the same underlying uncertainty. Some teams decide everything is high-risk and try to produce Article 10 evidence for every model in the estate, which guarantees that nothing gets done properly. Others decide that because pharma is not named in Annex III nothing applies, and miss the recruitment tool and the patient triage service entirely. The rule is narrow and readable. Apply it, and write down what you concluded.

Defining intended purpose too broadly

“Support clinical decision-making” is not an intended purpose. It cannot be tested against, which means no acceptance criterion derived from it can be tested either. A usable purpose statement names the population, the setting, the decision the output feeds, and the boundaries of use. Broad purpose statements feel safer commercially and are far riskier in an assessment, because they widen the population the data has to be representative of.

Confusing a bias policy with a bias examination

Article 10(2)(f) requires an examination. An examination produces numbers: dataset composition by subgroup, model performance by subgroup, and a comparison against a limit set in advance. A commitment to fairness, however sincerely written, produces none of those. This distinction is where the largest volume of remediation work usually sits.

Forgetting the deployer obligation

Companies that buy rather than build often assume Article 10 is entirely the vendor’s problem. Article 26(4) puts the input data obligation on the deployer wherever the deployer controls that data, using the same “relevant and sufficiently representative” language.⁵ If your organization supplies the reference data, the lookup tables, the site master data, or the fine-tuning set, that obligation is yours.

Leaving the reference population undefined

Every representativeness assessment needs a comparator. Defining it means someone has to state, in writing, which population the system is meant to serve. That statement has commercial and clinical consequences, so it tends to circulate without anyone signing it. Assign the decision to a named owner with a date, and treat a missing reference population as a blocking issue rather than an open item.

Conclusion

Article 10 is a data engineering requirement wearing the clothing of a legal obligation. Most of the effort it demands cannot be delegated to legal, cannot be resolved by policy, and cannot be produced in the final quarter before a deadline. The clause asks a data team to state precisely what a system is for, prove that the datasets behind it match that purpose, demonstrate that they represent the population the system will meet in the real world, and show that they were examined for bias against a limit set in advance. Then it asks for the documents.

The good news for pharma and biotech is that the foundation is already there. ALCOA+ and 21 CFR Part 11 have built genuine discipline around provenance, traceability, and record integrity, and Article 10(2)(a) through (e) sits comfortably on top of that. The honest news is that representativeness and bias examination are new. They ask a question data integrity has never asked, which is not whether the data is trustworthy but whether it resembles the world. That question needs a reference population, a subgroup taxonomy, and a preset limit, and none of those come out of a data warehouse. They come out of a decision somebody has to own. The deferral to December 2027 gives organizations time to make those decisions carefully, and to fix the pipeline problems the first honest assessment will expose. That time only helps the teams that start using it now.

Sakara Digital works with pharma and biotech organizations building the data foundations that AI governance requirements depend on, from scoping which systems are actually in scope through to the acceptance criteria and evidence artifacts that hold up under assessment. If you are working out where Article 10 lands in your estate and want an independent perspective on where to start, we are happy to have that conversation.

For Further Reading