AI Agents in GMP Quality Assurance: Use Cases and Considerations

What agents actually do that standalone AI does not

The distinction matters because it changes both the value proposition and the risk profile.

A standalone LLM helps when the task can be handed to it in a single prompt with all the necessary context already attached. A quality professional pastes in a deviation description and asks for a draft investigation report. The model produces something useful. But it cannot go and retrieve the relevant equipment logbook, check whether a similar deviation occurred six months ago, or confirm that the CAPA from the previous incident was actually completed. All of that context has to come from the human.

An agent changes this. Given a deviation number and access to the appropriate systems, an agent can navigate each of those steps autonomously: querying the MES for the batch record, pulling the production data for the affected time window, searching historical deviations for similar incidents, checking the CAPA register for closure status, and then synthesising all of it into an investigation starter pack for the QA reviewer. The human receives a richer, more complete starting point and spends time on judgement rather than information assembly.

This is not a future capability. It is achievable today with the right architecture. The question is how to do it in a way that does not create audit trail gaps, accountability ambiguity, or compliance exposure.

Where the regulation currently stands

An agent is a deployment pattern, not a category the GMP rules recognise. What governs an agent is whatever governs the models and systems underneath it.

In the EU, any computerised system used in GMP activities falls under Annex 11, whether or not it uses AI. The draft EU GMP Annex 22 adds AI-specific requirements on top, and its (current) scope is narrow. It covers static models used for classification, prediction, and process monitoring in critical applications. Generative AI sits outside that scope, and the draft states it should not be used in critical GMP applications. Most agents run on exactly that kind of model.

The restriction on generative AI is contested however. An EMA consultation that closed in October 2025 drew responses the agency itself reads as supporting the enabling of generative AI in manufacturing rather than prohibiting it. At the end of June 2026 the EMA convened a multistakeholder workshop to hear how adaptive and probabilistic models can be controlled in practice. Industry associations argued there that no model should be excluded because of its label, and that acceptability should follow from demonstrated risk control for a specific intended use under ICH Q9(R1). That is an industry position rather than an agreed text, and the revised annex has not been published yet. So it is important to keep in mind that we cover what the workshop put on the table, and how it reads against the FDA approach, in FDA and EMA perspectives on AI in pharmaceutical manufacturing, and the practical split of workloads by risk in our guide to AI in GMP manufacturing.

For anyone building agents now, the practical consequence is that the criticality of the workflow sets the evidence bar, not the sophistication of the agent. The further an agent reaches toward a decision affecting patient safety, product quality, or data integrity, the more the burden falls on you to demonstrate control rather than to argue about scope.

Four use cases where agents deliver the most value

Deviation investigation orchestration

Deviation investigations are labour-intensive because they require evidence from many different places. The process of assembling that evidence is not where QA expertise adds value, but correctly interpreting the evidence is.

An agent configured for deviation intake can extract structured fields from a free-text deviation description (equipment ID, step in the process, time window, lot numbers affected, immediate containment actions), then automatically retrieve the relevant records from each connected system. Production data for the affected period. Equipment calibration and maintenance status at the time. Environmental monitoring results for the area. Any open or recently closed deviations on the same equipment or process step. Similar incidents from the previous two years.

The agent does not determine root cause. It assembles and structures the evidence so that the investigator can begin from a richer starting point. Investigations that currently take days to initiate because someone has to manually pull records from four different systems can begin in minutes.

Batch release evidence assembly

Batch release is a structured process with a defined set of required checks. That structure makes it well-suited to agent orchestration.

Before a batch can be released, the QA team needs to confirm a long list of conditions: batch manufacturing and testing completed per procedures, all in-process checks within specification, equipment clean status and calibration verified, environmental monitoring results acceptable, any deviations assessed and dispositioned, lab results reviewed and approved, and no open change controls affecting the batch. Today, this typically means a QA professional navigating several systems and manually verifying each item.

An agent can perform this traversal automatically, flagging anything incomplete, inconsistent, or requiring attention, and assembling the results into a structured release dossier for the QP or quality unit to review and approve. The release decision remains entirely with the authorised individual. The agent's contribution is eliminating the manual reconciliation work and reducing the risk of missed checks.

This is the highest-criticality use case on the list, and it deserves more caution. An AI system has a more direct impact when its output affects a release decision and there is no later step that would catch an error. For example, an agent assembling a release dossier does not make the release decision itself. But if the QP relies solely on the agent’s summary instead of reviewing the underlying records, an error or missed check by the agent could go unnoticed. In that case, the agent has a much more direct impact on the release decision than it looks from the outside.

Two things follow. First, this use case needs a documented risk assessment and verification that the agent retrieves completely, tested against cases where you already know the right answer. Reviewing the finished dossier does not test that, because a dossier missing a check looks exactly like a complete one. Second, the agent has to report what it could not find, not only what it found. An agent that silently omits an unreachable record produces false confidence.

