For thirty years, the way regulated life-sciences organizations decided how much to validate a piece of software was a single question with a clean answer: which GAMP category is it? A non-configured product off the shelf got light validation; a configured product got more; bespoke custom code got the most. The category determined the rigor, the rigor determined the cost, and the whole apparatus of computerized-system validation rested on the assumption that software behaves the same way every time you run it. Then the LLM-based tool arrived in the regulated workflow, and it broke the assumption the entire framework stands on, because the same prompt produces a different output on different runs, the vendor pushes model updates that change behavior without changing a line of your configuration, and the tool's defining capability, generating plausible language, is the same mechanism that fabricates a TLF cross-reference. A Chief Quality Officer who asks you, the function strategist, "what GAMP category is our AI writing tool, and how do we validate it," is asking a question whose honest answer is that the tool strains every category, and that the strain is not a reason to avoid validation but the reason to design it deliberately. This lesson maps the GAMP 5 categories, places LLM-based tools against them, explains exactly where they strain, and shows why the GAMP 5 Second Edition AI-specific appendix exists.

What the GAMP 5 Categories Actually Are

GAMP 5, the Good Automated Manufacturing Practice guide now in its Second Edition, is the framework that the regulated life-sciences industry uses to scale validation effort to software risk and complexity, and its software categorization is the load-bearing idea. The categories are a deliberately small set. Category 1 is infrastructure software, the operating systems and database engines and middleware that other applications run on, validated indirectly through the applications they support. Category 3 is non-configured products, commercial off-the-shelf software used as supplied without configuration of the business process, where you validate that it is installed correctly and works for its intended use but you do not validate the vendor's internal code. Category 4 is configured products, commercial software configured to your specific business process, where the configuration itself is the thing that carries risk and must be validated, because two companies running the same configured product have effectively different systems. Category 5 is custom or bespoke software, written for you, where there is no vendor validation to lean on and the full lifecycle of specification, design, build, and test must be evidenced.

The crucial property of this scheme, the one that makes it work and the one the LLM breaks, is that category maps to determinism and to where the risk lives. A Category 3 tool is low-validation because its behavior is fixed and vendor-tested; you are trusting a stable, deterministic artifact. A Category 5 tool is high-validation because you built it and its behavior is whatever you specified, so you must prove the specification was met. The Second Edition modernized the guide around critical thinking and the Computer Software Assurance mindset, shifting effort toward the highest-risk functionality rather than uniform documentation, but it preserved the categorization spine, because scaling rigor to risk requires some way of characterizing the software, and the category has been that characterization. Everything that follows is about what happens when you try to characterize a probabilistic, vendor-updated, language-generating system with a scheme built for deterministic ones.

Where an LLM Tool Tries to Sit, and Why Each Seat Is Uncomfortable

Take a concrete artifact, the Certara-CoAuthor-class regulated narrative engine integrated into your Veeva Vault RIM system of record, and try to seat it in the categories. The instinct of a quality unit under time pressure is to call it Category 3, a non-configured commercial product, because you bought it off the shelf and did not write it. That seat is uncomfortable the moment you look closely, because Category 3's low validation rests on the behavior being fixed and vendor-tested, and an LLM's behavior is neither: it is probabilistic at the output level and mutable at the model level, so the Category 3 assumption that you can validate once and trust the stable artifact does not hold. The next instinct is Category 4, configured product, because you do configure it, the system prompt, the grounding sources, the retrieval setup, the output templates, are real configuration that genuinely carries risk and must be validated. Category 4 captures something true, the configuration is where much of your controllable risk lives, but it understates the part of the risk that is not in your configuration at all.

The part Category 4 misses is the model itself, which behaves more like Category 5 custom software in its risk profile while being entirely outside your control like a Category 3 product, a combination the scheme was never designed to express. You did not write the model, so you cannot evidence its lifecycle the way Category 5 demands, yet its behavior is not fixed and vendor-locked the way Category 3 assumes, because the vendor updates it and the output varies run to run. An LLM tool is therefore simultaneously Category 3 in its provenance, Category 4 in its configuration, and Category 5 in its behavioral risk, and no single category number captures it. This is the precise sense in which LLM-based tools strain the traditional categories: the scheme assumes that provenance, configuration, and behavioral risk move together up the category ladder, and the LLM decouples them. A strategist who forces a single category onto the tool will either over-validate the configuration and ignore the model risk, or under-validate by treating a probabilistic system as a stable Category 3 product, and both errors fail an inspection for opposite reasons.

