EU GMP Annex 22: What the AI Annex Actually Says

On 7 July 2025 the European Medicines Agency and PIC/S published three documents for consultation: a revised Annex 11 on computerised systems, a revised Chapter 4 on documentation, and a wholly new Annex 22, "Artificial Intelligence". The consultation closed on 7 October 2025 and drew roughly 1,300 comments. As of 30 August 2026 the final text has not been adopted — EMA working-group planning points at Q4 2026 for delivery, with operative dates to be confirmed.

The draft is short and its central position is unambiguous. In critical GMP applications, Annex 22 accepts static, deterministic models only: locked after training, same input, same output. It states that dynamic or continuously-learning models, models with non-deterministic output, and generative AI including large language models should not be used in those applications.

That single sentence has done more to shape European pharma AI roadmaps than any other regulatory text of the last two years, and it is routinely misread in both directions — by vendors who ignore it and by quality units who read it as a blanket prohibition on AI in manufacturing. It is neither.

What Annex 22 actually covers

Scope is the first thing people get wrong, and it is the thing that decides whether the annex applies to you at all.

Annex 22 was drafted by the EMA GMDP Inspectors Working Group together with PIC/S. Its subject is AI and machine-learning models used in critical GMP applications — those where the model's output has a direct impact on patient safety, product quality or data integrity.

That is a functional test, not a technological one. It does not ask what architecture the model uses or how it was trained. It asks what the output does. The same model can be in scope in one deployment and out of scope in another:

The distinction is not a loophole. It is the whole design lever. If you want to use a generative model in a GMP environment in 2026, the question is not "how do I validate an LLM against Annex 22" — the draft's answer to that is that you should not. The question is how the workflow is arranged so the model's output is an input to a human decision rather than the decision itself, and whether that human step is real or ceremonial. An inspector will test the second part.

The human step has to be real

A review step that a human cannot practically perform is not a control. If a reviewer is presented with 400 model-generated severity assignments a shift and a single "approve all" button, the human oversight exists on the process map and nowhere else. The draft's human-oversight expectation, and the ordinary GMP expectation that a decision is attributable to a person who made it, both fail in that design.

What makes the step real is mundane: the reviewer sees the evidence the model used, has time proportionate to the decision, can disagree without friction, and their disagreements are recorded and trended. If a model is overridden 30% of the time and nobody knows, there is no oversight — there is a rubber stamp with an audit trail.

Why "static and deterministic"

The requirement reads like technophobia until you look at it from the inspector's side of the table.

GMP is built on a claim a manufacturer must be able to make about a process: it does what we said it does, repeatably, and we can show you the evidence. Validation is how that claim is evidenced. Every element of the classic lifecycle — a user requirement specification, a functional specification, a test with a pre-defined expected result, a change control that triggers revalidation — assumes the thing under test has a fixed behaviour between changes.

A continuously-learning model breaks that assumption by design. Its behaviour changes without a change control, which means the validated state is a moment in time that has already passed. A non-deterministic model breaks it differently: the same input does not reliably produce the same output, so a test with a pre-defined expected result does not have a stable meaning.

Freezing the model resolves both. A locked model has a version, and a version can be tested, released, changed under control and revalidated — the machinery GMP already has. Retraining becomes a change, not an event that happens on its own.

This is also why the exclusion is not a permanent judgement about capability. It is a statement that the current validation framework has no way to hold a moving target. Consultation feedback showed clear industry appetite for permitting generative models with guardrails, and EMA's Annex 22 group and its Quality Innovation Group have run a multi-stakeholder workshop specifically on control and mitigation measures. The direction of travel is towards a framework that can accommodate them. It has not arrived.

What the draft requires of a model that is in scope

Strip out the AI vocabulary and the requirements are the ones a good validation engineer would have arrived at anyway.

Intended use, written down and narrow. Not "assist with visual inspection" but which defect classes, on which product and container, at which line speed, with what happens to a borderline result. The intended-use statement is what the acceptance criteria are set against, and a vague one makes every downstream artefact vague.

Test data independent of training data, and adequate. Independence is the part that gets fudged. A test set carved randomly out of the same collection run as the training set is not independent in any way an inspector will accept — same equipment, same operators, same batch, same season. Adequacy means the test set contains the cases that matter, including the rare defect you are actually deploying the model to catch, at enough frequency to say something statistically.

