Annex 22 and Your Existing CSV Deliverables: A Mapping Exercise

Where Annex 22 Stands in September 2026

Before mapping anything, it is worth being precise about status, because a lot of secondary commentary is not. The European Commission’s consultation page for the package covering Chapter 4, Annex 11, and the new Annex 22 records an opening date of July 7, 2025 and a closing date of October 7, 2025. It states that the response period has ended, and it gives no outcome, no revised text, and no next-step timeline². The EudraLex Volume 4 page, which lists every chapter and annex of the EU GMP guide with its in-force date, does not list Annex 22 at all as of this writing. Annex 11 is still shown at its January 2011 revision.

The one primary source that gives a date is EMA’s three-year work plan for the GMDP Inspectors Working Group covering January 2026 through December 2028. It lists Annex 22 with a target date of Q4 2026 and describes the deliverable as providing the European Commission with a final text, in parallel with the update of Annex 11 and Chapter 4. The same plan commits to developing inspector training on the revised Chapter 4, Annex 11, and Annex 22 during 2026 to 2028³. Read that carefully. A target for handing text to the Commission is an internal milestone for a working group. It is not a publication date, it is not an entry-into-force date, and it does not describe any transition period. Those steps belong to the Commission, and the Commission has said nothing about them.

Between those two dates, EMA did something unusual. On June 30 and July 1, 2026 it held a multistakeholder workshop under the GMDP Inspectors Working Group, in collaboration with its Quality Innovation Group, specifically to gather expert opinion on a risk-based approach to generative AI in manufacturing. The published draft agenda for the open first day lists sessions on regulatory pathways for adaptive and probabilistic models, strategic risk and compliance limits, human oversight and accountability, technical reliability and incident response, validation and lifecycle management, and cybersecurity and outsourced activities, presented by experts nominated by EFPIA, PDA, and ISPE. The second day was a closed session for the Annex 22 drafting group⁴. EMA said it expected the workshop to produce a report with expert input. As of this writing, the event page links only the draft agenda. No report, presentations, or recording have been published there.

What the Draft Actually Asks For

The draft runs to six pages with ten numbered sections and a glossary¹. Its scope statement does most of the work. It applies to computerized systems used in the manufacture of medicinal products and active substances where AI models are used in critical applications with direct impact on patient safety, product quality, or data integrity. It describes itself as additional guidance to Annex 11 for computerized systems in which AI models are embedded. It applies to machine learning models that obtained their functionality through training with data rather than explicit programming. And it applies only to static models with deterministic output. Dynamic models that keep learning in use, and models with probabilistic output that might give different answers to identical inputs, are outside its scope and, in the draft’s words, should not be used in critical GMP applications. Generative AI and large language models are named explicitly as falling in that excluded group.

Inside that scope, the expectations fall into ten groups. The draft’s own section numbers are given here because the mapping table refers to them.

