Annex 22 and AI Validation: What the Draft GMP Annex Means for Your Systems
What the draft Annex 22 means for AI validation: scope, test data, acceptance criteria, explainability and monitoring for GxP systems.
The draft EU GMP Annex 22 describes additional expectations for static, deterministic AI/ML models used in critical GMP applications. It focuses on precise intended use, representative and independent test data, predefined performance metrics, explainability, change control and ongoing monitoring. Annex 22 is currently a consultation draft, not a final GMP annex in force.
Start with the correct regulatory status
The European Commission opened a joint consultation on revised EU GMP Chapter 4 and Annex 11 and a new Annex 22, “Artificial Intelligence,” on 7 July 2025. The consultation closed on 7 October 2025. The official EudraLex page continues to list Annex 11 in its January 2011 revision; as of 12 July 2026, no final Annex 22 is published there.
Two rules follow. First, the draft must not be represented as current law. Second, it would be commercially unwise to build a critical AI system whose data, testing and operating model ignores the direction made explicit in the draft.
The draft is therefore an input to planning and gap assessment. The binding basis remains the applicable regulatory framework, including existing GMP requirements, Annex 11 and the pharmaceutical quality system.
In implementation, DHC connects CSV consulting with GxP system validation so that AI-specific model and data evidence sits inside a controlled system lifecycle.
Which AI systems the draft covers
Annex 22 applies several filters at once. The draft addresses computerised systems used in the manufacture of medicinal products and active substances where an AI model is used in a critical application with direct impact on patient safety, product quality or data integrity, for example to predict or classify data.
The draft covers models that obtain their functionality through training with data and are:
- static, meaning they do not continuously adapt during use;
- deterministic, providing identical outputs for identical inputs;
- embedded in a GMP-relevant computerised system;
- governed by a clearly described intended use.
The draft does not cover dynamically learning or probabilistic models and states that they should not be used in critical GMP applications. The same logic excludes generative AI and large language models from scope, and the draft says they should not be used in critical GMP applications.
For non-critical GMP applications, the text points to a different control model: qualified personnel should ensure outputs are suitable for intended use. This human-in-the-loop approach does not turn an uncontrolled LLM into a validated critical system.
The scope check before validation starts
Before writing test cases, answer six questions:
1. Does the system support manufacture of medicinal products or active substances?
2. Is the AI function critical to patient safety, product quality or data integrity?
3. Is the function delivered by a trained model or by explicitly programmed logic?
4. Will the released model remain static in operation?
5. Is the output reproducible for an identical input?
6. Does the AI support a human decision or automate it?
The answers separate three workstreams: a critical AI/ML system aligned with the Annex 22 draft, a non-critical application with human review, or a system outside the described Annex 22 scope. All may require controls, but not the same rationale.
Work package 1: Intended use and input sample space
The draft expects a detailed description of the task and the process into which the model is integrated. This includes comprehensive characterisation of input data, common and rare variations, limitations and potentially erroneous or biased inputs.
“The model detects defects” is not precise enough. A defensible intended use describes, for example:
- product, material, line, camera or sensor configuration;
- relevant defect classes and decision outputs;
- permitted operating and environmental conditions;
- known exclusions and escalation cases;
- responsibility of the human operator;
- downstream decision and potential effect of failure.
Under the draft, a process SME is responsible for the adequacy of this description, which should be documented and approved before acceptance testing starts.
Work package 2: Metrics and acceptance criteria
The performance of an AI model cannot be evaluated through a generic “test passed.” Annex 22 lists potential metrics for classification models such as a confusion matrix, sensitivity, specificity, accuracy, precision and F1 score.
Selection depends on intended use. In defect detection, a false acceptance can have a different consequence from an unnecessary rejection. Criteria may therefore need to be assessed separately for relevant subgroups.
Sequence matters: metrics and acceptance criteria are established before test execution. The draft also says acceptance criteria should be at least as high as the performance of the process being replaced. If the baseline of the manual or existing technical process is unknown, that expectation cannot be evaluated transparently.
Work package 3: Representative test data
Under the draft, test data should cover the full intended input sample space, including subgroups, limitations, complexity and both common and rare variations. Selection and rationale are documented. The draft says the data set and subgroups should be large enough to calculate the chosen metrics with adequate statistical confidence.
Labels are part of the evidence. The draft expects a process that achieves a very high degree of correctness, potentially through independent experts, validated equipment or laboratory tests. Pre-processing is prespecified; cleaning and exclusions are documented and justified.
For AI system validation in GxP, data quality is therefore not an upstream data-science concern. It is part of the validation object.
Work package 4: Independence of test data
A model should not be tested using data that already influenced its development. The draft describes technical and procedural controls that separate test data from development, training and validation.
If a test set is split from a common pool before training, developers should not have access to it. Access control and audit trail functionality protect the repository, and copies outside it should be prevented. The organisation records which data were used for testing, when and how many times.
This control does more than prevent accidental data leakage. It makes the model’s ability to generalise testable.
Work package 5: Test plan, execution and deviations
Under the draft, an approved plan is prepared before testing. It connects intended use, metrics, acceptance criteria, the test data reference, test steps and calculation methods. A process SME contributes to the plan.
Deviations from the plan, failed criteria or omitted test data are documented, investigated and justified. Under the draft, retained test documentation also includes intended use, data characterisation, actual test data and evidence for access control and audit trail protection.
This is established validation discipline expanded with model- and data-specific evidence. A data-science notebook on its own will not normally capture the complete controlled decision path.
Work package 6: Explainability and confidence
During testing of critical models, the system should capture features that contributed to a classification or decision. The draft refers to feature-attribution techniques such as SHAP or LIME and visual tools such as heat maps. Review of test results should assess whether the model is deciding on relevant and appropriate features.
Where applicable, the confidence score should be logged for each prediction or classification. A suitable threshold can produce an “undecided” result rather than force a potentially unreliable decision.
Explainability here is not a promise that every aspect of a model can be understood. It is specific evidence concerning the factors that influence outputs in the intended process.
Work package 7: Change control, configuration and monitoring
Under the draft, the tested model, the computerised system and the supported process are placed under change control before deployment. Changes to the model, system, process or physical input are assessed to determine whether retesting is required. A decision not to retest is justified.
The draft also expects configuration control and measures that detect unauthorised change. During operation, the organisation monitors model performance and the input sample space to detect deterioration or drift.
The operating model therefore needs defined triggers, such as:
- performance drops below a warning or acceptance threshold;
- inputs move outside the approved sample space;
- camera, sensor, line, product or pre-processing changes;
- model or software version changes;
- frequency of human overrides or “undecided” outputs increases.
Without these triggers, validation remains a point-in-time exercise.
What organisations can prepare now
Even before publication of a final Annex 22, organisations can take reversible, framework-neutral steps:
1. Inventory AI applications, including embedded supplier functionality.
2. Classify intended use, GMP relevance, criticality and model type.
3. For critical candidates, document data provenance, sample space and process baseline.
4. Clarify accountability across process SME, QA, IT, data science and the supplier.
5. Pilot independent test data, metrics, acceptance criteria and monitoring evidence.
6. Document the delta between current GAMP 5 compliance and the model-specific expectations in the draft.
The result is not a generic “Annex 22 certificate.” It is an evidence-based readiness position that can be adjusted when a final text is issued.
AI applications outside the draft Annex 22 scope still need to be assessed against the applicable GxP framework. The DHC assessment therefore also establishes the appropriate system boundary, human control, data and interface evidence, testing and monitoring for non-critical generative uses and for GCP, GLP or GDP contexts.
Frequently asked questions
Is Annex 22 already binding?
No. As of 12 July 2026, Annex 22 is a consultation draft. The consultation is closed, but EudraLex Volume 4 does not yet list a final Annex 22.
Does the draft allow LLMs in GMP processes?
The draft says that generative AI and LLMs should not be used in critical GMP applications. For non-critical applications, it points to qualified personnel ensuring output suitability for intended use. The specific use case still requires its own GxP and risk assessment.
Does Annex 22 replace CSV under Annex 11 or GAMP 5?
No. The draft provides additional guidance to Annex 11 for computerised systems with embedded AI models. Existing lifecycle, quality-risk, data-integrity and system controls remain relevant and are supplemented by model-specific evidence.
Primary sources
- European Commission: Annex 22 — Artificial Intelligence, consultation draft
- European Commission: Consultation on Chapter 4, Annex 11 and Annex 22
- EudraLex Volume 4 — current publication status
- EU GMP Annex 11 — Computerised Systems
Author
Daniel Herrmann Consulting supports Pharma and MedTech organisations in assessing, implementing and validating AI systems in GxP, with a clear distinction between binding requirements and regulatory drafts.
Are you planning an AI use case that can affect product quality, data integrity or patient safety?
The AI validation assessment establishes scope, evidence gaps and a controlled pilot path.