Where Real Time Release Testing (RTRT) is authorised under EU GMP Annex 17, the agent's role extends further. It can compile control strategy performance data, trend analyses, alarm histories, and process parameter adherence into the RTRT evidence package that supports certification. Because RTRT relies on process data rather than end-product testing, errors in the agent's work may be less likely to be caught by a later check. This makes the reliability and verification of the agent particularly important.

Continuous process verification with escalation

Validated anomaly detection models can identify when a process is drifting outside expected behaviour. In most implementations today, someone eventually investigates it.

In an agentic, when the anomaly detection model flags an excursion in critical process parameters (CPP) or critical quallity attribute (CQA) data, the agent can immediately open a pre-populated process event record in the QMS, attach the relevant batch context, check whether any planned interventions (maintenance, material changes, cleaning events) coincide with the anomaly, and route the record to the appropriate reviewer with a defined response time. If no action is taken within a specified period, the agent escalates.

Instead of automating the investigation, it is automating the evidence assembly. The response time improves, the evidence is complete from the start, and the audit trail captures each step the agent took.

CAPA lifecycle management

CAPA workflows tend to degrade under administrative burden. Agreed actions slip past due dates. Effectiveness checks are scheduled and then forgotten. Recurrence monitoring windows expire without review. These are a failure of a manual tracking system under the sustained pressure of day-to-day QA workload.

An agent operating across the QMS and document management system can manage the operational mechanics of a CAPA lifecycle: decomposing agreed corrective actions into tasks with owners and due dates, routing approval requests, sending reminders, triggering effectiveness check workflows at the defined interval, and flagging recurrence within the monitoring window. When an effectiveness check is due, the agent can retrieve the relevant process data or inspection results and present them alongside the original CAPA to support the reviewer's assessment.

The human remains responsible for every decision, what actions to take, whether they are effective, whether to close or escalate. The agent handles the workflow that surrounds those decisions.

The specific risks that agentic systems introduce

Agents are more capable than standalone AI tools, and they introduce risks that need specific attention.

Scope creep in automated actions. An agent given broad access and a loosely defined goal can take actions that were not anticipated. In a GMP environment, this is a serious concern: a poorly configured agent that can write to a QMS could, in principle, create, modify, or close records in ways that compromise data integrity. The solution is read-only access to source systems by default, with tightly scoped and explicitly approved write permissions (possibly with a human in the loop) limited to specific record types and fields.

Audit trail fragmentation. A multi-step agent workflow involves many individual actions: queries, retrievals, transformations, tool calls and outputs. If only the final output is logged, the audit trail is incomplete. Agent actions should be logged at each step, with sufficient detail to reconstruct the full workflow, including what data was retrieved, from where, and how it was used.

Failure mode opacity. When an agent makes an error (e.g. retrieves the wrong record, misinterprets a field, or fails to find relevant historical data), the failure may not be visible in the final output. A deviation investigation that is missing a relevant historical incident looks complete. This is different from a standalone LLM hallucination, which the reviewer can inspect directly. Agents require systematic verification steps, not just review of the final deliverable. Note that this type of error can also happen in human-based failures as well.

Accountability diffusion. The more steps an agent takes autonomously, the easier it is for accountability to become unclear. In GMP, clarity of responsibility is not optional. The design of any agentic system should make it explicit at each handoff point: what the agent produced, what the human reviewer confirmed, and under whose authority the GMP record was created or modified.

What the agentic framework needs to support

A compliant agentic system in a GMP environment requires several architectural commitments that go beyond what is needed for a standalone AI tool.

Source system integration should be read-only wherever possible, with write access limited to a specific set of approved actions in specific systems. In order to increase the observability of the system, APIs should carry provenance metadata so the agent's log can record not just what data it retrieved but from which system, at what time, and from which record. This would allow reviewers to trace back agentic actions to authoritative sources. The data path also needs to respect the AI data use fine print on training and retention before GMP records touch any external model provider.

The agent's actions need to be logged at a granular level. This log should be stored in an immutable, tamper-evident format consistent with Annex 11 and Part 11 audit trail expectations.

The scope of the agent's authority, what systems it can access, what record types it can create or modify, what actions it can escalate versus take independently etc., should be explicitly defined in the intended use documentation and enforced technically, not just procedurally.

Bounded autonomy: the principle that makes agents work in GMP

The concept that holds this together is bounded autonomy. An agent in a GMP environment is not an autonomous system in the general sense. It operates within a defined scope, against defined inputs, producing defined outputs for human review, with defined escalation paths when it encounters something outside that scope.

Bounded autonomy means the agent knows what it is allowed to do, what it is not allowed to do, and what to do when it is uncertain. A deviation investigation agent that cannot find a matching historical incident should flag the gap, not silently omit it from the output.

These are design choices of the agentic harness that are not inherent properties of AI agents. They require explicit definition and implementation. But they are what allow an agentic system to add genuine value in a GMP environment without compromising the integrity of the quality system it is supporting.