The model that passed validation in January isn't the model running now
Picture a QA lead walking an inspector through a CAPA root-cause workflow that leans on an ML classifier. The inspector points at one record and asks a simple question: which version of the model produced this output? The lead knows the model was validated in January. What she can't say, from the record in front of her, is whether the model that scored this case in March was the same one. A scheduled retrain ran in February. The weights moved. Nobody wrote a line of code, nobody opened a change request, and the validation binder on the shelf still describes the January model.
The record is signed, the audit trail is clean, and the human approval is all there. But the one attribute that ties the regulated decision to the software that shaped it, the model version, was never captured. The validation package describes a system that no longer exists.
That's the gap GAMP 5 Second Edition set out to close, and it's the gap most eQMS deployments still carry.
What traditional Category 5 quietly assumed
GAMP 5's software categorisation has worked for two decades on a quiet assumption: the software you validated is the software you'll be running tomorrow. Category 1 (infrastructure) shifts only when IT updates the operating system. Category 3 (non-configured COTS) shifts when the vendor releases a new version. Category 4 (configured) shifts when you change the configuration. Category 5 (custom application) shifts when your team, or your contracted developer, writes new code, and the change is captured under change control with a re-validation decision.
In every category, the what of the software is anchored in time. A validated state on Tuesday is a validated state on Wednesday unless something explicitly changed. The validation evidence is a package produced once, retained, and updated when the explicit change happens: protocols, executed test cases, traceability matrix, validation summary.
AI breaks this assumption in a specific way. An ML model in production today isn't the same model that was in production six months ago, even if no one wrote a single line of code. The weights drifted because new training data was incorporated. The behaviour shifted because the input distribution changed under it. The decision boundary moved because a periodic retrain ran on schedule. None of these are change-control events under the traditional framework. They're operational events. But the regulated behaviour the validation package described is no longer the regulated behaviour the system is exhibiting. The framework has a category for what the software is, and no category for what it has become.
What Appendix D11 actually adds
GAMP 5 Second Edition, published by ISPE in 2022, added Appendix D11 on Artificial Intelligence and Machine Learning specifically to address this gap. The appendix doesn't create a new category. It extends the existing Category 5 framing with an ML-aware lifecycle: model concept, model development, model validation, deployment, post-deployment monitoring, and retraining or refresh.
The most useful thing D11 does is make the loop explicit. The lifecycle isn't a one-time validation followed by maintenance. It's a recurring cycle where each phase produces evidence the next phase consumes:
- Model development produces a training-data snapshot.
- Validation produces baseline performance metrics.
- Deployment produces inference logs.
- Post-deployment monitoring produces performance trend data.
- When that data drifts, it triggers a retrain decision, which loops back to a fresh training-data snapshot.
The validation evidence isn't a deliverable at the end of a project. It's a stream the system produces continuously.
ISPE supplemented D11 in July 2025 with a standalone GAMP Guide: Artificial Intelligence, a 290-page document extending the appendix-level guidance into a full reference framework. The expanded guide doesn't change D11's lifecycle logic; it works it out in operational detail across pharma manufacturing, lab, and quality scopes.
Static vs dynamic ML, the distinction that decides everything
The single classification decision that drives most of D11's downstream requirements is whether the deployed ML system is static or dynamic.
A static ML system is trained once, deployed, and frozen in production. Performance can drift if the input distribution shifts, but the model itself doesn't change. A dynamic ML system retrains on a schedule, on a trigger, or continuously. The model in production today is, by design, different from the model deployed last quarter, so the training pipeline, the data refresh, the retraining trigger, and the deployment gate are all part of the validated system rather than external operational events.
The two invite different validation strategies:
| Static ML | Dynamic ML | |
|---|---|---|
| Model after deployment | Frozen; validated state persists | Changes by design, on schedule or trigger |
| What's in validation scope | The model at point-in-time | The change architecture itself |
| Primary control | Traditional Category 5 protocols + periodic review | Predetermined Change Control Plan (PCCP) or equivalent |
| Main drift risk | Input distribution shifts under a fixed model | Each retrain moves the decision boundary |
| Ongoing evidence | Periodic-review cadence to catch drift | Continuous monitoring + per-retrain records |
Without a documented change envelope, every retrain of a dynamic system is theoretically a change-control event requiring a fresh validation cycle. That doesn't scale and isn't operationally feasible for any production ML deployment, which is exactly why the PCCP exists.
Three regulator documents that now layer onto GAMP 5
GAMP 5 is industry guidance: ISPE-published, used by regulators as a reference but not statutory. Three regulator-issued documents now sit on top of it for AI in regulated workflows, and each addresses a different lifecycle phase. Two are device-side, from FDA; the third is drug-side, issued jointly by EMA and FDA.
Good Machine Learning Practice (GMLP) Guiding Principles, October 2021. The foundational joint document from FDA, Health Canada, and MHRA. Ten principles spanning the model development lifecycle. Principle 4 (maintain training data sets as independent from test data sets) is the one most teams skip in practice. Principle 10 (monitor deployed models for performance and manage re-training risks) is the one D11's lifecycle operationalises.
Predetermined Change Control Plan (PCCP) Final Guidance, December 2024. FDA's mechanism for pre-approving the change envelope of a dynamic ML system. A PCCP describes, at submission time, the modifications the manufacturer expects to make post-deployment (retraining cadence, input feature changes, performance threshold adjustments), the protocols that will govern them, and the impact assessment criteria. Changes inside the envelope don't require new submissions; changes outside do.
Guiding Principles of Good AI Practice in Drug Development, January 2026. Ten principles issued jointly by EMA and FDA, covering AI in drug development specifically, with a stronger lifecycle and human-oversight framing. They are explicitly non-binding — a foundation for good practice rather than a requirement — but they signal where both regulators are heading. Principle 1 (human-centric by design) puts the Quality Unit's approval record at the centre of accountability.
GMLP covers development. PCCP covers the deployment-change envelope. The EMA–FDA principles cover ongoing human accountability. Together they cover the gaps Appendix D11 anchors at the framework level.
GMLP Principle 10, the retrain-risk principle
The GMLP principle that most directly maps to operational eQMS records is Principle 10: monitor deployed models for performance and manage re-training risks. It assumes three things the validation evidence has to demonstrate.
First, that deployed model performance is monitored against defined metrics at a defined cadence: accuracy, false-positive rate, false-negative rate, calibration error, or whatever metric corresponds to the intended use. The monitoring isn't an annual review; it's a continuous stream, with thresholds that trigger investigation.
Second, that retraining itself is a controlled event. When monitoring triggers a retrain, the retrain runs through a documented protocol. The new training-data snapshot is identified, the validation against the test set is executed, the performance against the prior baseline is compared, and the decision to deploy the retrained model is approved by named roles. Each step produces an audit-trail entry.
Third, that the retrain creates a new model version with its own identity, and the regulated decisions made by that version are traceable to it. A clinical decision support output from January is attributable to model version 4.2.1. The same kind of output from March is attributable to version 4.3.0 if a retrain happened in between. That traceability is what lets post-market surveillance, incident investigation, and recall scope determination function.
Most existing eQMS deployments don't carry model-version-as-record-attribute discipline. It's not an absence of will; it's an absence of architectural primitive. The eQMS records the human approval; the AI inference happens upstream. Without a record-level attribute carrying model identity, the traceability Principle 10 demands is a manual lookup against deployment logs, which is what inspections are now starting to probe. It's the same class of problem that surfaces in the multi-tenant SaaS audit-trail problem: the evidence exists somewhere, but not attached to the record an inspector is holding.
The PCCP architecture, pre-approving the change envelope
The Predetermined Change Control Plan is FDA's mechanism for letting dynamic ML systems update inside a documented envelope without triggering a fresh submission every time. It has three components that map cleanly to eQMS workflow records.
- The plan itself. A document submitted with the marketing application describing the modifications the manufacturer expects to make post-deployment: the retraining triggers (calendar-based, performance-based, data-volume-based), the data sources that feed retraining, the performance thresholds the retrained model must meet, the validation protocol that will be executed, and the deployment gate it must pass.
- The protocol. The procedure describing how each in-envelope change will be executed: retraining protocol, validation protocol, performance comparison protocol, and deployment rollback protocol if the retrained model fails acceptance criteria. Each is a controlled document, versioned and electronically signed.
- The impact assessment criteria. The rules that decide whether a proposed change is inside the envelope (proceed under PCCP) or outside (requires new submission). This is the gate that determines whether a retrain triggers full change control or runs under PCCP authority. Documented, signed, and audit-trailed.
The PCCP is conceptually similar to a validated process envelope in traditional GAMP 5 thinking, but operationally it's a continuous control surface, not a static document. The eQMS has to carry the PCCP as a living record, with each in-envelope change captured against it, each decision logged, and the cumulative drift from baseline tracked.
The validation evidence stream that replaces the binder
For a traditional Category 5 system, the validation deliverable is a binder. For a dynamic AI Category 5 system, it's a stream of records the system produces continuously. The shift from binder to stream is the architectural shift D11 implies even if it doesn't say so in those words.
The stream looks like this:
- At deployment, the system records model version, training-data snapshot identifier, validation set identifier, baseline performance metrics, approving roles, and deployment timestamp.
- During production, it records every inference event with model version at inference time, input payload digest, output payload digest, and downstream regulated record identifier.
- At a defined monitoring cadence, it records aggregated performance metrics against the baseline, drift indicators, threshold crossings, and investigation triggers.
- At each retrain, it records trigger source, new training-data snapshot, new performance baseline, comparison against the prior version, and deployment approval.
- At each in-envelope change under PCCP, it records the change, the PCCP clause it's authorised under, the protocol executed, and the result.
The stream isn't a new kind of evidence. It's the same evidence categories the binder used to carry, captured as event records rather than document artefacts. The advantages are structural: the evidence is always current, the audit trail is continuous, and the model version that produced a specific regulated decision is one query away.
What inspectors are starting to trace
Inspection scripts for AI-enabled regulated workflows are stabilising fast, and the pattern through 2026 is consistent. An investigator picks one record and pulls the thread:
"Show me the validation package for the model you're using in this CAPA root-cause workflow. Show me the model version that produced the output on the record you just walked me through. Show me the training-data snapshot for that version. Show me the post-deployment performance monitoring for the last twelve months. Show me the retrain decisions in that period and the records that approved them."
The questions multiply because the lifecycle multiplies. A static Category 5 system answers with one validation package. A dynamic Category 5 system answers with a stream, and the stream is either there or it isn't.
If the firm's eQMS doesn't carry model identity as a record attribute, the inspector's first question stalls. The defensible posture is to know in advance which AI-enabled workflows the firm runs, which model versions are in production, and where the validation evidence stream for each lives. The PCCP, the GMLP-aligned monitoring records, and the human-approval records the EMA–FDA principles point at all become inspection topics together.
How Complere supports an AI-enabled quality programme
Complere doesn't run your AI model. It's where the human side of an AI-enabled programme stays defensible, and that's where most of an inspector's questions actually land. In plain terms:
- The rules for your AI live as living documents. Your validation plans, your change-control plan for the model, your retraining procedures: written down, approved, and put on a review schedule, so the one that's due for another look doesn't quietly go stale.
- A model retrain is one connected story, not five loose ends. When retraining changes a procedure or a training requirement, the judgement of what it affects, the documents it updates, the retraining it sets off, and the check that it worked all hang off the same record.
- AI risk sits with all your other risk. The risks specific to a model (bias, drift, how people use its output) are weighed in the same place as everything else, and any problem found after go-live is worked the same way every other quality issue is, so a reviewer never switches tools to follow it.
- The record answers the inspector before they finish asking. Who approved the model's change plan, when it was last reviewed, what's changed under it, and what each change was judged to affect: all in the same place your team wrote it down.
- Nothing changes without leaving a mark. Every approval, edit, and sign-off is recorded against the thing it applies to, with the person and the time attached, so a change to a record becomes part of the record. Your data sits in a space of your own, apart from every other customer's.
The quality judgement stays yours, and that's the point: under a modern, risk-based approach, validation is human-run. Your AI platform owns the model and how it behaves; Complere holds the procedures, the changes, and the paper trail around them, the human-approval side an inspector asks about first.
