Drift Monitoring as a Continued Process Verification Activity

Stage 3 Already Describes What Drift Monitoring Needs to Be

FDA’s guidance on process validation, issued in January 2011 as Revision 1, splits validation into three stages: process design, process qualification, and continued process verification.^{1 2} The third stage is the one that matters here. Its stated goal is continual assurance that the process remains in a state of control, described in the guidance as the validated state, during commercial manufacture. The guidance is direct about what that requires: a system or systems for detecting unplanned departures from the process as designed is essential to accomplish this goal.

Substitute the word model for the word process and read that sentence again. A deployed model that was qualified against a test dataset and then released into routine use is in exactly the position of a process that passed process performance qualification and then started making commercial batches. The qualification evidence describes performance under a known set of conditions. It says nothing about what happens in month fourteen when the supplier of a raw material changes, when a camera lens fogs, when a new site joins the network, or when the mix of products running through the line changes.

What the guidance actually tells you to do

The Stage 3 section is short, and almost every sentence in it maps onto a decision an AI monitoring plan has to make. An ongoing program to collect and analyze product and process data related to quality must be established. The data should be statistically trended and reviewed by trained personnel. FDA recommends that a statistician, or a person with adequate training in statistical process control techniques, develop the data collection plan and the statistical methods used to measure process stability and capability.¹

Then comes the sentence that should be printed on the front of every model monitoring plan. Procedures should describe how trending and calculations are to be performed, and should guard against overreaction to individual events as well as against failure to detect unintended process variability. That is the entire design problem of model monitoring stated in one line, fifteen years before anyone was arguing about drift detectors. Set the sensitivity too high and the team stops reading the alerts. Set it too low and the model degrades in plain sight.

The guidance also anticipates that monitoring intensity should change over time. It recommends continued monitoring and sampling at the level established during process qualification until enough data exist to generate meaningful variability estimates, after which monitoring can be adjusted to a statistically appropriate and representative level. Process variability should be periodically assessed and monitoring adjusted accordingly. For a model, that is the difference between the heavy monitoring of the first ninety days after go-live and the steady-state plan you settle into once you know what normal looks like in production rather than in the test set.

Where ICH Q10 and Annex 22 fit

ICH Q10 supplies the system that holds all of this. Its Process Performance and Product Quality Monitoring System, at section 3.2.1, is one of the four elements of the pharmaceutical quality system, alongside corrective and preventive action, change management, and management review. The ICH Q8, Q9 and Q10 Questions and Answers document makes the connection to validation explicit, noting that process validation has a lifecycle and that continual monitoring can demonstrate the actual level of assurance of process consistency and provide the basis for continual improvement of the product.^{3 4} A model monitoring program that reports into the same quality system inherits the escalation paths, the record retention rules, and the management attention that already exist. One that reports into a data science team’s internal review inherits none of them.

The draft EU GMP Annex 22 on artificial intelligence adds the regulator’s current thinking on what specifically must be monitored for a model. It is important to be precise about its status: as of September 2026, Annex 22 remains a consultation draft. It has not been adopted, and there is no implementation date. Its numbered clauses are proposals, not requirements in force. That said, they are the clearest available signal of where European GMP expectations are heading, and they are unusually specific.⁵

Section 10.3 of the draft states that the performance of a model as defined by its metrics should be regularly monitored to detect any changes in the computerized system, and gives the example of deterioration or change of a lighting condition. Section 10.4 states that it should be regularly monitored whether the input data are still within the model sample space and intended use, and that metrics should be defined for monitoring any drift in the input data. Section 10.5 addresses human review, requiring that records be kept where a model feeds a decision made by a human operator and the testing effort was reduced accordingly.⁵

Notice what the draft does not do. It does not name a metric, set a frequency, prescribe a limit, or say what happens when monitoring shows a problem. The operative words are regularly monitored and metrics should be defined. That is deliberate, and it puts the design work back on the regulated user. Stage 3 practice is the most credible place to get that design, because it is a method a regulator already recognizes for exactly this class of question.

Five Different Things People Call Drift

The single largest source of confusion in model monitoring programs is that the word drift is used for at least five distinct phenomena with different causes, different detection methods, and different correct responses. A monitoring plan that does not separate them will either miss real degradation or generate alerts nobody can act on. The machine learning literature has settled terminology for most of these, and it is worth adopting rather than inventing local names.^{6 7}