• Principles (section 2): close cooperation between process subject matter experts, QA, data scientists, IT, and consultants during algorithm selection, training, validation, testing, and operation; documentation reviewed by the regulated user whether the model was built in-house or by a supplier; and activities scaled by quality risk management.
• Intended use (section 3): a detailed description of the model’s intended use and the tasks it assists or automates, including a full characterization of the input data and all common and rare variations (the draft calls this the input sample space), identified limitations and possible erroneous or biased inputs, division of the input space into subgroups where applicable, and a process SME who approves the description before acceptance testing starts. Where a human operator uses the model output to make a decision and testing effort has been reduced on that basis, the operator’s responsibility is part of the intended use.
• Acceptance criteria (section 4): case-dependent test metrics (the draft gives a confusion matrix, sensitivity, specificity, accuracy, precision, and F1 score as examples for a classifier), acceptance criteria that may differ by subgroup, SME approval of the criteria before testing, and a “no decrease” rule: the acceptance criteria should be at least as high as the performance of the process the model replaces, which means that performance has to be known.
• Test data (section 5): representative and stratified selection across all subgroups, sufficient size for adequate statistical confidence per subgroup, verified labeling with a very high degree of correctness, pre-specified pre-processing, documented and justified exclusions, and a recommendation against generating test data or labels with generative AI.
• Test data independence (section 6): technical or procedural controls ensuring that test data is never used in development, training, or validation; if test data is split from a pool before training, the people developing and training the model must never have had access to it; the test data is protected by access control and audit trail with no copies outside the repository; a record of which data was used for testing, when, and how many times; the same rule for physical test objects; and staff independence, with a four-eyes fallback where full separation is impossible.
• Test execution (section 7): a test that shows the model generalizes to new data and is not over- or underfitted, an approved test plan containing the intended use summary, the metrics and criteria, a reference to the test data, a step-by-step script, and the metric calculation method; documented and investigated deviations; and retention of the test documentation, the intended use description, the test data characterization, the actual test data, and the access control and audit trail records.
• Explainability (section 8): during testing of models in critical applications, the system should capture and record the features in the test data that contributed to each classification or decision, using techniques such as SHAP values, LIME, or heat maps where applicable; and a review of those features should be part of the approval of test results.
• Confidence (section 9): where applicable, log the confidence score for each prediction, and set a threshold so that low-confidence outputs are flagged as “undecided” rather than returned as unreliable predictions.
• Operation (section 10): the model, the system it is implemented in, and the whole process it automates or assists go under change control before deployment; any change to the model, the system, the process, or the physical objects the model uses as input is evaluated for retest, with any decision not to retest fully justified; configuration control with measures to detect unauthorized change; regular monitoring of the defined performance metrics; regular monitoring that inputs are still within the model’s sample space, with defined drift metrics; and human review records where a human-in-the-loop arrangement reduced the testing effort.
• Glossary: the definition of an AI system tracks the wording of Article 3(1) of the EU AI Act, Regulation (EU) 2024/1689¹⁰, which matters because it means the GMP text and the horizontal EU law will not disagree about what an AI system is.

Two features of this list should stand out to anyone who has managed a CSV program. First, most of it is testing discipline: metrics, criteria, data, independence, execution, records. Second, the draft repeatedly names a specific accountable role, the process subject matter expert, for approving the intended use description, the acceptance criteria, and the test plan. That is a person, not a data scientist, and not QA acting alone. Both features are why the mapping to an existing validation package works as well as it does.

The CSV Package You Already Have

The typical package for a GxP computerized system in a pharma or biotech company follows the GAMP 5 lifecycle. GAMP 5 Second Edition, published by ISPE in July 2022, kept the framework of the first edition, made explicit that its specification and verification approach supports iterative and incremental development as well as linear development, emphasized critical thinking by knowledgeable SMEs, and expanded its appendices to cover artificial intelligence and machine learning among other newer topics⁷. The older PIC/S guidance on computerized systems, PI 011-3 from 2007, describes the same shape in regulator language: a user requirements specification, a functional specification, design specifications, and a system build, verified in turn by installation, operational, and performance qualification, with the regulated user expected to define the relationships between the lifecycle elements for their own model¹¹.

For the purposes of this exercise, the package consists of the following deliverables. Names vary between companies, so the function of each matters more than the label.

That is the vocabulary the mapping uses. One caution before the table: this is a mapping of the draft’s expectations to deliverables, not a claim that the deliverables as currently written satisfy the draft. The verdict column is where that distinction lives.

The Mapping Table

The table uses three verdicts. Covered means the existing deliverable already answers the expectation in substance and needs at most a wording check. Add section means the deliverable is the right home but needs new content that it does not carry today. New means no existing deliverable in a typical package answers the expectation, and pretending otherwise would leave a gap an inspector could find in minutes.

Counting the verdicts: three rows are covered, fifteen need an added section, and four are new. Those four rows produce five new deliverables, because the model description is derived from the scope and model selection rows rather than being a row of its own. Two of the five (the baseline study and the explainability capture) are closely tied to existing deliverables and could be folded into them by a team that prefers fewer documents. The other three (test data independence, the model description discussed below, and drift monitoring) are new in substance no matter how you file them.

Row-by-Row Commentary

The URS carries more weight than it used to

