AI in GMP Manufacturing: A Practical Guide for Quality Professionals

What “AI in GMP” actually means in practice

The term AI covers a wide spectrum of capabilities, and not all of them are equally suitable for regulated environments.

At one end of the spectrum, you have narrow, deterministic models: classifiers trained to detect specific defects, regression models predicting a process parameter, anomaly detection algorithms flagging unusual sensor readings. These have well-understood behaviour, can be tested with defined acceptance criteria, and fit reasonably well within existing validation frameworks.

At the other end of the spectrum, you have large language models (LLMs) and generative AI: systems that can read a deviation report, draft an investigation summary, retrieve the relevant SOP, and suggest a CAPA. These are genuinely useful, but they are probabilistic, non-deterministic, and more difficult to validate in the traditional GMP sense of the word.

Most of the practical value for quality professionals right now sits in a middle ground: using AI to orchestrate tasks, aggregate evidence, and support human decision-making, rather than to make decisions autonomously.

Where AI actually adds value in QA workflows

The highest-value applications share a common pattern: they tackle work that is time-consuming, repetitive, and dependent on pulling information together from multiple systems. These are also the areas where human error is most likely, not because quality professionals are careless, but because reconciling data across an MES, LIMS, QMS, and historian is genuinely hard.

Batch release evidence assembly is a good example. Before a batch can be released, someone needs to confirm that equipment was calibrated, environmental monitoring was within limits, all deviations are assessed, lab results meet specification, and dozens of other checks are complete. Today, that process often involves navigating multiple systems and manually verifying each item. An AI system can assemble this evidence packet automatically, flag anything missing or inconsistent, and present it to the QP or quality unit for review. The release decision stays with the human while the tedious information-gathering is automated.

Deviation investigation support is another strong use case. When a deviation is logged, an AI system can extract structured information from the report, link it to relevant equipment records and production data, and search historical deviations for similar incidents. This can meaningfully accelerate the early stages of an investigation and improve consistency across sites or investigators.

CAPA tracking and effectiveness monitoring is unglamorous but important. AI can decompose an agreed CAPA into tasks, route approvals, track due dates, and trigger effectiveness checks, reducing the administrative overhead that often causes CAPA programmes to slip.

Continuous process verification and anomaly detection is where narrower, validated models shine. A model trained to detect multivariate anomalies in CPP/CQA data can surface process drift earlier than traditional univariate control charts, creating an opportunity to intervene before a batch is affected.

The regulatory picture: what you need to know

The regulatory landscape for AI in GMP is evolving, and the details matter. This section covers what you need to act on. For the side-by-side view of both regulators, and a fuller account of what the June 2026 EMA workshop put on the table, see our FDA and EMA perspectives on AI in pharmaceutical manufacturing.

In the EU, any computerised system used in GMP activities falls under Annex 11. This means validation, audit trails, access controls, periodic evaluation, and supplier oversight are all required regardless of whether the system uses AI. AI does not create a special exemption from these requirements.

The draft EU GMP Annex 22, published for consultation in July 2025, adds AI-specific requirements on top of Annex 11. Its scope is narrow. It covers static models, meaning models whose parameters are fixed after training, used for classification, prediction, and process monitoring in critical GMP applications. Dynamic or continuously learning models, probabilistic-output models, and generative AI sit outside that scope, and the draft states they should not be used in critical GMP applications. For non-critical tasks it expects a documented human-in-the-loop responsibility.

As drafted, Annex 22 restricts generative AI in critical GMP work. You will hear the argument that being out of scope only means being governed somewhere else, and there is something to it, because LLMs do fall back on Annex 11, data integrity requirements, and the general principle that any system used in GMP must be fit for intended use, validated on a risk basis, controlled, and traceable. But treating the clause as a technicality understates it. The restriction was written deliberately, and it is the part of the draft that has drawn the most argument.