The Two Properties That Break the Categories: Non-Determinism and Vendor-Driven Change

Two specific properties of LLM-based tools do the breaking, and naming them precisely is what lets you design validation that addresses them rather than pretending they are not there. The first is non-determinism: at any temperature above zero the same prompt over the same sources can produce different outputs, which means the classical validation idea of demonstrating that a fixed input yields a fixed expected output does not directly apply. You cannot write a test script that says "given prompt X, the system shall produce output Y" and expect it to pass every run, because the system is not built to produce Y; it is built to produce a plausible member of a distribution of which Y is one. Validation must therefore shift from output-matching to property-checking: instead of asserting the exact text, you assert that the output satisfies invariants, that every factual claim is grounded in a loaded source, that no cross-reference points to a non-existent target, that no reportable element is omitted, properties that hold across the distribution of outputs rather than pinning a single one.

The second property is vendor-driven change, which attacks the durability of any validated state you achieve. A Category 3 or 4 product changes when the vendor ships a new version, an event you can see, schedule, and re-validate against under change control. An LLM behind a vendor API can change when the vendor updates the underlying model, sometimes without a version bump you would notice, and that update can shift behavior in ways that invalidate your qualification silently. This is why the validation-posture axis from the vendor-evaluation lessons matters so much: a tool whose vendor provides a controlled release cadence, model version pinning, and change notification lets you maintain a validated state, while a tool that silently re-points to a new model makes a validated state impossible to maintain. The combination of non-determinism and vendor-driven change means the validated state of an LLM tool is not a one-time achievement but a continuously monitored condition, which is the conceptual bridge to ongoing performance monitoring and the predetermined-change-control pattern that the next lessons build.

Why the GAMP 5 Second Edition AI-Specific Appendix Exists

The reason GAMP 5 Second Edition added AI and machine-learning specific guidance is precisely the decoupling described above: the industry recognized that the categorization spine, while still useful, was insufficient on its own to characterize the validation burden of AI and ML systems, and that a layer of AI-specific thinking had to sit alongside it. The appendix-level guidance reframes the question from "which category" to a richer set of questions the category alone cannot answer: what is the intended use and the criticality of the AI's output, is the model static or does it continue to learn, how is the training and input data quality governed, how is the model's performance characterized and monitored over time, and what is the human oversight in the decision the AI supports. These questions map directly onto the FDA-EMA Guiding Principles, fitness for purpose, data quality and lifecycle management, model performance monitoring, ongoing lifecycle monitoring, and human-centric design, which is why the AI-specific guidance and the regulatory principles read as two expressions of the same underlying recognition that AI changes what validation has to cover.

The practical effect for the strategist is that the category becomes the starting point of the validation design, not the end of it. You still categorize, because the categorization usefully separates the configured part of the risk, which behaves classically and can be validated classically, from the model part of the risk, which does not. But you layer onto the category the AI-specific dimensions the appendix names: a criticality assessment of the AI's intended use that scales rigor to the consequence of a wrong output, a data-governance assessment of what the model grounds on, a performance-characterization and monitoring plan that treats the validated state as continuous, and a defined human-oversight point that keeps a named person accountable for the output. A regulated narrative engine and a central-monitoring signal layer might both be Category 4 in their configuration, but the AI-specific overlay produces very different validation plans, because the consequence of a wrong narrative claim and a wrong monitoring signal differ, and the appendix exists precisely to make the framework express that difference.

Static Versus Learning Models: The Dividing Line That Matters Most

Within the AI-specific overlay, the single most consequential distinction the strategist must draw is whether the model is static or continues to learn, because it determines whether the validated state can be held still or must be actively governed as it moves. A static model, one whose weights are fixed and do not update with use, is the more tractable case: its non-determinism is bounded by sampling at inference time, its behavior changes only when the vendor deliberately ships a new model version, and a validated state can be maintained through classical change control as long as the vendor's release cadence is visible and pinned. The validation challenge for a static model is real but familiar in shape, demonstrate fitness for the intended use, control the configuration, monitor performance for drift in input data, and re-validate on version change. A learning model, one that updates its behavior as it ingests new data, is the harder case, because the thing you validated is changing underneath you, and a validation done at a point in time describes a system that no longer exists once the model has learned from a month of new cases.