In a conventional package the URS says what the system must do. For a model, the draft asks the URS to also say what the system will see: the full input sample space, including rare variations, known limitations, and inputs that could be erroneous or biased. That is a different kind of writing. It requires the process SME to describe the data, not just the function, and the draft makes that SME responsible for the adequacy of the description. Companies whose URS templates are written by IT or by the supplier will find this the hardest section to fill, because the knowledge lives with the people who run the process. It is also the section that feeds everything downstream: subgroups come from it, test data stratification comes from it, and drift monitoring is defined against it. If the URS section is thin, every later deliverable inherits the gap.

Metrics replace scripts in the PQ

Most PQ protocols are written as scripted steps with expected results and a pass or fail. A classifier does not verify that way. The draft’s acceptance criteria section asks for suitable metrics, and for a classification task it lists a confusion matrix, sensitivity, specificity, accuracy, precision, and F1 score as examples. Criteria may differ by subgroup, and they must be approved by the SME before testing begins¹. In practice this means the PQ protocol gains a statistics section: which metrics, computed how, on which subgroup, against which threshold, with what sample size justification. The rest of the protocol structure, approvals, execution records, deviations, and a report, is unchanged, which is why this row is “add section” rather than “new.”

The “no decrease” rule creates a deliverable most teams do not have

Clause 4.3 says the acceptance criteria should be at least as high as the performance of the process the model replaces, and that this implies the performance of the replaced process should be known. Very few companies have measured the sensitivity and specificity of their manual visual inspection, their manual plate reading, or their manual peak review. Without that number the model’s acceptance criteria are arbitrary. This is why the baseline study is listed as new. It is often small, it is usually informative regardless of the AI project, and it should be started early because it takes calendar time to collect enough human decisions to characterize.

Test data independence is the row with the sharpest edge

Section 6 is the most prescriptive part of the draft, and it has no counterpart in a CSV package. Test data must never be used in development, training, or validation. If it is split off before training, the people who develop and train the model must never have had access to it. The repository must be access controlled and audit trailed, there must be no copies outside it, and there must be a record of which data was used for testing, when, and how many times. Staff who have seen the test data must be kept out of training and validation, with a four-eyes rule as a fallback¹.

The reason regulators care is well documented outside pharma. Kapoor and Narayanan’s 2023 review of machine-learning-based science identified leakage between training and test data as a widespread cause of results that could not be reproduced, and proposed model information sheets as a countermeasure¹⁴. The FDA, Health Canada, and MHRA’s joint 2021 guiding principles for good machine learning practice, written for medical devices but instructive here, state the principle in one line: training and test datasets are selected and maintained to be appropriately independent of one another, with all potential sources of dependence considered and addressed¹⁵. The draft turns that principle into GMP-style evidence. A team that already runs a controlled data repository with audit trails for other GxP data has the tooling. What it lacks is the record that ties the repository to this model: who could see what, when, and the log of every test run against it.

Explainability is a test record, not a product feature

It is easy to misread section 8 as requiring an explainable model. It does not. It requires that during testing of a model used in a critical application, the system captures and records the features in the test data that contributed to each decision, using techniques such as SHAP values, LIME, or heat maps where applicable, and that a review of those features is part of the approval of test results¹. SHAP, introduced by Lundberg and Lee in 2017, assigns each input feature a contribution value for an individual prediction¹². LIME, introduced by Ribeiro, Singh, and Guestrin in 2016, fits a simple local model around an individual prediction to explain it¹³. Both are model-agnostic and both produce artifacts that can be stored. The new deliverable is that stored artifact plus the SME’s documented review of it, asking one question: is the model deciding on relevant and appropriate features, or on something incidental like a label position, a lighting artifact, or a site-specific background?

Confidence thresholds belong in the functional specification

Section 9 is straightforward to place. Logging a confidence score per prediction and applying a threshold that routes low-confidence outputs to “undecided” are functions. They belong in the FS and the configuration specification, and they get verified in OQ like any other function. The design decision that needs an SME is where the threshold sits and what happens to an undecided output, which links back to the human-in-the-loop description in the URS.