That argument is still running. The consultation closed in October 2025, and the EMA reads the responses as suggesting support for enabling generative AI in manufacturing rather than prohibiting it, which is a striking thing for an agency to say about its own draft. At the end of June 2026 it convened a multistakeholder workshop to hear how adaptive and probabilistic models (like LLMs) can be controlled in practice, with the drafting group largely listening rather than defending the text. Industry associations put a joint position to that workshop: no model should be excluded or permitted because of its label, and acceptability should follow from demonstrated risk control for a specific intended use, governed by ICH Q9(R1).

None of that is settled. It is what industry asked for, not what the regulator has agreed, and the revised Annex 22 has not been published. The draft as written still says what it says. What has changed is the balance of probability. A final text built on principles that apply to any model now looks more likely than one that names model families. So build for both. Assume the restrictive reading when you plan a critical application today, and produce the risk documentation and performance evidence that would also satisfy a risk-based text if that is where this lands.

In the US, 21 CFR Part 211 and Part 11 apply. FDA's data integrity guidance requires that records created by computerised systems maintain ALCOA principles: attributable, legible, contemporaneous, original, and accurate. Any AI system that creates or modifies GMP-relevant records must satisfy these requirements.

ICH Q9 and Q10 provide the risk management and quality system framework that should govern how AI is integrated: intended use drives risk classification, which drives validation depth, change control, and monitoring.

Two lanes, sorted by risk rather than by model type

A useful way to think about AI deployment in GMP is a two-lane model. What decides the lane is the consequence of getting the answer wrong, not the technology producing it.

Sorting by technology might be the intuitive reasoning (it is what the current draft of Annex 22 does), but it breaks down quickly. A small locked classifier that automaitically defines a release step can carry far more risk than a language model drafting a summary that a reviewer might rewrite anyway. ICH Q9(R1) already gives you the better sorting tool through its formality concept, driven by how important it is to be correct, how much you do not know, and how complex the problem is. For AI, add detectability, because a wrong answer that goes unnoticed is more serious than one that is easily caught.

Lane A is high formality: anything that directly affects patient safety, product quality, or data integrity. The sharpest working definition of direct impact is an automated step connected to release with no other activity able to catch a defect. Lane A needs the full evidence package. Defined acceptance criteria, independent test data, explainability capture, drift monitoring, and change control before any update. In practice this is where locked, static models mostly live today because that is where the evidence is currently easiest to produce.

Lane B is lower formality: drafting, summarising, retrieving, and orchestrating, where a human reads the output before it goes anywhere. This is where most LLM-based tools sit. The key controls are human review before any output influences a GMP record, auditable prompt and output logging, and a clear procedural definition of what the tool can and cannot do. This support lane is also where AI agents in GMP quality assurance become most relevant.

The two-lane split is a heuristic about where the evidence burden sits, not a regulatory boundary. It happens to line up with the technology split in the current draft of Annex 22, which makes it a safe way to plan right now. But the QRM argument runs the other way: if you can demonstrate control of a probabilistic model for a specific Lane A use, that use should be assessable on the evidence rather than refused on the label. (Note: whether the final Annex 22 accepts that is an open question.)

Most organisations should start in Lane B. The compliance burden is lower, the value is immediate, and the experience builds the organisational capability to tackle Lane A over time.

What “human in the loop” actually requires

Human-in-the-loop is sometimes treated as a phrase that makes AI use acceptable by default. In GMP, it has specific operational meaning.

It means a qualified person reviews the AI output before it influences a GMP record or decision. It means that review is documented, with the reviewer's identity and timestamp captured in a compliant audit trail. It means the reviewer has the training, context, and authority to actually evaluate the output, not just click approve. And it means the system is designed so that the AI recommendation is clearly distinguished from the human decision.

In practice, this often means the AI generates a draft or recommendation, the QA reviewer edits, approves, and preferably both the AI output version and the approved version are retained. The eQMS or eDMS surrounding the AI tool carries the Annex 11 / Part 11 obligations.

The validation question

Quality professionals often ask: how do you validate an AI system?

