What does a GAMP 5 lifecycle look like for a continuously-retrained model?

V-model plus continuous-validation overlay. Planning with AI risk assessment, classification, validation plan including CV SOP. URS/FS/DS with data-pipeline and model-behaviour specs. Versioned data and models with traceability. IQ/OQ/PQ including bias/edge-case qualification. Release with CV SOP active. Operation: monitoring, escalation, periodic review, change-managed retraining.

What evidence is required per V-model phase for a model?

Planning: AI risk assessment, data and model lifecycle plans. Spec: data-pipeline traceability, quantitative acceptance criteria, bias/fairness, drift detection. Build: versioned data/model artifacts with hashes, training reproducibility, model card. IQ/OQ/PQ: standard plus model-behaviour, edge-case, bias evidence. Release: validated state, monitoring operational. Operation: continuous evidence file.

How do GAMP 5 controls map to AI-specific risks?

Data drift: monitoring + retraining controls. Hallucination: scope + verification controls (human-gated outputs in regulated roles). Training-data quality: data-governance (lineage, labeller competence, ALCOA+) + qualification evidence. Bias: fairness specification + qualification across intended-use population. Each AI risk extends an existing risk-based control family.

Where does ISPE GAMP AI guidance change classic categorisation?

Keeps categories, adds AI-specific overlay. Cat 3 vendor needs supplier assessment of AI dev practice and intended-use evidence in buyer envelope. Cat 4 configured needs configuration testing including model behaviour in configured state. Cat 5 custom needs full classic lifecycle plus AI lifecycle for data/model/continuous validation. Explicitly addresses CV SOPs classic V-model treated as out of scope.

Validation-Ready AI for GxP Operations in Pharma

Q: How is AI/ML software classified under GAMP 5?

GAMP 5 Second Edition with ISPE AI guidance. Vendor as-shipped behaves like Cat 3 (supplier + intended-use verification). Vendor configured: Cat 4. Bespoke ML: Cat 5. Regardless of category, ML behaviour needs controls classic categories did not specify. Classification produces base category plus AI risk profile; scope is union.

Q: Why is continuous validation needed for AI/ML?

One-shot validation assumes the system behaves as validated. AI/ML breaks this: data drift, concept drift, silent model degradation occur without code changes. Continuous validation captures inputs/outputs/acceptance signals at production cadence; operating procedure defines triggers for investigation, retraining, re-qualification. Operational practice that keeps validation conclusion true.

Introduction

Validation-ready AI for GxP operations is the methodology that turns an AI/ML system the regulator would refuse into one the regulator accepts. The standard GAMP 5 classification (Category 3 standard, Category 4 configured, Category 5 custom-developed) was designed for deterministic software; ML systems that learn from data and shift behaviour over time break the category assumptions, and teams that force every model into Category 5 with full CSV waste validation effort on the wrong approach. The 2026-correct path uses GAMP 5 Second Edition plus the ISPE GAMP AI guidance to assess the AI/ML system’s risk profile, classify according to current guidance, and implement proportional validation with continuous monitoring. See life sciences for the broader GxP-AI methodology this article lives inside.

The naive read is that AI validation is “full CSV with extra documentation.” The expert read is that proportional validation governed by risk and reinforced by continuous monitoring is the methodology that scales — and that the validation-ready design choices made before the AI system is built are the ones that decide whether the validation is tractable.

What this means in practice

GAMP 5 classification for AI/ML is risk-driven, not always Category 5; proportional validation follows the classification.
Continuous validation replaces one-shot validation for models that evolve; the lifecycle is ongoing.
AI-specific risks (data drift, hallucination, training-data quality) need controls the classic V-model does not include.
ISPE GAMP AI guidance reframes parts of the classic categorisation; using the current guidance is mandatory.

How is AI/ML software classified under GAMP 5 — Category 3, 4, 5, or something new?

The 2026 answer applies the GAMP 5 Second Edition with ISPE AI guidance. AI/ML systems do not automatically fall in any single category. A vendor-supplied AI tool used as-shipped with no model customisation behaves like Category 3 — the validation focus is supplier assessment, intended-use verification, and configuration controls. A vendor AI platform configured for the buyer’s process (data integration, workflow configuration, threshold tuning) behaves like Category 4 — the validation adds configuration testing on top of the Category 3 baseline. A bespoke AI/ML system built or substantially customised for the buyer (custom training, custom architecture, custom data pipeline) behaves like Category 5 — the validation adds full lifecycle controls including the data and model development.

The ISPE GAMP AI guidance adds the dimension that classic categorisation misses: regardless of category, the system’s ML behaviour requires controls the classic categories did not specify. The honest classification produces both a base category (3/4/5) and an AI risk profile (drift exposure, autonomy level, decision impact); the validation scope is the union of both.

What does a GAMP 5 validation lifecycle look like for a continuously-retrained AI model?

The lifecycle has the classic V-model phases plus continuous-validation overlay. Planning and concept: intended use, risk assessment per ISPE AI guidance, classification with AI risk profile, validation plan including continuous-validation operating procedures. Specification: URS, FS, DS with explicit data-pipeline specification and model behaviour specification (acceptance criteria for performance, drift detection thresholds, retraining triggers). Configuration and build: model development with versioned training data, versioned model artifacts, traceability from data to model to deployment.

