A Head of Quality at a UK site that makes medicines for European markets now has a validation question with no settled answer. The European Commission and PIC/S put a new GMP annex on artificial intelligence out for consultation on 7 July 2025, alongside a rewritten Annex 11 on computerised systems and a revised Chapter 4 on documentation. The consultation closed on 7 October 2025. A year on, none of the three is in force, and the line excluding generative AI from critical use is being reconsidered.
That uncertainty is not a reason to wait. Draft Annex 22 is six pages long, and most of those pages describe evidence a careful site would want anyway: who defined the intended use, how the test data was chosen, whether the people who trained the model ever saw it, and what happens when the process changes. A site that builds that file now, with or without DATS AI consulting, has the core of the evidence whichever way the final scope lands, and a base on which to add the control strategy a wider scope would require. This guide sets out what the draft asks for, what has changed since the consultation, how the annex reaches a UK manufacturer, and the validation file worth starting this quarter.
Scope matters, so here is the boundary. This post holds AI model validation under GMP. It cedes pharmacovigilance and GPvP inspection evidence to our GPvP inspection evidence pack, cedes standing quality evidence and plant-floor decision limits to continuous audit evidence for manufacturers, and cedes the wider map of where AI pays in the sector to AI for pharma in the UK.
This guide is shipped by the team behind DATS, the five-stage AI consulting system from DILR.AI, delivered by senior practitioners who ship code, not decks. Or see the AI operating model engagement, which covers governance, RACI and lifecycle, audit-ready by design.
What is EU GMP Annex 22, and is it in force?
EU GMP Annex 22 is a draft annex to the EU and PIC/S Good Manufacturing Practice guides that sets requirements for selecting, training and validating AI models used in the manufacture of medicines and active substances. It is not in force. The joint consultation ran from 7 July to 7 October 2025, and in November 2026 the published GMP guide still lists no Annex 22 and the 2011 Annex 11.
The European Commission consultation page says the three documents were drafted by the EMA GMDP Inspectors Working Group in cooperation with PIC/S, and that the response period has ended. The EudraLex Volume 4 page, checked on 11 November 2026, still lists Annex 11 Computerised Systems as the January 2011 revision and Chapter 4 Documentation as January 2011. No final adoption date has been published, so any timeline you read for the final text is a forecast, not a fact.
The draft annex is short and structured. It has ten numbered sections: Scope, Principles, Intended Use, Acceptance Criteria, Test Data, Test Data Independency, Test Execution, Explainability, Confidence and Operation, followed by a glossary. It presents itself as additional guidance to Annex 11 for computerised systems in which AI models are embedded, which means the two documents have to be read together. The Annex 11 rewrite is the bigger change in volume: the current 2011 annex runs to five pages, and the consultation draft of Annex 11 runs to nineteen, across seventeen sections that include alarms, identity and access management, audit trails and periodic review.
For a quality team the practical reading is simple. Nothing in Annex 22 binds you today, but the expectations in it are written by the inspectors who will one day inspect against it, and most of them restate validation discipline that a careful site already applies to any computerised system. Our enterprise AI consulting guide sets out how the DATS five-stage system moves a pilot into production.
Which AI models does draft Annex 22 cover?
Draft Annex 22 covers machine learning models embedded in computerised systems used in medicines manufacturing where the application is critical, meaning it has direct impact on patient safety, product quality or data integrity. The consultation draft limits that coverage to static models, which do not keep learning in use, and to deterministic models, which give identical outputs for identical inputs. Everything else is placed outside it.
The draft Annex 22 text gives prediction and classification as its examples of critical use, and it applies to models that obtained their function through training on data rather than explicit programming. A model may consist of several individual models, each automating a specific GMP process step. Dynamic models that continuously adapt during use are not covered and, in the draft's words, should not be used in critical GMP applications. The same applies to models with a probabilistic output.
The sentence the EMA has since revisited is the one on generative AI. The draft states: "Following the above, the document does not apply to Generative AI and Large Language Models (LLM), and such models should not be used in critical GMP applications." The draft then allows those models in non-critical applications, with one condition: personnel with adequate qualification and training should always be responsible for ensuring the outputs are suitable for the intended use, which the draft calls human-in-the-loop.
For the most common cases, that gives three categories to sort use cases into before anything else happens. The draft is silent on other combinations, such as a non-critical adaptive model that is not generative AI.
| Category under the consultation draft | Example of the kind of use | What the draft says |
|---|---|---|
| Critical, static, deterministic model | A trained classifier that accepts or rejects units on visual inspection | In scope: the full annex applies |
| Critical, dynamic or probabilistic model, or generative AI | A language model drafting a batch disposition decision | Not covered, and should not be used in critical GMP applications |
| Non-critical generative AI or LLM | A language model summarising SOP changes for a training note | Allowed with a qualified human responsible for every output |
The examples in the middle column are ours, not the draft's. Placing a real use case into one of those rows is a judgement about criticality, and section 2.3 asks for the annex's activities to be based on the risk to patient safety, product quality and data integrity, so the same risk logic should drive the classification. Write the rationale down, and give the call a named owner inside your AI operating model, because it is the first thing anyone reviewing the file will ask to see.
Why does the generative AI exclusion matter, and could it change?
The generative AI exclusion matters because it decides whether a whole class of tools can go near a critical GMP decision at all. It could change. An EMA report on a workshop held on 30 June and 1 July 2026 records that consultation comments supported allowing language models and generative AI in GMP applications, and that the Annex 22 drafting group has discussed widening the scope, subject to a documented risk-based control strategy.
The EMA workshop report (EMA/156789/2026) is careful about what it does and does not say. The drafting group asked for the workshop because concerns remained about what such a control strategy would need. Industry associations presented a consolidated position across six topics: regulatory pathways for adaptive and probabilistic models, technical reliability and incident response, human oversight and accountability, validation and lifecycle management, strategic risk and compliance limits, and cybersecurity and outsourced activities. The EMA event page describes the aim as shaping a risk-based approach to generative AI in medicines manufacturing.
The report's conclusion is hedged. It says the discussions suggest "there may be viable pathways for the use of adaptive, probabilistic and generative AI technologies in GMP-regulated applications" subject to appropriate controls and a robust risk-based framework. Its next steps commit only to reviewing the input and using it to inform the ongoing revision. So the honest position in November 2026 is that the exclusion is under review, not that it has been removed.
The report also records key messages from the industry-led discussion. They are industry positions, not regulator text, but four of them show what the drafting group heard:
- A valid quality risk management outcome can still be "do not use" where uncertainty cannot be controlled, and that conclusion should be documented.
- Accountability stays with qualified or responsible persons and cannot be delegated to an AI system.
- Human-in-the-loop is one possible control, not a default requirement, and oversight cannot make up for inadequate validation.
- Detectability matters for AI risk, especially where a model's errors are hard to observe.
The last point is the one most likely to catch a site out. A language model that produces fluent, plausible text fails in ways a reviewer does not notice, which is the kind of detectability risk the workshop discussed. Whatever the final scope, it would be prudent to plan for more evidence where errors are harder to see. If your organisation is weighing a self-hosted model for regulated documents, our guide to private LLMs for regulated institutions covers the hosting side; the GMP validation question sits on top of it.
Does Annex 22 apply to a UK manufacturer?
Annex 22 does not yet apply to anyone, but it is a joint EU and PIC/S draft, and the MHRA is a PIC/S participating authority. A UK manufacturer should therefore treat it as the most likely shape of future inspector expectations on AI in manufacturing, while noting that we found no MHRA statement on the annex and no UK date for it.
The PIC/S list of participating authorities records the MHRA as having joined the PIC Scheme in June 1999. The consultation itself was run jointly by the European Commission and PIC/S, and the PIC/S announcement describes the drafts as changes to both the PIC/S and EU GMP guides, prepared to maintain global alignment of standards. The MHRA's own GMP and GDP guidance page points manufacturers to Volume 4 of the rules governing medicinal products in the EU among the GMP guidance it lists.
We found no MHRA statement on Annex 22 in preparing this guide, and we are not going to guess one. What a UK site can do is build the evidence that the draft and existing validation practice already point towards: a documented intended use, independent test data, approved acceptance criteria and controlled change. If you want a second view on where your site stands, book a scoping call. A site that supplies EU markets has a further reason to follow the EU text closely once it is final.
There is also a governance overlap worth naming. Other AI rules, such as the EU AI Act, run on their own terms and timetables, so do not assume a GMP validation file also answers them. Our post on AI risk frameworks across UK sector regulators looks at the UK regulator side, and our note on the EU AI Act omnibus delay covers the shifting EU timetable.
What goes into an Annex 22 validation file?
An Annex 22 validation file is the set of approved documents that shows an AI model is fit for its intended use before it touches a critical GMP process. Under the consultation draft it starts with an intended use description and acceptance criteria approved by a process subject matter expert, then adds a test plan, independent test data, test results with explainability and confidence records, and change control.
Read in order, the draft describes a sequence rather than a checklist. The diagram below condenses it into six stages; the stage names are ours, and the section numbers in each subtitle point back to the draft.
Intended use. Section 3.1 asks for a detailed description of what the model is for, based on in-depth knowledge of the process, including a characterisation of the input data with all common and rare variations, which the draft calls the input sample space. Known limitations and possible erroneous or biased inputs should be identified. A process subject matter expert is responsible for the description, and it should be documented and approved before acceptance testing starts. Section 3.2 adds subgroups: accept or reject outcomes, site or equipment, material characteristics, and defect type and severity are the draft's own examples.
Acceptance criteria. Section 4.1 asks for case-dependent test metrics. For a classifier the draft lists a confusion matrix, sensitivity, specificity, accuracy, precision and F1 score as examples. Section 4.2 makes the process SME responsible for the acceptance criteria, again approved before testing, and allows different criteria for different subgroups. Section 4.3 is the clause that changes project plans: "The acceptance criteria of a model, should be at least as high as the performance of the process it replaces." That only works if you know how well the current process performs, and a site may never have measured that for a manual visual inspection. Our enterprise AI solutions page lists evaluation and observability for production agents as one of six named solutions.
One drafting detail is worth flagging to your validation lead. Section 4.3 cross-refers to "Annex 11 2.7", but in the consultation draft of Annex 11, clause 2.7 is Security and the no-risk-increase principle sits at clause 2.8. Cite the principle by name in your own documents until the final numbering is settled.
Personnel and supplier documentation. Section 2.1 expects close cooperation between process SMEs, QA, data scientists, IT and consultants, each with defined responsibilities. Section 2.2 is the clause easiest to miss in procurement: documentation should be available and reviewed by the regulated user irrespective of whether the model was trained and tested in-house or provided by a supplier. Buying a model does not buy you out of the file.
When a validated model moves into production, our AI execution office provides embedded delivery, with production placements the client owns.
How should test data be kept independent?
Test data independence under draft Annex 22 means the data used to test a model has never been used to develop, train or validate it, and that people involved in training are kept away from it, or paired with a colleague who is not. The draft treats this as a control to be proven, with access restrictions, audit trails and records of which data was used, when and how many times.
Section 6 is the most operational part of the draft, and it asks a data science team to prove separations it may until now have kept informally. Independence can be achieved by capturing test data only after training and validation are complete, or by splitting it from the full pool before training starts. If you split, the draft expects that staff involved in development never had access to the test set, that the test data is protected by access control and an audit trail logging access and changes, and that no copies exist outside that repository. It is the same evidence-by-default thinking behind continuous audit evidence for manufacturers, applied here to a dataset. Where test data comes from physical objects, such as sample units, the objects used for the final test should not have been used in training or validation, unless features are independent.
Staff independence gets its own clause. Where it is impossible to keep the people who saw test data away from training, the draft allows a four-eyes arrangement: someone who may have seen the test data works on training only alongside a colleague who has not. For a small site with one data scientist, that is a resourcing question to raise now rather than during an inspection.
Section 5 sets the quality bar for the test set itself. It should be representative of the full intended use, stratified across every subgroup, and large enough to calculate the test metrics with adequate statistical confidence. Labels should be verified through a process that ensures a very high degree of correctness, which may mean independent verification by several experts or by validated equipment or laboratory tests. Pre-processing should be pre-specified and justified, and any exclusion of test data documented. Section 5.6 is blunt about synthetic data: generating test data or labels, including with generative AI, is not recommended, and any use should be fully justified.
In practice this looks a lot like the golden-set discipline that mature AI teams already run for regression testing; our note on golden-set regression testing describes the mechanics in a different domain. The GMP difference is that the separation has to be evidenced to an inspector, not just believed by the team.
Explainability and confidence under the draft
Explainability in draft Annex 22 means recording which features in the test data drove a model's classification or decision, and having a person review those features before the test results are approved. Confidence means logging the model's confidence score for each prediction where applicable, setting a threshold, and considering an "undecided" outcome when confidence is very low rather than forcing an answer.
Section 8.1 asks that, during testing of models used in critical applications, systems capture and record the features that contributed to a particular outcome, such as a rejection. It names feature attribution techniques like SHAP values or LIME, and visual tools like heat maps, as examples. Section 8.2 makes the review of those features part of approving the test results, so that a model which reaches the right answer for the wrong reason is caught before release. A vision model that rejects tablets because of the background lighting rather than the defect is the kind of failure this review is there to catch.
Section 9 is short but has design consequences. A model that predicts or classifies should have a threshold so that it makes a call only when suitable, and the draft suggests flagging very low-confidence outcomes as undecided. If a site adopts that option, the hard cases need somewhere to go, which means the process around the model needs a queue, an owner and a record for those undecided items. Our guide to AI observability and tracing covers the tracing side of keeping per-decision records in a production system.
What does Annex 22 expect once a model is in operation?
Once a model is in operation, draft Annex 22 expects it to stay under change control and configuration control, with its performance and its input data monitored for drift. Any change to the model, the system or the process it serves should be evaluated for retesting, and where a human decides on the model's output and testing was reduced on that basis, records of that review should be kept.
Section 10.1 is broader than many teams expect. Change control covers the model, the system it runs in and the whole process it automates or assists, including changes to the physical objects the model uses as input. In our reading, a new camera or a new packaging format could each count as such a change and call for a retest evaluation, and a decision not to retest should be fully justified. Section 10.2 adds configuration control with effective measures to detect unauthorised change.
Sections 10.3 and 10.4 deal with drift. The model's performance against its defined metrics should be monitored regularly, and the draft's own example of what can shift is a change in lighting conditions. Separately, the input data should be monitored to check it still falls within the model's sample space and intended use, with metrics defined for detecting drift. Our UK manufacturing guide asks the separate question of whether AI should make a quality or safety decision on a plant floor at all. Section 10.5 covers human-in-the-loop operation: where a person makes the decision on the model's input and testing effort was reduced on that basis, records of the review should be kept, and depending on criticality that may mean reviewing every output.
The draft Annex 11 reinforces this with periodic review. Its clause 14.1 says that after initial validation, periodic reviews should verify whether the system remains fit for intended use and in a validated state. For an AI model, that review is where drift monitoring results, undecided-outcome volumes and change records come together. The release discipline is the same one we describe in change control for production AI, applied under a quality system rather than a product team.
What is the best way to prepare for Annex 22 in 2026?
The best way to prepare for Annex 22 in 2026 is to build the validation file for one live or planned model now, using the consultation draft as the template, and to keep generative AI out of critical decisions until the final scope is published. Specialist validation consultancies or a vendor's own validation pack can both win when the model is a single bought-in vision system.
That concession matters. If your only AI use is a supplier's inspection system with an established validation package, a GxP validation specialist or the supplier itself may be the faster route, provided you still review the documentation as section 2.2 requires. For a large multi-site programme, a big advisory firm such as Deloitte, PwC or Accenture may suit the scale better. An outside team can help most with the placement question: deciding which use cases belong in which category, and where AI does not belong at all.
A sensible ninety-day plan for a single site looks like this:
- Inventory and classify. List every AI use touching GMP, including tools in validation, quality and laboratory systems. Place each in one of the three categories above and record the criticality rationale.
- Measure the baseline. For each critical use, establish the performance of the process the model would replace, because acceptance criteria cannot be set without it.
- Lock the test data. Create a controlled repository with access control and an audit trail before any further training happens, and name who is barred from it.
- Draft one complete file. Take one model through intended use, acceptance criteria, test plan, execution, explainability and confidence records, then put it under change control.
- Write the generative AI rule. Until the scope is settled, state in a procedure where language models may be used, who reviews their outputs, and that they do not make critical decisions.
The first two steps decide whether AI belongs in the process at all, which is why they come before any model work. For the wider sector picture, our map of where AI pays in pharma sets out where DATS fits against submission dossiers and pharmacovigilance work.
Frequently asked questions
Does Annex 22 replace Annex 11?
Annex 22 does not replace Annex 11. The consultation draft describes Annex 22 as additional guidance to Annex 11 for computerised systems in which AI models are embedded, so a model inside a GMP system would be validated under both. Annex 11 itself is being rewritten in parallel, growing from five pages in the 2011 version to nineteen in the consultation draft.
In practice that means your computerised system validation, data integrity and audit trail controls stay the foundation, and the AI-specific evidence in Annex 22 sits on top. The revised Chapter 4 on documentation was consulted on at the same time and covers how those records are kept across paper, electronic and hybrid formats.
Can a large language model be used anywhere in GMP under the draft?
A large language model can be used in non-critical GMP applications under the consultation draft of Annex 22, provided qualified and trained personnel are always responsible for checking that each output is suitable for its intended use. The draft says such models should not be used in critical applications, although EMA's 2026 workshop report shows that position is being reconsidered.
Typical non-critical uses are drafting training material, summarising procedure changes or searching controlled documents, with a named reviewer. Record which uses you treat as non-critical and why, because that classification is what an inspector will test first.
Want to see this in production? Start with DATS AI consulting, explore enterprise AI solutions, browse our compliance guides, or read about our approach to placing AI inside regulated systems.
Build the validation file before the annex lands.
30-min scoping call · No deck · Confidential. We will tell you where AI belongs in your operation, and where it does not.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.