Continuous Monitoring for AI in GxP: Why One-and-Done Validation Fails

Why point-in-time validation fails for AI

A traditional IQ/OQ/PQ cycle tests a defined set of inputs and expects reproducible outputs. For a LIMS configuration, this works: a sample type defined as "Potency Assay" will always route to the potency workflow. For an AI model that classifies requirements by risk level, the same input text may produce different risk scores depending on the model's internal state, training data, and version. Testing a fixed set of inputs and documenting the outputs does not demonstrate that the model will perform acceptably on future inputs it has never seen.

The second failure mode is model drift. A model trained on requirements from one system type (say, LIMS) may perform poorly when applied to requirements from a different system type (say, MES) — even if those requirements are within its designed scope. Over time, as the input distribution shifts, model performance degrades in ways that a point-in-time test cannot predict. The validation must account for this explicitly.

The continuous validation framework

Continuous AI validation adds four layers to the traditional GAMP 5 lifecycle:

• Baseline establishment. During initial validation (PQ), establish quantitative performance baselines: accuracy, precision, recall, F1 score, or domain-specific metrics. These baselines are the reference against which ongoing performance is measured. Document them in the Validation Summary Report alongside the acceptance criteria.
• Real-time performance monitoring. In production, every AI output is scored against the baseline. This can be automated (comparing AI outputs to human-reviewed ground truth) or semi-automated (sampling AI outputs for periodic expert review). The monitoring system itself is a validated component — it must produce reliable metrics and a tamper-evident record of those metrics.
• Drift detection. Statistical monitoring of input data distributions (data drift) and output distributions (concept drift). When either drifts beyond a defined threshold, the system triggers an alert and initiates the re-qualification workflow. Common techniques: KL divergence, PSI (Population Stability Index), or domain-specific distributional tests.
• Periodic re-qualification. Scheduled reviews — typically quarterly for high-risk use cases, semi-annually for medium-risk — that formally compare current performance to baseline. If performance has degraded beyond acceptance criteria, the re-qualification triggers a change control for model update or retraining.

What monitoring infrastructure looks like

The monitoring infrastructure for a validated AI system includes: a performance dashboard with current vs baseline metrics (visible to the model owner and QA); an alerting system that notifies the model owner when metrics breach thresholds; a log of every AI inference with input hash, output, confidence score, and model version; and a periodic report generator that produces the evidence needed for re-qualification reviews.

This infrastructure must itself be validated. It is a GAMP 5 Category 4 (configured) or Category 5 (custom) system depending on how it is built. GxP Copilot includes built-in AI performance monitoring as part of its Annex 22 assurance layer, removing the need to build and validate a separate monitoring system.

Change control for AI model updates

Every change to an AI model — retraining on new data, architecture modification, hyperparameter tuning, version update — must go through change control. The change control record must include: the reason for the change, a risk assessment of the change's impact on validated outputs, a test plan for regression testing, and documented approval from the model owner and QA. Post-change, the baseline may need to be re-established through a partial or full re-qualification. This is operationally more demanding than traditional software change control because AI changes can have non-obvious downstream effects. A model retrained on slightly different data may produce subtly different risk classifications that affect the entire validation package. Change controls manages this lifecycle in GxP Copilot.

What inspectors ask about AI monitoring

• "Show me the performance metrics for this AI system over the last 12 months." — You need a time-series of performance vs baseline.
• "How do you know the model is still performing as validated?" — You need the monitoring dashboard, alerting rules, and evidence that alerts have been investigated.
• "When was the last re-qualification, and what were the results?" — You need the re-qualification report with current vs baseline comparison.
• "What happens if the model performance drops below acceptable levels?" — You need the fallback SOP: how the system operates in non-AI mode until the model is re-qualified.
• "Has the model been retrained since initial validation?" — You need the change control records for every retraining event, with documented risk assessment and regression test results.

The practical path forward

Start by accepting that AI validation is continuous, budget for it accordingly, and build the monitoring infrastructure alongside the AI system — not after deployment. book a demo to see how GxP Copilot handles continuous AI validation with built-in performance monitoring, drift detection, and Annex 22 assurance.