Change control needs new triggers, not a new procedure

Clause 10.1 puts the tested model, the system, and the whole process it automates under change control before deployment, and requires that any change to the model, the system, the process, or the physical objects the model uses as input be evaluated for retest. A decision not to retest must be fully justified¹. Every company has a change control procedure. What it lacks is the trigger list: a new camera, a new media supplier, a relocated inspection station, a software update to the inference runtime, a retrained model version from the supplier. Adding those triggers and a mandatory retest evaluation is an “add section” change. The harder case is a supplier-hosted model that can change without the customer’s knowledge. Commentary on the draft has pointed out that hosted models weaken change and configuration control unless versioning, observability, and contractual terms make model updates detectable triggers for requalification⁶. That is a supplier assessment and contract question, which is why the supplier assessment row also gets an added section.

Periodic review gains two monitoring streams

Clauses 10.3 and 10.4 ask for two different kinds of monitoring. The first is performance monitoring: recalculating the defined metrics regularly to detect changes in the computerized system, with the draft giving deterioration or a change in lighting as examples. The second is input monitoring: checking that inputs are still within the model’s sample space and intended use, with defined drift metrics¹. The first fits naturally into an existing periodic review. The second is new because a periodic review looks at the system, and drift monitoring looks at the world the system is seeing. It needs its own metrics, thresholds, and a defined response, which is why it is listed as a new monitoring plan rather than a section in the review procedure.

The Genuinely New Deliverables

Pulling the “new” verdicts together, and adding one that the draft implies rather than names, a team should expect to create five things it does not have today.

Everything else in the draft is an added section to a deliverable the team already owns. That is the practical message of the mapping: this is not a second validation system. It is the same system with a model in it, and the model brings its own data, its own evidence, and its own monitoring.

Worked Example: A Static Classifier in a QC Microbiology Lab

To show how the mapping behaves on a real system, take a hypothetical but typical case. A QC microbiology laboratory at a biologics site images incubated environmental monitoring plates on a bench-top imaging station and uses a static convolutional neural network to classify each image as “growth” or “no growth.” Plates flagged as growth go to a microbiologist for full reading and identification. Plates flagged as no growth are read by a microbiologist on a sampling basis rather than in full. The model was trained by the imaging station supplier on pooled images from several customers and delivered with frozen weights. Every figure below is illustrative, chosen to show the shape of the deliverable rather than to recommend a value.

Is it in scope?

Yes. It is a trained model, it is static (frozen weights, no learning in use), and it is deterministic (the same image produces the same output). It is used in a critical application, because a missed growth plate has a direct impact on product quality decisions and on the integrity of the environmental monitoring record. The human-in-the-loop arrangement reduces testing effort on the no-growth side, which means clauses 3.3 and 10.5 apply. The scope classification goes into the risk assessment.

The deliverables, one at a time

Two observations from working through it. First, the site’s data scientist, if there is one, is deliberately excluded from the test data repository. That feels wrong to teams who are used to the most technical person having the most access, and it is the point of section 6. Second, the largest single effort is not any document. It is producing enough verified, labeled, independent test plates across all subgroups to compute the metrics with the stated confidence. Rare variations are rare, and collecting enough cracked-agar or pigmented-media plates to test those subgroups takes time. Start collecting before the paperwork is finished.

The Generative AI Question

The mapping above applies to static, deterministic models, because that is what the draft covers. The question every leadership team asks next is what to do about generative AI, and it deserves an answer built only from what EMA has said in public.

What the draft says

The draft states that dynamic models that continuously learn and adapt during use are not covered and should not be used in critical GMP applications, that models with probabilistic output are likewise not covered and should not be used in critical GMP applications, and that, following from those two rules, the document does not apply to generative AI and large language models, which should not be used in critical GMP applications. If such models are used in non-critical GMP applications, which do not have direct impact on patient safety, product quality, or data integrity, adequately qualified and trained personnel should always be responsible for ensuring the outputs are suitable for the intended use, and the principles of the document may be considered where applicable¹. The draft also, in its test data section, says that generating test data or labels by means of generative AI is not recommended and any such use should be fully justified.