Covariate shift is the easiest to see and the least conclusive

Input drift is detectable without any labels at all, which is why almost every commercial monitoring tool leads with it. Compare the distribution of each input feature in the current window against a reference window fixed at qualification, and flag the features whose distributions have moved. This maps directly onto Annex 22 section 10.4, which asks whether input data are still within the model sample space and intended use.⁵

The limitation is that a moved input distribution does not mean the model got worse. A model can be entirely robust to a large shift in a feature it barely uses, and can fail badly on a small shift in a feature it depends on. Treat input drift as a trigger for investigation, not as a performance finding. The most useful refinement is to weight input drift by feature importance, so that a shift in a feature the model actually relies on raises a higher-priority signal than a shift in a feature it ignores.

Prior probability shift is often mistaken for model failure

If the mix of outcomes in the population changes, a model’s observed precision and its predicted class balance both change even when the model itself is unchanged and still correct. A defect classifier will report more rejects when the line genuinely produces more defects. Reading that as model degradation and retraining on it makes the model worse, not better. The published method for separating the two estimates the target distribution using the model’s own confusion matrix, and it works even when the predictor is biased or poorly calibrated, provided the confusion matrix is invertible.⁸ In practice this means your monitoring plan needs a periodic, independently labeled sample from which the confusion matrix can be re-estimated. Without one, you cannot tell a shift in the world from a shift in the model.

Concept drift is the one that matters and the hardest to see

Concept drift is a change in the relationship between the inputs and the outcome. The same input now means something different. This is the failure that causes harm, and it is the only one of the five that cannot in principle be detected from input data alone when the input distribution has not moved. Surveys of drift monitoring in evolving environments make this point plainly: unsupervised methods work on the data distribution directly, and where the distribution is unchanged there is nothing for them to find.⁷ Detecting concept drift requires outcomes, which brings you back to the label problem addressed later in this article.

Pipeline breakage deserves its own controls

The systems engineering literature on production machine learning has documented the failure modes that come not from the model but from everything around it: undeclared consumers of a model’s output, data dependencies nobody owns, configuration drift, and feedback loops where the model’s own predictions change the data it is later trained on.¹⁰ In a GMP setting these map onto familiar controls. An undeclared consumer is an unassessed change impact. A data dependency nobody owns is a gap in the system inventory. And a feedback loop where operators stop inspecting the vials the model marks as good, and therefore stop generating the labels that would reveal the model missing defects, is a validation problem with a patient safety consequence.

What to Monitor for Classification, Regression, and Generative Models

The draft Annex 22 gives useful direction on metric selection. Section 4.1 states that suitable, case dependent test metrics should be defined to measure model performance according to the intended use, and offers as examples for a classification model a confusion matrix, sensitivity, specificity, accuracy, precision, and F1 score. Section 4.2 requires acceptance criteria for those metrics, approved before testing starts, and permits different criteria for different subgroups. Section 4.3 sets a floor: acceptance criteria should be at least as high as the performance of the process the model replaces, which implies you know what that performance was.⁵

The monitoring plan should use the same metrics as the qualification test, computed the same way. This sounds obvious and is frequently violated. If the model was qualified on sensitivity and specificity per defect subgroup, and monitoring reports overall accuracy on a mixed population, the two numbers are not comparable and the monitoring cannot tell you whether qualified performance is being maintained.

Classification models

Regression models

Regression models used to predict a continuous attribute, a yield forecast or a predicted assay result for example, need a different metric set. Track the mean error, not just the absolute error, because a growing bias in one direction is a different failure from growing noise and calls for a different investigation. Track residuals against time and against the main input variables, because a residual pattern that was flat at qualification and now slopes is direct evidence that the relationship has changed. Where the model produces a prediction interval, track empirical coverage: if the ninety percent interval now contains the true value seventy percent of the time, the model’s uncertainty estimate has failed even if the point predictions still look acceptable.

Generative models, and an important boundary

Here the draft Annex 22 draws a line that many organizations have not absorbed. The draft applies to static, deterministic models. It states that models with a probabilistic output, which given identical inputs might not provide identical outputs, are not covered and should not be used in critical GMP applications, and it says the same explicitly of generative AI and large language models. Where such models are used in non-critical GMP applications with no direct impact on patient safety, product quality, or data integrity, the draft expects a qualified person in the loop to be responsible for confirming that outputs are suitable for the intended use.⁵

