AI Adoption · Pharma & life sciences · Written and maintained by Haink’s AI adoption team · Updated August 2026 · 11 min read

EU GMP Annex 22: what the draft requires of AI in manufacturing

Until recently, an AI model on a GMP site was governed by inference. Annex 11 on computerised systems — last substantively revised in 2011, years before machine learning reached the shop floor — was stretched to cover it. Quality teams were asked to approve deployments against a rulebook that never mentioned training data, test-set independence, explainability or drift. Some approved anyway. Many did not, and the model stayed in the pilot.

EudraLex Volume 4, Annex 22 closes that gap — and it closes it more narrowly than most teams expect. The draft does not ask whether AI is permitted in GMP. It states which kinds of models are permitted where, and generative models are not on the list for critical applications.

The line the draft draws: static and deterministic, or nothing critical

The whole annex turns on one distinction. For GMP-critical applications — anything with direct impact on product quality, patient safety or data integrity — the draft admits only static, deterministic models: parameters frozen after training, same input producing the same output, no autonomous adaptation in use. Models that continue to learn in production are excluded. So are models with probabilistic output. So, explicitly, are generative AI and large language models.

That is the sentence that reframes most 2026 roadmaps. It is not, however, a site-wide ban. The draft leaves the door open for LLMs in non-critical contexts — summarising deviation reports, searching SOPs, drafting maintenance notes — on the condition that a qualified person remains in the loop, reviews the output, and retains documented responsibility for whatever action follows.

Which puts a practical question in front of every AI initiative on a GMP site: is this use case critical, and if it is, is the model type still legal?

Read the table as a design constraint rather than a restriction. Every LLM-based system that survives contact with a GMP quality unit will be one that produces drafts and findings for a named human, never actions. Build it that way from the first sprint and the compliance conversation is short. Build a system that decides, and no amount of retrofitted documentation will rescue it.

Five obligations that change how the system is engineered

The draft's requirements span the model lifecycle and sit on top of Annex 11, not instead of it. If you already run an AI governance framework, these extend it rather than replace it — see AI governance for adoption for how the pieces fit. Five obligations have direct engineering consequences.

1. Intended use is documented before testing begins

Not a one-line purpose statement — the full input sample space: common cases, edge cases, rare variations, plausible errors, sources of bias. A process subject matter expert approves it. If the team cannot articulate what the model is for and how it fails, acceptance testing cannot start. In practice this is the requirement that stalls existing deployments, because the document was never written and the people who trained the model have moved on.

2. Metrics are fixed in advance — and the model must beat the process it replaces

Acceptance metrics are defined and approved before testing, not selected after the results are in. And the bar is comparative: the model must perform at least as well as the process it is replacing. For sites where the manual process was never formally benchmarked, that benchmark now has to be produced first. Budget for it — it is often the longest lead item in the whole project.

3. Test data is separated from training data, enforced by people as well as systems

Strict separation, with both technical and procedural controls. Staff who had access to test data cannot be involved in training the same model unless paired with a colleague who did not — a four-eyes principle borrowed from financial controls. This has an architectural consequence most teams miss: your test set needs its own storage with its own access control and its own audit trail, not a folder on the same share. Sites that have never inventoried where their process data lives will hit this first; data readiness is the prerequisite, not a parallel workstream.

4. The model shows its working

The system records which features drove each classification, using SHAP values, LIME, heat maps or equivalent, and a review of those features forms part of the approval. The standard is not "the model was right" but "the model was right for the right reasons". Explainability artefacts therefore have to be produced per inference and stored, not generated on request months later when an inspector asks.

5. Change control extends to the physical world

Once deployed, any change to the model, to the system it runs on, or to the physical objects it takes as input must be assessed for revalidation. Retraining counts as a significant change. Confidence scores are logged per prediction where applicable, and where confidence is very low the system should be able to return undecided rather than force a classification.

That last point is the one with the longest tail. If a vibration model is fed by a sensor, then replacing the sensor, recalibrating it, or swapping the bearing it monitors becomes part of the AI compliance record. Asset history and model governance stop being separate disciplines.

Where Annex 22 sits

Three instruments overlap, and confusing them wastes months.

One provision deserves separate emphasis: responsibility for validation evidence rests with the regulated company, whether the model was built in-house or came embedded in a vendor system. There is no vendor black box. If a supplier cannot tell you how a model was trained, on what data, and how it is monitored, that is your gap to close, not theirs — a point worth raising during procurement rather than during an inspection.

What this means for system architecture

Most commentary on Annex 22 stops at governance. The more useful question for anyone about to build is what the draft changes in the design itself. Six things, concretely.

Two of those — version pinning and model provenance — point in the same direction as the data-confidentiality argument that already drives most pharma AI deployments on-premises. If proprietary process data cannot leave the perimeter and the model version has to stay frozen under change control, a self-hosted deployment stops being a preference and becomes the shape the requirements dictate. We built exactly that for a computational chemistry team in air-gapped AI for pharmaceutical R&D, where IP counsel ruled out any cloud path at all. We cover the deployment decision in private LLM for pharma, the general trade-off in cloud versus private AI, and the hardware side in private AI infrastructure. What these requirements do to a document extraction system specifically — and why a hosted model usually fails on change control rather than on confidentiality — is worked through in document extraction when the system itself has to be validated.