What EMA has said since

EMA’s event page for the June 30 to July 1, 2026 workshop states that the 2025 stakeholder consultation suggested support for potentially enabling the use of technologies such as generative AI or large language models in medicines manufacturing, notes that the draft had indicated that dynamic, adaptive, and probabilistic models should not be used in critical GMP applications, and says the drafting group, in collaboration with the Quality Innovation Group, sought expert input on possible control and mitigation measures such as guardrails as part of a proposed risk-based approach. EMA expects the workshop to produce a report with expert input. The draft agenda shows the open day was structured around six topics, with industry associations presenting on regulatory pathways for adaptive and probabilistic models, risk and compliance limits, human oversight and accountability, technical reliability and incident response, validation and lifecycle management, and cybersecurity and outsourced activities⁴. Trade press coverage before the event described it as a reassessment of the draft’s generative AI position following the consultation feedback, and EMA has published no timeline for the final text⁵.

That is the full public record. EMA has not published a revised position, a report, or a date. Anyone who tells you the generative AI exclusion has been lifted, or that it has been confirmed, is ahead of the source.

What to do now

Three things follow from the record as it stands. First, inventory every generative AI use that touches a GMP activity and classify each one as critical or non-critical using the draft’s own test: direct impact on patient safety, product quality, or data integrity. Second, for the non-critical uses, apply the human-in-the-loop principle exactly as the draft describes it, and document the intended use, the operator’s responsibility, and the review record using the same URS and SOP sections the mapping table already identified. That way, if the final text extends scope, the documents are already in the right shape. Third, for anything critical, hold. The draft says not to, EMA has not said otherwise, and the technical problems that make a static-model mapping tractable (fixed weights, known training data, deterministic output, feature attribution that means something) are exactly the properties a hosted language model does not offer. Commentary on the draft has made the same point about why validation-style requirements such as provable test-set independence and calibrated confidence thresholds do not transfer cleanly to language models⁶. The interesting policy question, whether procedural guardrails and human accountability can substitute for those properties, is precisely what EMA asked its experts, and the answer is not yet public.

One more practical note. The ISPE article that accompanied GAMP 5 Second Edition’s AI appendix observed that human oversight and interpretability were not directly covered by GAMP 5, and that Appendix D11 addressed them only to some extent⁹. The draft Annex 22 fills exactly that gap for static models. Whatever the final text says about generative AI, the human oversight sections of the draft are the parts most likely to survive intact, and they are the parts worth building into procedures first.

Sequencing the Work Before the Final Text Arrives

The mapping is only useful if it turns into a sequence a quality team can run in the next two quarters without betting on a date. This is the order we would suggest.

Peer-reviewed commentary on the draft has already begun to describe it as a structured, risk-based framework defining expectations for intended use, validation, life cycle management, explainability, and human-in-the-loop oversight, and to examine its alignment with continued process verification practice¹⁶. That framing is consistent with the mapping here. The draft is not asking for a new discipline. It is asking the existing validation discipline to extend to a new kind of component and to produce evidence about data and decisions that it has not had to produce before.

Conclusion

Draft Annex 22 is short, specific, and unfinished. The consultation closed almost a year ago, EMA’s working group has given itself a Q4 2026 target to hand a final text to the Commission, the generative AI scope is being reconsidered in public, and nothing has been published about a publication date or a transition period. In that situation the wrong move is to build a standalone AI compliance program around guessed dates and guessed wording. The right move is to map the draft’s expectations onto the validation deliverables a pharma or biotech company already maintains, add the sections those deliverables are missing, and create the small number of genuinely new records the draft requires: a model description, a baseline study of the replaced process, a test data independence record, an explainability review, and an input drift monitoring plan. Done that way, the work survives whatever the final text says, because it is filed where inspectors already look and owned by the people who already sign.

Sakara Digital works with pharma and biotech organizations that are trying to bring trained models into GMP systems without building a second validation system alongside the first. If you are running this mapping against your own package and want an independent view of which rows are really covered, which need a section, and which need something new, we are happy to have that conversation.

For Further Reading