That boundary is a draft position rather than settled law, and it is being actively debated. But it shapes what monitoring for a generative system is actually for. You are not monitoring to demonstrate that a language model remains in a validated state for a critical decision, because under the current draft it should not be making one. You are monitoring the human-in-the-loop control that makes the use acceptable, and drift in that control is a human factors problem as much as a model one.

Practical signals for a generative system in a non-critical GMP use: the human acceptance rate for generated content, the average extent of human edits, the rate at which the reviewer rejects output outright, the share of outputs where the system could not ground its answer in the retrieved source, and the distribution of request types compared with what was assessed. Automated evaluation of output quality against a fixed reference set of prompts, re-run on a schedule and after every version change, gives a comparable number over time. The NIST generative AI profile is a useful checklist for the risk categories a monitoring plan should cover, including confabulation and information integrity.¹¹

Predefined Metrics and Control Limits, Not Dashboard Watching

The dominant pattern in industry today is a monitoring dashboard with a dozen time series charts, reviewed by whoever remembers to open it, with no defined threshold on any of them. This is not monitoring. It is the analytics equivalent of looking at batch data without a specification, and it fails the same way every time. For the first few months everyone looks, then nobody looks, and when something is finally noticed the question of when it started cannot be answered, because no one ever wrote down what normal was.

A CPV plan does not work this way, and neither should a model monitoring plan. Every monitored parameter has a defined limit, a defined action if the limit is exceeded, and a defined owner. Model monitoring should adopt the same three-tier structure that CPV plans use.

How to derive a limit that means something

Four inputs go into a defensible limit. First, the qualification performance itself, including its uncertainty. A sensitivity of 0.97 estimated on forty positive cases has a confidence interval wide enough to swallow most limits you might set, and Annex 22 section 5.2 already requires the test dataset and each of its subgroups to be sufficient in size to calculate the metrics with adequate statistical confidence.⁵ Second, the performance of the process the model replaced, which sets the floor. Third, the consequence of a miss, which determines how much margin you want between alert and failure. Fourth, the volume you will actually observe per monitoring period, which determines whether the metric can be estimated at all at that frequency.

That last point is where most plans break. If a model processes eight hundred units a month and the defect rate is two percent, a monthly sensitivity estimate rests on sixteen positive cases. A limit on that number will be crossed by chance regularly. The fix is not a looser limit. It is a longer aggregation window for the label-dependent metric, combined with a shorter window for the label-free metrics that support it. Report sensitivity quarterly on a pooled sample, and report predicted class proportion, confidence distribution, and input drift weekly.

Where SPC Helps and Where Its Assumptions Break

Statistical process control is the natural toolkit here, and pharmaceutical quality organizations already have the skills. Shewhart charts for individual values, EWMA and CUSUM charts for detecting small sustained shifts, and the standard run rules are all directly applicable to a model performance metric plotted over time. The NIST and SEMATECH engineering statistics handbook remains a clear, freely available reference for chart selection and for the distinction between the initial phase in which limits are established and the ongoing phase in which they are applied.^{12 13}

Charts built for the small sustained shift are usually the right choice for model monitoring. Drift in a model is rarely a step change. It is a slow slide, and a Shewhart chart with three sigma limits is deliberately insensitive to slow slides. EWMA and CUSUM charts are designed for exactly that case and should be the default for any metric where gradual degradation is the expected failure mode.

The assumptions, and how they break on model outputs

None of these break SPC. They break naive SPC. The FDA guidance anticipates the underlying issue when it recommends that a statistician or a person trained in statistical process control develop the data collection plan and the statistical methods.¹ A model monitoring plan drafted without that input tends to produce charts that are at once too noisy to act on and too blunt to catch the failure that matters. Published work on continued process verification has been arguing for years that univariate charts alone are not enough for a process with many correlated variables, and the same argument applies with more force to a model whose inputs are correlated by construction.¹⁷

A Worked Monitoring Plan for One Model

The following is a monitoring plan for a single model, written the way a CPV plan is written. The model is a visual inspection classifier on a lyophilized vial line, classifying each vial as accept or reject with a defect type. It is illustrative and generic. The point is the shape of the document, not the numbers, which have to come from your own qualification data.

