Risk-based validation is the current regulatory expectation GAMP 5 — the ISPE’s Good Automated Manufacturing Practice guide — is the framework regulators expect pharmaceutical companies to use when validating computerised systems. First published in 2008 and substantially revised as the Second Edition in 2022, it sets out a structured way to decide how much validation effort is appropriate for a given system, based on the risk that system poses to product quality and patient safety. The core principle is proportionality. Higher-risk systems get more thorough validation; lower-risk systems get proportionate but lighter activities. This is not a relaxation of regulatory expectations — we hear that misreading often, and it is worth correcting. It is a more disciplined allocation of validation resources, focusing engineering effort where it actually affects product quality and patient outcomes. The GAMP 5 software categories Category Description Validation approach Examples 1 Infrastructure software Qualification, no detailed validation Operating systems, databases, network infrastructure 3 Non-configured products Verification of intended use Off-the-shelf instruments, standard firmware 4 Configured products Configuration verification and testing ERP, LIMS, MES configured for specific processes 5 Custom applications Full lifecycle validation Bespoke manufacturing control systems, custom analytics The original GAMP 5 assumed a clean boundary between configured (Category 4) and custom (Category 5) software. Machine learning systems break that boundary. An ML model trained on facility-specific data using a commercial framework — PyTorch, TensorFlow, or a managed service on top of either — is neither a configured product nor a fully custom application in the traditional sense. The training data, the framework, the model architecture, and the deployment pipeline each carry different risk profiles. The Second Edition addresses this by elevating critical thinking to a validation principle, directing teams to assess what the system actually does rather than forcing it into a predetermined category. What the Second Edition changes The 2022 revision makes three shifts from the original framework that matter in practice. Critical thinking over prescriptive testing. Instead of mandating specific test types for each software category, the Second Edition asks validation professionals to assess risk and apply proportionate assurance activities. This aligns directly with the FDA’s Computer Software Assurance (CSA) guidance, which moved the agency’s posture away from documenting every test and toward documenting the reasoning behind the test plan. Agile and iterative development. The original GAMP 5 assumed waterfall lifecycles, with discrete IQ/OQ/PQ phases following a frozen specification. The Second Edition acknowledges iterative development and explains how to maintain validation compliance when requirements, design, and code co-evolve across sprints — including how to handle the validation deliverables themselves as living documents under version control. AI/ML considerations. The Second Edition includes guidance on validating non-deterministic systems. It recognises that AI systems require continuous validation — ongoing performance monitoring — rather than one-time qualification, and that model changes constitute system changes that fall under change control. The practical implications for classifying and validating AI/ML software under GAMP 5 extend to how organisations handle model retraining, data pipeline changes, and performance drift, each of which may trigger re-validation activities. How does risk-based validation reduce effort without reducing compliance? The risk-based approach reduces validation effort by focusing testing on high-risk functionality and accepting lighter-touch verification for low-risk functionality. The total number of tests goes down, but coverage of risk-critical functions actually goes up compared to flat, one-size-fits-all validation. The risk assessment evaluates each system function on two dimensions: the impact of failure — what happens if this function produces incorrect results — and the probability of failure given the technology and implementation. Functions with high impact and high probability receive the most rigorous validation. Functions with low impact and low probability receive minimal validation, often just documented verification that the function exists and operates. For a typical LIMS implementation, this approach is an observed pattern across our engagements: the total test count drops by roughly 40–60% compared with validating every function at the same level of rigour. The figure is not a benchmarked rate — it is what we have seen when teams retire redundant tests against low-risk functions: report formatting, user interface preferences, notification routing. These affect user convenience but not product quality or data integrity, so minimal testing is justified. The critical success factor is the risk assessment itself. A risk assessment that misclassifies a high-risk function as low-risk creates a validation gap that auditors will identify. We use cross-functional risk assessment teams — IT, Quality, Operations, and subject matter experts — so that no risk perspective is missing. The resulting document becomes a key validation deliverable that regulators review during inspections to confirm that validation scope was determined appropriately. Applying GAMP 5 to AI systems: a decision checklist Does the AI system affect GxP data or product quality? If yes, it falls within GAMP 5 scope. Determine the appropriate category from system architecture and risk profile. Is the system deterministic or non-deterministic? Non-deterministic systems — ML models, LLM-based components, anything whose output is a function of trained weights — require continuous validation. One-time IQ/OQ/PQ is insufficient on its own. What is the system’s risk classification? High-risk systems (batch disposition, release decisions, quality calls) require thorough validation. Advisory systems (suggestions, reports, ranked recommendations reviewed by a human) require proportionate effort. How will model updates be managed? Every model change — retraining, architecture change, data pipeline modification — requires change control with a documented impact assessment. What performance metrics define “validated state”? Define acceptance criteria (accuracy, precision, recall, drift thresholds) before deployment, not after. These thresholds, recorded against a specific model version and dataset, are the operational benchmark against which continuous monitoring measures the live system. GAMP 5’s risk-based approach is not optional. It is the framework regulators expect pharmaceutical companies to apply. The alternative — uniform full validation regardless of risk — wastes resources and, more importantly, obscures the systems that actually need rigorous oversight. FAQ