This dividing line is where the predetermined-change-control-plan pattern, originally an FDA construct for adaptive AI and ML software-as-a-medical-device, becomes the working model for any learning AI in a regulated workflow, even though most regulated writing and monitoring tools are not medical devices. The logic transfers cleanly: if the model will change, you cannot validate it once, so you instead validate the envelope of permitted change, define in advance what kinds of model updates are anticipated, what the acceptance criteria for an updated model are, and what monitoring will detect an update that falls outside the envelope. This converts the impossible task of validating a moving target into the tractable task of governing the boundaries of its motion, which is exactly what the next two lessons operationalize, the validation protocol for a specific tool and the ongoing-monitoring-and-PCCP pattern for keeping it validated. For the strategist designing the validation framework today, the rule is to determine the static-versus-learning status of every AI tool in the stack first, because that status, more than the GAMP category, determines whether you are validating a state or governing a trajectory.

Designing the Validation Stance From the Category and the Overlay

Putting the pieces together, the strategist's validation stance for any LLM-based tool is a composition of the classical category and the AI-specific overlay, and articulating it cleanly is what lets you defend a proportionate, risk-based approach to a Quality Council rather than either over-documenting or under-controlling. Start by separating the tool into its classical and its AI parts: the configuration, the integrations, the workflow logic around the model are classical and get categorized and validated in the familiar way, typically Category 4, with scripted and unscripted testing scaled by the risk of each function under the Computer Software Assurance critical-thinking approach. Then characterize the model part with the AI overlay: assess the criticality of its output, govern its grounding data, determine its static-or-learning status, and design the performance-characterization and monitoring that the non-determinism and vendor-change properties make mandatory rather than optional. The validation plan is the union of these, and it is proportionate when its rigor on each part matches the risk of that part rather than applying a single category's rigor uniformly.

The defensibility of this stance to an inspector rests on its honesty about what the tool is, which is the throughline of the entire Level 4 program. You do not claim the AI tool is a stable Category 3 product that you validated once, because an inspector who understands non-determinism will not believe you and an inspector who does not will be misled, and neither outcome is defensible. You claim, and evidence, that you categorized the configured risk classically, characterized the model risk with the AI-specific dimensions, treated the validated state as a continuously monitored condition for a non-deterministic vendor-updated system, drew the static-versus-learning line and governed the learning case with a predetermined-change-control envelope, and anchored every critical output in a named human who owns the judgment the AI supports. That stance maps the tool to the FDA-EMA principles and the GAMP 5 Second Edition AI guidance simultaneously, it scales rigor to consequence, and it is the validation foundation the rest of this chapter builds into a concrete protocol. The category is where the analysis starts; the honest characterization of a probabilistic, vendor-updated, language-generating system is where the defensible validation actually lives.

Key Takeaways

• The GAMP 5 categories scale validation rigor to software risk by characterizing the software, and the scheme works because category maps to determinism and to where the risk lives. Category 3 is low-validation because behavior is fixed and vendor-tested, Category 4 puts the risk in your configuration, and Category 5 demands full lifecycle evidence for custom code, all resting on the assumption that software behaves the same way every run, which is exactly the assumption an LLM breaks.
• An LLM-based tool strains every category because it decouples provenance, configuration, and behavioral risk that the scheme assumes move together. It is Category 3 in provenance (bought off the shelf), Category 4 in configuration (system prompt, grounding, templates), and Category 5 in behavioral risk (probabilistic and mutable), so forcing a single category either over-validates the configuration while ignoring model risk or under-validates a probabilistic system as a stable product, and both fail inspection for opposite reasons.
• Two properties do the breaking: non-determinism and vendor-driven change. Non-determinism means validation must shift from output-matching to property-checking, asserting invariants like grounded claims and no fabricated cross-references that hold across the distribution rather than pinning one output, and vendor-driven change means the model can shift behavior silently, so the validated state is a continuously monitored condition, not a one-time achievement, making the vendor's release cadence and version pinning decisive.
• The GAMP 5 Second Edition AI-specific appendix exists because the categorization spine alone cannot express the AI validation burden. It reframes the question from which category to intended-use criticality, static-or-learning status, data-quality governance, performance characterization and monitoring, and human oversight, dimensions that map directly onto the FDA-EMA Guiding Principles, so the category becomes the starting point and the AI overlay produces the actual validation plan, with two Category 4 tools yielding very different plans by consequence.
• The static-versus-learning distinction matters more than the GAMP category, because it determines whether you validate a state or govern a trajectory. A static model can hold a validated state through classical change control on visible version changes, while a learning model changes underneath you, so you validate the envelope of permitted change using the predetermined-change-control-plan pattern adapted from adaptive AI/ML software-as-a-medical-device, and the defensible validation stance composes the classical category for the configured risk with the AI overlay for the model risk, anchored in a named human who owns every critical output.