Performance metrics and acceptance criteria, defined before the test. Which metric, at what threshold, and why that threshold is the right one for this intended use. For a model whose failure mode is a missed defect, overall accuracy is close to meaningless; sensitivity at a fixed specificity, with a confidence interval, is the number that means something. Setting criteria after seeing the results is the oldest failure in validation and it is instantly visible in the document dates.

Explainability, proportionate to risk. The draft asks for explainability considerations rather than a specific technique. What this means in practice is that you can say why the model produced an output in terms a subject-matter expert can evaluate, at a depth that matches the consequence of being wrong.

Human oversight, designed rather than asserted. Covered above.

Ongoing performance monitoring after deployment. The model's live performance is measured against the same metrics used at qualification, with pre-defined action thresholds. Drift is not a research topic here; it is a deviation trigger. The monitoring plan states what is measured, how often, who reviews it, and what happens when it moves — including what constitutes a trigger for revalidation.

What this looks like as a document set

For a system with an AI component, the ordinary validation package acquires a handful of additions:

• An intended-use and context-of-use statement for the model, separate from the system's user requirements
• A model card: data provenance, training and test split, preprocessing, metrics, known limitations
• A model risk assessment sized on influence and consequence — how much the model's output drives the decision, and how bad it is if the decision is wrong
• Performance qualification of the model against pre-defined acceptance criteria on the independent test set
• The human-oversight design, with the override path and how overrides are trended
• The production monitoring plan, with drift metrics, review cadence and revalidation triggers
• Version control over the model, its configuration and — for any generative component — its prompts, as controlled artefacts

None of this is exotic. It is the pattern that the GAMP guidance on AI, the FDA credibility-assessment framework and draft Annex 22 all converge on from different directions, and it is what "IQ, OQ and PQ for AI" resolves to in a client room.

Where Annex 22 sits in the wider stack

Annex 22 does not stand alone, and quoting it in isolation is how consultants get caught out.

The revision to Annex 11 matters at least as much as Annex 22 for anyone building an AI system, and it is the one people skip. Two of its changes hit AI architectures directly. Audit trails must capture creation events, not only changes and deletions — so a model that writes a value into a GMP record generates an audit-trail entry at the point of writing, attributable to an identified system account. And the alignment to ALCOA++ adds traceability, meaning end-to-end lineage through the data lifecycle. For a retrieval-based system, that is a real design requirement: which source documents produced this output, in which version, at what time.

The GxP flavour question is worth stating plainly, because it is the most common scoping error. An AI system inherits the GxP flavour of the process it touches, not the company that owns it. A deviation-triage model in manufacturing is GMP and Annex 22 is in play. A document-classification model filing into an eTMF at the same company is GCP, where the governing text is the EMA guideline on computerised systems and electronic data in clinical trials — and Annex 22 does not apply to it at all.

What to do before the final text lands

The draft is not binding. Designing as though it were is still the right call, for a reason that has nothing to do with compliance theatre: every architecture that satisfies Annex 22 is also the architecture that survives the model being wrong.

Classify every AI use as critical or not, and write down why. This is a half-day exercise that determines the entire validation posture, and it is the first question an inspector asks. Getting it wrong in the permissive direction is expensive; getting it wrong in the conservative direction is merely slow.

For anything critical, lock the model. Version it, test it, change-control it. If a vendor cannot tell you which model version is serving your requests today, you cannot make the claim GMP requires you to make.

For anything generative, engineer the human step. Design the workflow so the model's output is evidence for a human decision, make the decision attributable, and instrument the override rate from day one. The override rate is the single most useful number you will have when someone asks whether the oversight is real.

Build the monitoring before the go-live, not after. A monitoring plan written after deployment is a plan written by people who already know what the model does, which is precisely the bias it exists to catch.

Watch the finalisation, and watch what changed. The consultation produced roughly 1,300 comments and a documented appetite for permitting generative models under guardrails. If the final text relaxes the exclusion, it will relax it conditionally — and the conditions will be the controls above. Building them now is not wasted work under either outcome.

The honest summary

Annex 22 is a narrow, conservative, unfinished document that has been read far more widely than it has been read carefully. It does not prohibit AI in pharmaceutical manufacturing. It prohibits a specific and small category of deployment: a model that cannot be pinned down, making a decision that reaches the patient.

Almost everything a pharmaceutical manufacturer wants from AI today — triage, drafting, search, anomaly flagging, planning, investigation support — sits outside that category and can be designed to stay outside it. The organisations that will struggle are the ones that put a generative model in the release path because the demo was impressive, and the ones that built a human review step that nobody has time to perform.

Neither of those is a regulatory problem. They are design problems that a regulator will eventually find.