GAMP 5 remains the shared reference for life-science software validation. Here's how teams apply its Second Edition alongside modern AI workflows.
The first edition of GAMP 5 came out in 2008 and, for the better part of fourteen years, was the closest thing life sciences had to a shared language for computerized system validation. Its risk-based, category-driven lifecycle became the default structure behind most validation plans in the industry, built around a linear V-model that assumed software was something you specified, built, tested, and then largely left alone. In July 2022, ISPE published a second edition — 404 pages, a genuine rewrite in places rather than a light refresh — because that assumption had stopped matching how software actually gets delivered.
What actually changed
The core of GAMP 5 didn't move: it's still a risk-based, lifecycle approach organized around software and hardware categories, still aimed at getting assurance effort to match actual risk to patient safety, product quality, and data integrity. What changed is how seriously the second edition takes the fact that software isn't static anymore. It explicitly recognizes non-linear development — iterative, incremental, exploratory approaches — as legitimate ways to build GxP software, not exceptions to justify against the V-model.
The clearest expression of that shift is critical thinking, which gets its own dedicated treatment rather than a passing mention. The second edition is direct about discouraging "rigid tables, predefined templates, and tick-in-the-box methods" in favor of validation professionals actually reasoning about what a given system and risk profile calls for. It draws an explicit line to the FDA's Computer Software Assurance guidance and to ISPE's own data integrity guidance, treating testing as something meant to produce substance — evidence that a feature works as intended — rather than volume, with room for exception-based reporting where a passing result needs a note, not a narrative.
The appendices are where the modernization shows up most concretely. Cloud and SaaS get a section built around supplier oversight — leaning on a vendor's own validation and certifications instead of duplicating their testing locally — which matters enormously for any team whose systems no longer run on servers they control. Blockchain and distributed ledger technology get a dedicated appendix, mostly relevant to audit trail and supply-chain use cases. And, most relevant for where the industry is actually headed, AI and machine learning get an appendix of their own for the first time.
How it treats AI and machine learning
That AI/ML appendix — D11 in most editions of the guide — sets out a risk-based lifecycle framework for AI/ML components: defining a model's boundaries, documenting the classification choices and computational resources behind its development and training, and using performance indicators in roughly the role that technical specifications play for conventional software. It's a genuinely useful starting structure, and it maps reasonably well onto the validation and testing expectations regulators already ask for elsewhere in the document.
It's worth being honest about where it doesn't fully reach, though. Reviews mapping GAMP 5 against the EU AI Act's requirements have pointed out the same gap: human oversight measures and the technical means to help a reviewer interpret a model's output aren't directly covered by Appendix D11, even though it partially gestures at them. That gap is not a flaw specific to GAMP 5 — it's the same territory the draft EU Annex 22 is trying to stake out with more precision, restricting critical use to static, deterministic models and demanding explainability and independent test data as first-class requirements rather than implied good practice. GAMP 5 gives a team the lifecycle scaffolding for validating an AI/ML component. It does not, on its own, tell them how to document that a human is actually positioned to catch a wrong answer before it matters.
What this looks like on a Tuesday
In practice, applying GAMP 5 Second Edition well means resisting the temptation to keep running the old V-model templates with a new cover page. A software category classification should genuinely change what gets built next — a configured COTS system doesn't need the same specification-and-test burden as a bespoke application, and pretending otherwise is exactly the "tick-in-the-box" habit the second edition is trying to retire. Cloud and SaaS components should route through supplier oversight — audits, certifications, contractual assurance — rather than a full local test cycle repeating work the vendor has already done. And anything built on AI or machine learning should start from Appendix D11's lifecycle structure, then get supplemented, deliberately, with the human oversight and explainability evidence that structure doesn't fully provide — because the next round of regulatory expectations is already asking for exactly that, whether or not a given team has gotten there yet.
The second edition works, when it works, for the same reason CSA and the Annex 11 revision are landing at the same moment: all three are pointing validation away from proving effort through paperwork and toward proving that someone actually reasoned about risk and can show their reasoning on demand. GAMP 5 gives that reasoning a shared structure. It still has to happen.
.png)
