The reference framework for pharma software validation The GAMP Guide — Good Automated Manufacturing Practice, published by the International Society for Pharmaceutical Engineering (ISPE) — is the industry-standard reference for validating computerised systems in pharmaceutical and regulated life sciences environments. Now in its Second Edition (published 2022), GAMP 5 provides a structured, risk-based approach to determining the appropriate validation activities for any computerised system operating within GxP scope. GAMP is not a regulation. It is a guidance framework that regulatory agencies — including the FDA, EMA, and MHRA — reference and expect companies to follow. An inspector will not cite GAMP 5 as a regulatory requirement, but they will expect validation approaches consistent with its principles. That distinction matters in practice: it means the burden is on the validation team to produce a defensible rationale, not to tick a fixed checklist. For practitioners building or qualifying AI/ML systems, the Second Edition is also the document that finally takes non-deterministic software seriously. The classic V-model assumed a system whose outputs are fully determined by its inputs and code; ML inference under data drift is not that system. GAMP 5 (2022) and the companion ISPE GAMP AI good practice guide are where the reframing happens. What the GAMP guide covers Topic area GAMP 5 guidance Practical use Risk-based approach Scale validation effort to system risk Avoid over-validating low-risk systems and under-validating high-risk ones Software categories Categories 1, 3, 4, 5 for classification Determine appropriate validation activities per system type V-Model lifecycle Requirements → Design → Build → Test → Release Structure validation documentation and traceability Supplier management Assess and leverage supplier quality activities Reduce redundant testing where supplier evidence is adequate Data integrity ALCOA+ principles applied to computerised systems Design audit trails, access controls, and data integrity checks Operational phase Change control, periodic reviews, incident management Maintain validated state throughout system operational life Retirement Decommissioning with data preservation Archive data and documentation per retention requirements The guide is deliberately broad because the population of regulated systems is broad: LIMS, MES, SCADA, ERP modules touching GxP data, electronic batch records, cloud-hosted document management, and increasingly machine-learning components inside any of these. One framework has to give defensible answers across that spread, which is why critical thinking — not a fixed protocol — is the centre of gravity in the Second Edition. Key changes in the Second Edition The 2022 Second Edition substantially updates the original 2008 GAMP 5 to address technology developments that the original framework did not anticipate: Critical thinking: The most significant philosophical change. The original GAMP 5 prescribed specific validation activities per software category. The Second Edition directs validation professionals to apply critical thinking — assessing what validation activities are appropriate based on system risk, complexity, and novelty rather than following prescriptive category-based protocols. AI and machine learning: New guidance on validating non-deterministic systems. Acknowledges that ML models cannot be validated using one-time testing approaches and introduces continuous validation as a concept — ongoing performance monitoring against predetermined acceptance criteria. This is the entry point for treating data drift, training-data lineage, and model retraining as in-scope validation concerns rather than out-of-band maintenance. Agile development: Recognises that pharmaceutical software is increasingly developed using iterative and agile methodologies. Provides guidance on maintaining validation compliance while using sprints, continuous integration, and incremental delivery. Cloud and SaaS: Addresses the validation implications of systems hosted by third-party cloud providers. Covers shared responsibility models, data residency, and supplier qualification for cloud infrastructure. The decision between traditional validation approaches and these updated methods is a risk-based choice that CSA and GAMP 5 now align on. How do you apply GAMP in practice? The guide is structured for reference, not sequential reading. A validation team typically uses it as follows: System assessment: Classify the system using GAMP software categories. Determine GxP relevance and risk level. Validation strategy: Define the validation approach — traditional V-model, agile, or hybrid — based on system category, risk, and development methodology. Activity selection: Choose specific validation activities (documentation, testing, reviews) proportionate to risk. High-risk systems get thorough testing. Low-risk systems get targeted verification. Supplier engagement: Assess supplier quality capabilities. Leverage supplier testing evidence where adequate. Supplement with user testing where supplier evidence is insufficient. Lifecycle management: Establish change control, periodic review, and incident management processes that maintain the validated state during the operational phase. The guide’s value is not in following it prescriptively — the Second Edition explicitly discourages this. Its value is in providing a defensible framework that regulatory inspectors recognise and accept. When the framework is applied with judgement, the documentation set ends up shorter, the testing more targeted, and the inspection conversations more straightforward. How do you apply GAMP to modern agile development practices? GAMP’s validation lifecycle was designed around waterfall development: requirements first, then design, then build, then test, then deploy. Agile development iterates through these phases repeatedly. Reconciling GAMP with agile requires adapting the documentation approach without compromising the regulatory intent. The adaptation: maintain living requirements and design documents that evolve with each sprint, but snapshot them at release points for regulatory traceability. Each release candidate is validated against the requirements document as it stands at that point. The traceability matrix reflects the current state of requirements-to-tests at each release. Sprint-level testing replaces the monolithic OQ/PQ execution. Each sprint produces tested functionality with documented evidence. The release validation aggregates sprint test results and supplements them with integration and regression testing. The validation report for each release references the sprint test evidence rather than re-executing all tests. This approach we use in our engagements maintains full traceability — every requirement has a linked test with documented evidence — while supporting iterative development. The regulatory requirement is not waterfall development. It is documented evidence that the system meets its requirements. Agile can produce this evidence as effectively as waterfall, provided the documentation discipline is maintained. The key enabler in our experience is automated testing. Unit tests and integration tests that execute automatically with every code change — typically wired through a CI pipeline using something like GitLab CI, Jenkins, or GitHub Actions — provide continuous verification evidence with a timestamped audit trail. Containerised test environments (Docker, sometimes orchestrated with Kubernetes for larger suites) give you reproducible execution that an inspector can re-run. Manual validation activities (UAT, business process testing) are then reserved for functionality that genuinely cannot be automatically tested, which is a much smaller surface than most teams initially assume. How does GAMP 5 handle AI/ML systems? The Second Edition acknowledges what the 2008 original could not: an ML model is not a deterministic piece of software with a static specification. Its behaviour depends on the training data, the retraining cadence, and the input distribution it encounters in production. A model can pass IQ/OQ/PQ on day one and then quietly degrade as the patient population, instrument calibration, or upstream data pipeline shifts. GAMP 5 (2022), reinforced by the ISPE GAMP AI good practice guide, makes three concrete moves. First, classification is reframed: a pure ML component is rarely a clean Category 4 (configured) or Category 5 (custom) — it is often a hybrid where the platform is configured but the model itself is custom and data-derived. Second, validation extends into the operational phase as continuous validation, with predefined performance thresholds, monitored metrics, and triggered re-qualification when thresholds are breached. Third, the validation evidence set explicitly includes data lineage, training-set composition, and model-card-style documentation alongside the traditional URS-FS-DS-test traceability. For practical classification work on a specific AI/ML system — including the question of how Category 4 vs Category 5 plays out when a model is retrained on customer data — the GAMP software categories breakdown is the right next step. For the broader GxP scope question of which AI components are even in regulatory scope, our validation-ready AI for GxP operations discussion is the better entry point. FAQ How is AI/ML software classified under GAMP 5 — Category 3, 4, 5, or something new? The Second Edition does not introduce a new category; it asks practitioners to apply critical thinking to the existing four. In practice an ML system is usually decomposed: the runtime platform and orchestration layer may be Category 4 (configured product), while the trained model and its retraining pipeline behave like Category 5 (custom-developed) because their behaviour is determined by your data. Classification drives validation scope, not the reverse. What does a GAMP 5 validation lifecycle look like for a continuously-retrained AI model? The lifecycle keeps the V-model structure for the platform and adds a continuous validation loop around the model. Each retraining event is treated as a change under change control, with pre-defined acceptance criteria, an offline evaluation against a frozen validation set, and a production canary or shadow period before full release. The validation evidence is appended over time rather than re-executed monolithically. Why is continuous validation needed for AI/ML, and how does it differ from one-shot validation? One-shot validation assumes the system’s behaviour is fixed at release. An ML model’s behaviour drifts with the input distribution and degrades silently. Continuous validation defines the performance thresholds, the monitoring cadence, and the re-qualification triggers up front, so that drift is detected and addressed inside the validated state rather than discovered during an audit. What evidence is required at each GAMP 5 V-model phase when the system under test is a model? Requirements and functional specification cover intended use, performance acceptance criteria, and the operating envelope (input ranges, populations, edge cases). Design documentation covers the model architecture, training data provenance, and retraining policy. Build and test evidence covers offline evaluation, fairness/bias checks where applicable, and reproducibility of the training run. Release evidence covers the deployment configuration and the monitoring plan that will sustain the validated state. How do GAMP 5’s risk-based controls map onto AI-specific risks (data drift, hallucination, training-data quality)? Each AI-specific risk becomes a control objective with monitored evidence. Data drift maps to input-distribution monitoring and re-qualification triggers. Hallucination in generative components maps to grounding constraints, output validation, and human-in-the-loop gates for high-impact decisions. Training-data quality maps to data lineage, labelling QA, and documented inclusion/exclusion criteria for the training set. Where does the ISPE GAMP AI guidance change the classic GAMP 5 categorisation for ML software? The ISPE GAMP AI good practice guide does not overturn the four categories; it sharpens how they are applied to ML. It treats the model and its data as first-class validation artefacts, introduces continuous validation as the default operational mode, and gives explicit guidance on supplier qualification for third-party AI services where the buyer cannot fully inspect the training pipeline.