The answer that holds up is that evidence sits in three places, and you need something at each. First, the computerised system around the model, which is ordinary Annex 11 territory: access control, audit trail, change control, periodic evaluation. Second, the AI component itself, meaning whether the model does what it is supposed to do on test data that represents real use, measured against acceptance criteria you agreed before running the test. Third, the guardrails, meaning whether the controls you wrapped around the model actually work when they are needed. How deep you go at each layer scales with the risk of the use case.

For Lane A models, this is structured and familiar in principle, though the specifics are new. You define intended use, characterise the input space, establish test metrics and acceptance criteria, use independent test data, document explainability elements (feature attribution, confidence scores), set thresholds for “undecided” outcomes when confidence is low, and establish a drift monitoring programme. Draft Annex 22 is specific about all of this.

For Lane B LLM tools, the tempting shortcut is to say you validate the process and not the model. It is convenient, but it is wrong. The process controls are real work and you still need them: documented intended use with explicit boundaries, a defined HITL (human in the loop) workflow, prompt templates under version control, output logging and audit trail, periodic review of outputs for quality and compliance, and change control that treats prompt changes, model version changes, and dependency updates as reasons to reassess. But those are the first and third layers. The middle layer does not disappear because the model is hard to measure.

What the middle layer means for a language model is that you have to have looked at how it fails on your task. Hallucinations are a familiar one. Sycophancy matters more than people expect in QA work, because a model that accepts the framing of a badly written deviation description will confidently investigate the wrong thing. Overconfidence in exactly the areas where a model is weakest is the third. You cannot claim a system is fit for its intended use against failure modes you never went looking for. In practice this means a held-out set of task inputs that look like your real ones, a defined way of scoring the outputs, an acceptance bar set before you run it, and a rerun whenever the model version changes.

Neither approach is simple. The mistake is trying to apply traditional software validation directly to a generative model, or skipping the model layer altogether because measuring it is difficult.

Practical starting points

For quality professionals looking to move from curiosity to action, a few principles help.

1. 1

   Start narrow. Pick one workflow where the value is clear and the GMP criticality is manageable. Prove the concept, build the validation documentation, and learn from it before expanding.

2. 2

   Treat it as a Pharmaceutical Quality System element from day one. The intended use definition, risk assessment, validation plan, and CAPA linkage all belong in the quality system from the start.

3. 3

   Do not let the vendor define your compliance posture. Suppliers of AI systems are often unfamiliar with Annex 11 or Part 11 requirements.

4. 4

   Plan for drift. Unlike traditional software, AI models (and especially large language models) can change in performance, even if no code changes. Build performance monitoring and periodic evaluation into the operating model before you go live.

5. 5

   Build evals into AI and agentic workflows from the start. Define what good output looks like before you deploy, not after. Make success criteria explicit and machine-readable so the system can score its own outputs, iterate, and self-correct before a result reaches a human reviewer. An AI that cannot measure its own performance against a defined bar will drift silently; one that can will surface failures early and compound improvements over time.

Where this is heading

The revised Annex 22 is the document to watch out for. Two questions in it matter more than the rest. Whether the final text still names model families, or replaces that with principles you apply to any model. And how it treats models that update themselves after deployment.

Annex 22 also does not arrive on its own. It is co-drafted with PIC/S so that inspectors outside the EU read it the same way, and it moves alongside a revised Annex 11 and an updated Chapter 4. The computerised systems baseline your AI controls attach to is shifting at the same time as the AI guidance itself, which is worth planning for if you are currently writing procedures.

Two technical problems will outlive the drafting as they are engineering problems. The first is detectability. If a model gives you a wrong answer, would anything downstream catch it, and can you show that it would? The second is that a language model has no reliable error bound. With a statistical model you can characterise how often and how badly it is wrong. Nobody can currently tell how often a given model will fabricate on a task.

The potential is still VERY real however. Evidence assembly, investigation support, and process monitoring are better candidates for AI than most enterprise knowledge work, because the data is structured, the tasks are well-defined, and the value of consistency is high. Getting there requires treating AI with the same rigour applied to every other GMP system.