Intended use and monitoring scope

The model classifies images of filled and stoppered vials as accept or reject, with a defect type where reject. Output feeds an automated reject arm, with all rejects and a random sample of accepts routed to manual inspection. Subgroups, defined per Annex 22 section 3.2, are the four product presentations on the line and five defect categories. The monitoring plan covers model performance, the input sample space, the manual inspection control, and the supporting data pipeline.

Performance monitoring table

Input sample space monitoring table

The three supporting documents

A monitoring plan of this kind is not self-sufficient. It needs a signal log recording every alert, its investigation, and its disposition. It needs a limits register recording the current value of every limit, its statistical basis, and the change control reference for every revision. And it needs the periodic monitoring report itself, which is the document a periodic review or an inspector will actually read. All three are GMP records with the same retention as the rest of the validation package, and Annex 22 section 7.4 already sets that expectation for the testing documentation this plan extends.⁵

Cadence, Reviewers, and the Route into Deviation and CAPA

Cadence is where most plans are either unrealistic or meaningless. Continuous monitoring of everything is neither achievable nor useful. The workable structure has three layers running at different speeds, with different people and different consequences.

Three layers

Automated checks, per run or daily. Schema validation, range checks, pipeline health, predicted class proportions, confidence distribution, abstention rate. These run without a person and either pass or raise. Their job is to catch breakage fast and to keep a continuous record. No judgment is applied at this layer.

Monthly technical review. The model owner and the process subject matter expert review the charts, the signal log, and any open investigations. This is where run rules and slow trends are read, where a signal is either closed as understood or escalated, and where someone records the observation that the model is fine but the reviewer behavior has changed. FDA’s process validation guidance recommends something structurally identical for processes: that the quality unit meet periodically with production staff to evaluate data, discuss possible trends or undesirable variation, and coordinate corrections.¹

Quarterly quality review. The quality unit reviews the aggregate picture, the label-dependent performance metrics that need a quarter of data to compute, the effectiveness of any actions taken, and any proposed change to a limit. This is the layer that produces the record feeding periodic review and management review.

Escalation, and the boundary with deviation management

Retraining belongs at the end of this ladder, not in the middle of it. A drift signal is a reason to investigate. The investigation may conclude that retraining is the right corrective action, and if it does, that retraining is a change requiring its own assessment, its own testing against independent data, and its own approval under change control. Annex 22 section 10.1 puts the model, the system, and the whole process under change control before deployment, and requires that any change be evaluated to determine whether retesting is needed, with any decision not to retest fully justified.⁵ Treating retraining as an automatic response to a drift alert skips the investigation entirely and, where the signal was caused by prior probability shift or a broken pipeline, retrains the model on the wrong problem.

The Hard Problem: When Ground Truth Arrives Late or Never

Everything above assumes you eventually find out whether the model was right. For a meaningful share of pharmaceutical AI use cases you do not, or you do so late enough that the information has limited value. This is the problem that defeats monitoring programs, and it deserves to be planned for explicitly rather than discovered eighteen months in.

Four regimes, four honest positions

That last row is not pessimism, it is a result. Surveys of drift monitoring in evolving environments are explicit that unsupervised methods work on the data distribution, and where the input distribution has not changed there is no distributional signal to find, whatever has happened to the relationship between input and outcome.⁷ If a use case has no path to labels and no acceptable proxy, that is a design finding to raise before deployment, not a monitoring problem to solve after.

The verification bias trap

What to do while you wait

The practical answer under label delay is a layered set of signals, ordered by how quickly they arrive and how directly they bear on performance.

• Input sample space checks, immediately. Available on every prediction, no labels needed, and directly required by draft Annex 22 section 10.4. This is the fastest signal you will ever have and the one that catches the largest share of real problems.
• Confidence and abstention behavior, daily. A model becoming less confident on unchanged inputs is telling you something before any label arrives.
• Human disagreement, continuously wherever a reviewer exists. This is the cheapest approximation of ground truth in most workflows, and it is available now rather than in six months. Its weakness is that the reviewer is not infallible and their behavior drifts too, which is why the reviewer needs monitoring in their own right.
• Downstream outcome proxies, weekly or monthly. A signal correlated with the true outcome and available sooner: a downstream test result, a rework rate, a complaint category. Document the correlation you are relying on, and confirm it when real labels do arrive.
• Planned label acquisition, on a defined schedule. A pre-specified sample sent for confirmation regardless of what the model said, with the sampling plan documented like any other, including the size needed for the metric you intend to estimate.
• Retrospective back-testing when labels land. When the delayed labels arrive, run the full performance calculation against the period they belong to, and record whether the leading indicators you were relying on actually moved first. Over a few cycles this tells you which proxies to trust and which to retire.