Keeping an LLM project in the permitted lane

If the use case is non-critical and an LLM is allowed, four design rules keep it that way — and they apply to any LLM application or RAG pipeline that has to survive a quality review. They are worth writing into the functional design rather than discovering during qualification.

• The system proposes; a named person disposes. No output takes effect without human review, and the reviewer's identity is recorded with the approval. This is what the draft means by documented responsibility.
• Every answer carries its source. A citation to the specific document and version it came from. An answer grounded in a superseded SOP is worse than no answer, and version-aware retrieval is the only defence.
• Everything is logged. Prompt, output, retrieved sources, model version, user, timestamp. Under Annex 11 principles this log is a GMP record, which also means it has to be retained and protected like one.
• The boundary is explicit. The intended-use document states what the system must not be used for. Systems without stated limits acquire critical uses by accident, one helpful shortcut at a time.

These are the same constraints that make an document intelligence system auditable in any regulated setting — we applied a comparable pattern to maintenance packages in civil-aviation MRO, where a wrong classification also has to be caught by a human before it reaches a record.

A first-pass readiness check

Not a substitute for a formal gap assessment, but it surfaces the pressure points in an afternoon.

• Do you have a complete register of AI and ML in use — including models embedded in vendor equipment and process control systems? If not, the portfolio review comes before anything else.
• For each in-scope model, can you name every asset, sensor and data source feeding it? Changes to any of them will require formal evaluation.
• Is intended use documented, with input sample space, edge cases and failure modes, and approved by a process expert?
• Is test data demonstrably separate from training and validation data — with procedural evidence, not just good intentions?
• Are confidence scores logged, and do low-confidence outputs get flagged rather than forced?
• Can you detect input drift and trigger revalidation when it happens?
• For every vendor system with embedded AI, do you have enough information about training, validation and monitoring to meet an obligation that is yours, not the vendor's?

Existing deployments are unlikely to be grandfathered: introducing Annex 22 would itself constitute the kind of significant change that, under Annex 11, triggers reassessment — though the final text may carry its own transition provisions. Sites with several vendor systems containing embedded ML should assume a substantial remediation exercise rather than a paperwork one. The pattern is familiar from why AI pilots fail: what stalls a system is rarely the model.

What is still uncertain

Three things worth stating plainly, because confident writing about a draft is how bad decisions get made.

The final text may differ from the consultation draft, including on the exclusions that matter most. Timing and phasing are not fixed — publication has already moved once. And transition provisions for existing deployments are unknown; planning for no grandfathering is the conservative assumption, not a confirmed requirement.

What is safe to act on now is the direction, and the direction has been consistent across the AI Act, the Annex 11 revision and this draft: documented intended use, evidence-based validation, explainability, human accountability at decision points, and monitoring that continues after go-live. A system designed to those principles will not need rebuilding when the final text lands. A system that decides autonomously will — and it will need rebuilding regardless, because it was never going to pass a quality review.

Frequently asked questions

Is Annex 22 in force?

No. As of August 2026 it remains a draft. The public consultation closed in October 2025 and finalisation was anticipated around mid-2026, but no final text has been published in EudraLex Volume 4. Plan against it; do not cite it as a binding requirement yet.

Does Annex 22 ban LLMs in pharma manufacturing?

No — it excludes them from GMP-critical applications. The draft explicitly permits LLM use in non-critical contexts such as summarising deviation reports, searching SOPs or drafting maintenance notes, provided a qualified person reviews the output and retains documented responsibility for any action taken.

How does Annex 22 relate to Annex 11?

It sits on top of it. Annex 11 remains the foundation for all GxP computerised systems; Annex 22 adds AI-specific expectations — training and test data, explainability, confidence scoring, drift monitoring — that Annex 11 never addressed. Annex 11 is itself under revision on a parallel track.

Who is responsible if the AI came from a vendor?

The regulated company. The draft places responsibility for validation evidence on the company deploying the model, regardless of who built it. A supplier who cannot describe how a model was trained, validated and monitored leaves you with a gap you have to close yourself — which is a procurement question, not a compliance one.

Do we have to revalidate when we retrain a model?

Retraining is treated as a significant change and has to be assessed for revalidation. So does a change to the system the model runs on, or to the physical objects it takes as input — replacing a sensor or the equipment it monitors can alter the input sample space and requires formal evaluation.

What does Annex 22 mean for where the model runs?

It does not mandate on-premises deployment. But two requirements push that way: models must be static and version-controlled, which is difficult with a managed endpoint whose version can change without your involvement, and model provenance must be documentable, which rules out a black box. Combined with the confidentiality constraints most pharma data carries, self-hosted open-weight models are usually the simpler path to evidence.