Qualification: IQ on the infrastructure, OQ on the model behaviour against the specification (including bias, fairness, edge cases relevant to the intended use), PQ on the integrated system in the operational environment with operator workflow. Release for use with the continuous-validation operating procedure activated. Operation: continuous monitoring of inputs, outputs, drift signals, and outcome metrics with documented escalation; periodic review against acceptance criteria; retraining controlled through change management with re-qualification scoped to the change. Retirement: documented decommissioning, archive of the validation evidence supporting the operational period.

Why is continuous validation needed for AI/ML, and how does it differ from one-shot validation?

One-shot validation establishes that the system meets its specification at release. For deterministic software where behaviour does not change once the code is frozen, one-shot validation plus change-controlled re-validation on changes is sufficient — the assumption “the system behaves today as it was validated to behave at release” holds. For AI/ML systems, the assumption fails along multiple axes: data drift changes the input distribution the model was trained on, concept drift changes the underlying relationship the model learned, and silent model degradation occurs without code changes.

Continuous validation adds the operating discipline that surfaces these changes against the specification. Monitoring captures inputs, outputs, and the acceptance-criteria signals at production cadence; the operating procedure defines what triggers investigation, what triggers retraining, and what triggers re-qualification; the evidence file maintained continuously supports the periodic review against the validation plan. Continuous validation is not “more documentation” — it is the operational practice that lets the validation conclusion remain true over time. Skipping it is the design choice that turns a validated system into an unvalidated one within months of release.

What evidence is required at each GAMP 5 V-model phase when the system under test is a model?

Per phase, the model-specific evidence additions. Planning: AI risk assessment with ISPE GAMP AI alignment, data-strategy plan covering training-data lineage and retention, model-lifecycle plan covering training, monitoring, retraining, retirement. Specification: data-pipeline specification with traceability from raw source to training set, model behaviour specification with quantitative acceptance criteria (precision, recall, calibration as relevant), bias-and-fairness specification per the intended use, drift-detection specification with thresholds and operating limits.

Build: versioned training data and model artifacts with hashes recorded, training-pipeline reproducibility evidence (re-run produces equivalent model within tolerance), model-card documentation per release. IQ/OQ/PQ: standard qualification evidence plus model-behaviour qualification against the acceptance criteria, edge-case qualification per the AI risk profile, bias evidence per the fairness specification. Release: model and data version in the validated state, monitoring infrastructure operational, operating procedure for continuous validation in force. Operation: continuous evidence file capturing monitoring outputs, deviation investigations, retraining-and-requalification records, periodic review records.

How do GAMP 5’s risk-based controls map onto AI-specific risks (data drift, hallucination, training-data quality)?

GAMP 5’s risk-based approach scales control intensity to risk; the mapping to AI-specific risks. Data drift maps to monitoring controls (input-distribution surveillance, drift-threshold operating limits, investigation-and-CAPA on drift exceedances) and retraining controls (change-managed model refresh, re-qualification scoped to the change). Hallucination (relevant for generative AI in GxP contexts) maps to scope controls (the AI system is not used in roles where unverified outputs could affect product quality or patient safety without human verification) and verification controls (outputs in scope are gated by human review with documented acceptance criteria).

Training-data quality maps to data-governance controls (training-data lineage, labeller competence, label-quality audit, training-data integrity per ALCOA+), and to qualification controls (the training-data quality is in scope of the validation evidence, not assumed). Bias risk maps to fairness specification (intended-use-specific fairness criteria) and qualification evidence (bias measurement against the criteria across the intended-use population). The pattern: each AI-specific risk has an existing GAMP risk-based control family that extends to cover it; the work is in identifying the relevant risks per intended use and applying the proportional controls.

Where does the ISPE GAMP AI guidance change the classic GAMP 5 categorisation for ML software?

The ISPE GAMP AI guidance keeps the classic categories but adds the AI-specific overlay that the classic guidance did not include. The classic categorisation answered “what kind of software is this and what controls fit” — the AI guidance answers “what AI-specific risks does this system carry and what additional controls are needed regardless of category.” The change in practice: a vendor AI tool used as-shipped (classic Category 3) still needs supplier assessment of the AI development practice, not just the software development practice, and still needs intended-use evidence that the AI behaves as the supplier represents within the buyer’s operating envelope.

A configured AI platform (classic Category 4) needs configuration testing that includes the model behaviour in the configured state, not just functional configuration. A custom AI system (classic Category 5) needs the full lifecycle of the classic category plus the AI-specific lifecycle for data, model, and continuous validation. The guidance also explicitly addresses the operating-procedure requirements for continuous validation that the classic V-model treated as out of scope. Teams operating without the current ISPE guidance reach incorrect conclusions on what their validation evidence must include; teams operating with it produce defensible validation packages that align with the direction regulators are moving.

How TechnoLynx Can Help

TechnoLynx works with pharma manufacturers on validation-ready AI from intended-use scoping and AI risk assessment through GAMP 5 classification with ISPE AI alignment, lifecycle planning, continuous-validation operating procedure design, and the evidence-file discipline that supports periodic review. If your team is scoping an AI/ML system for GxP operations and needs validation-ready design from the start, contact us.

Image credits: Freepik