The important discipline is honesty in the record. A monitoring report under a six month label delay should state plainly that confirmed performance is available through a stated date and that everything after that date rests on leading indicators. An inspector will accept a lag that is disclosed and managed. What causes problems is a report that presents proxy signals in a way that reads as confirmed performance.

Feeding Periodic Review and Management Review

Monitoring output that goes nowhere has no regulatory value. The two destinations that matter are periodic review of the computerized system and management review under the pharmaceutical quality system, and they need different things.

Periodic review

Periodic review asks whether the system remains in a validated state and fit for its intended use. For a model, the monitoring record set is most of the answer. The review should be able to establish, from the record and without new analysis, whether performance remained within acceptance criteria across the period, whether input data remained within the qualified sample space, every signal raised and how each was resolved, every limit that changed and under what change control, every model and system version deployed and what testing supported it, and whether the human-in-the-loop control operated as described.

If the monitoring plan produces those six things as a matter of routine, periodic review becomes an assembly exercise. If it does not, periodic review becomes a retrospective investigation, which takes far more effort and tends to surface gaps at the worst possible time.

Management review

Management review under ICH Q10 looks at the health of the quality system, not at individual control charts. The Q8, Q9 and Q10 questions and answers note that relevant elements of the pharmaceutical quality system, including the quality monitoring system, change management, and deviation management, belong together as part of the control strategy.^{3 4} What management needs from model monitoring is aggregate and comparative: how many models are under monitoring and how many of those have current, in-date performance data; how many signals were raised and how many are still open past their due date; how many models breached an acceptance criterion; how many retraining events occurred and what triggered them; and where the label delay is long enough that the organization is operating on proxies.

That last item is the one worth escalating deliberately. A portfolio in which most models cannot be evaluated against ground truth within a reasonable period is carrying a risk that no individual monitoring plan will surface, because each plan looks locally reasonable. It only becomes visible when the portfolio is looked at together, which is precisely what management review is for.

What the GAMP guidance adds

The ISPE GAMP Guide on artificial intelligence, released in 2025, extends GAMP 5 principles to AI-enabled computerized systems and covers the operational phase, including performance monitoring and demonstrating ongoing control of these systems through life.^{15 16} Its practical contribution for most organizations is not new theory but permission. It establishes that monitoring and maintenance of an AI system belongs inside the existing computerized system life cycle rather than alongside it. That framing matters, because the alternative, an AI governance process running parallel to the quality system, produces two sets of records, two escalation paths, and an argument during every inspection about which one governs.

Conclusion

The organizations that struggle with model drift monitoring are usually not short of technical capability. They are short of a decision about where the activity belongs. Treated as a data science practice, drift monitoring produces dashboards, informal review, and no durable record. Treated as Continued Process Verification, it produces predefined limits, named reviewers, a defined escalation into deviation and CAPA, and a record set that periodic review and management review can actually use. The second version is harder to start and far easier to sustain, and the quality organization already knows how to run it. The translation work is mostly a matter of writing the monitoring plan in the language of a CPV plan and routing it through the systems that already exist.

Two things are worth deciding early, because they are difficult to retrofit. The first is the label strategy: how the organization will find out whether the model was right, how often, and drawn from where. A random audit sample that does not depend on the model’s own output is the piece most programs omit, and it is the piece that determines whether the monitoring can detect the failure that matters. The second is the limit basis: what normal looks like, established from real production data during a defined early period, under change control, with the statistical reasoning written down. Get those two right and the rest of the plan follows. Get them wrong and no amount of monitoring technology will compensate.

Sakara Digital works with pharma and biotech organizations building monitoring and governance for AI systems inside an existing quality system rather than beside it. If you are standing up drift monitoring for a deployed model, or trying to work out whether the plan you already have would survive a periodic review, we are happy to have that conversation.

For Further Reading