A trained model is not a spreadsheet macro, and pretending it is one is how validation packages fall apart during an inspection. GAMP 5 gives you a category system for software, but the categories were written for systems whose behaviour is fully specified before they ship. A machine-learning model’s behaviour is learned from data, revised when the data drifts, and only partially specifiable in advance. That mismatch is the core problem when you try to bring AI/ML into a GxP environment — and it is solvable, provided you classify honestly and validate the parts that GAMP 5 never anticipated. This is the practical method: how to assign a software category to an AI/ML system, what that category actually obliges you to test, and where the GAMP 5 framework stops being sufficient and you have to extend it with model-specific controls. Why the standard GAMP 5 categories don’t map cleanly to ML GAMP 5 sorts software into categories that scale the validation effort to the risk and the degree of configuration. Category 1 covers infrastructure software. Category 3 is non-configured, commercial off-the-shelf software used as supplied. Category 4 is configured software — you set it up, but you don’t change the code. Category 5 is custom or bespoke software written for your specific use. The logic underneath these categories is simple and, for conventional software, sound: the more you customise, the more the vendor’s testing stops covering you, and the more you have to test yourself. A Category 3 tool arrives with a documented, deterministic function set. You verify it does what the label says in your environment and you move on. A Category 5 system has no external testing to lean on, so you specify, design, build, and test it end to end. The problem is that an ML model breaks the assumption holding all of this together — that the software’s function is defined before deployment and stays fixed until you deliberately change it. A trained model’s function is inferred from a training set. Two teams using the same architecture and the same code produce different systems because they trained on different data. And the same deployed model can behave differently over time as the input distribution shifts, without a single line of code changing. GAMP 5’s categories describe code provenance and configuration; they were never built to describe learned behaviour. That is why teams get stuck. They ask “is our model Category 3, 4, or 5?” and discover no answer fits. The honest answer, in our experience across pharmaceutical AI engagements, is that the code around the model is one category and the model itself needs a separate, additional layer of validation that the category alone won’t give you. How do you assign a GAMP 5 category to an AI/ML system? Split the system before you classify it. An AI/ML system in a GxP context is not one thing; it is at least three distinct components, each of which carries its own category and its own validation obligation: The platform and runtime — the framework and serving stack (PyTorch or TensorFlow, an inference runtime like ONNX Runtime or TensorRT, container orchestration). This is typically Category 1 infrastructure or Category 3 non-configured software. The application code — the data pipeline, feature engineering, pre- and post-processing, business logic wrapping the model. Configured code is Category 4; anything bespoke is Category 5. The trained model artifact — the weights themselves, plus the training data, training procedure, and the acceptance criteria the model was validated against. This does not map to any GAMP 5 category cleanly, and pretending otherwise is the mistake. GAMP 5 classification for AI/ML components Component Typical GAMP 5 category What the category covers What it leaves uncovered Framework / inference runtime 1 or 3 Supplier qualification, install verification Nothing model-specific — but pin the version Data pipeline & pre/post-processing 4 or 5 Requirement traceability, functional testing Data quality and drift at the input boundary Wrapper / business logic 5 Full spec-design-build-test lifecycle Model decision behaviour Trained model artifact No clean fit — Everything: performance, generalisation, drift, explainability The category assignment (observed-pattern; based on how we structure these engagements, not a regulatory mandate) tells you how to validate the software. It says almost nothing about how to validate the model, which is where most of the real risk lives. Once you accept that the model needs its own validation layer, the classification argument stops being a dead end and becomes the scaffolding for a defensible package. The model validation layer GAMP 5 doesn’t specify Conventional computerised system validation asks: does the software do what it was specified to do, reliably and repeatably? For deterministic code that question is answerable with functional and requirement testing. For a model, “what it was specified to do” is a statistical claim — “classify defective vials with sensitivity above a defined threshold on a representative population” — and verifying it requires a different toolkit. A defensible model validation layer, layered on top of whatever GAMP 5 category the surrounding code sits in, needs to establish four things. Performance against a locked, representative test set. The model’s acceptance criteria — sensitivity, specificity, precision at the operating threshold — must be measured on data the model never saw during training, and that test set must be representative of the production population, not a convenience sample. This is a benchmark-class claim in the validation package: a named, reproducible measurement against declared criteria. If the test set is not representative, the whole package is built on sand, regardless of how clean the software validation looks. Data lineage and integrity. Because the model is its training data in a real sense, the provenance, quality, and integrity of that data are part of the validated state. This is where GAMP 5 meets EU GMP Annex 11’s requirements for data integrity and computerised systems — the audit trail has to reach back into how the model came to behave the way it does, not just how the software runs today. Boundary and failure behaviour. What does the model do at the edges of its training distribution? A vision model trained on one line’s lighting conditions can degrade silently when deployed on a line with different optics. The validation has to characterise these boundaries, not assume they don’t exist. Silent degradation with no error thrown is the failure mode we watch for most closely, because deterministic-software validation habits don’t catch it. Ongoing monitoring — continuous validation. This is the most important departure from classical CSV. A deterministic Category 4 system, once validated, stays validated until you change it. A model can fall out of its validated state without anyone touching it, because the world its inputs come from changed. So the validated state is not a point in time; it is a monitored condition. Input drift detection, periodic performance re-measurement against fresh labelled data, and defined retraining-and-revalidation triggers are part of the validation, not an operational afterthought. A risk-based validation rubric for AI/ML in GxP The effort you spend on each layer should scale with the risk the system carries — the same principle GAMP 5 and the current move toward Computer Software Assurance both rest on. Use this rubric to size the validation before you write a single protocol. Scoring the validation depth an ML system needs Score each dimension 1 (low) to 3 (high); sum for a rough depth indicator. Patient / product impact — Does a model error reach the patient or the released batch directly (3), through a human review step (2), or only advisory (1)? Decision autonomy — Does the model act automatically (3), gate a human decision (2), or merely surface information (1)? Data drift exposure — Is the input environment volatile (3), moderately stable (2), or tightly controlled (1)? Explainability demand — Must every decision be individually justified to a regulator (3), aggregate performance suffices (2), or is it non-critical (1)? A total of 4–6 supports a light, risk-based CSA-style approach where you lean on vendor evidence and focus testing on the high-risk paths. A total of 10–12 signals a high-impact system that needs the full model validation layer, formal challenge testing, and a continuous monitoring plan with pre-defined revalidation triggers. This scoring is a planning heuristic drawn from how we scope these engagements — not a regulatory scoring system, and not a substitute for your quality unit’s judgement. The rubric also protects you from the opposite failure: over-validating a low-risk advisory tool as if it were an automated release-gate. Effort spent where the risk isn’t is effort stolen from where it is. Where classification meets the rest of GxP Getting the category right is necessary but not sufficient. The classification decision plugs into a wider compliance picture — what GxP compliance actually requires for AI software goes beyond software categories into supplier assessment, change control, and data governance, and the model validation layer described here has to be traceable through all of it. Two practical consequences follow. First, change control for an ML system must treat retraining as a change — a new model artifact is a new validated state, even if no code moved. Second, the intended-use statement matters more than usual: a model validated for computer-vision-based inspection under one set of conditions is not automatically valid for another, and the classification package should state the boundary of the claim explicitly. FAQ What GAMP 5 category does an AI/ML system fall into? There is no single category, because an AI/ML system is really several components. The framework and runtime are usually Category 1 or 3, the data pipeline and wrapper code are Category 4 or 5, and the trained model artifact does not map cleanly to any category. The practical approach is to classify each component separately and add a model-specific validation layer on top. Why can’t a trained model be classified like normal software? GAMP 5 categories describe code provenance and configuration, assuming a system’s behaviour is fully specified before deployment and stays fixed until you change the code. A model’s behaviour is learned from training data and can drift over time without any code change. The category system was never built to describe learned, statistical behaviour, so it has to be extended rather than forced to fit. What does validating the model itself involve? Four things beyond conventional software testing: measuring performance against a locked, representative test set with declared acceptance criteria; establishing data lineage and integrity for the training data; characterising boundary and failure behaviour at the edges of the training distribution; and setting up continuous monitoring with drift detection and defined retraining-and-revalidation triggers. The validated state becomes a monitored condition, not a one-time event. How do I decide how much validation an AI system needs? Scale the effort to the risk. Score the system on patient or product impact, decision autonomy, data-drift exposure, and explainability demand. A low-risk advisory tool supports a light, CSA-style approach focused on high-risk paths; a high-impact automated system needs the full model validation layer, challenge testing, and a continuous monitoring plan. The rubric protects against both under- and over-validating. Classification isn’t a filing exercise. Assigning the category is where you decide, in writing, which parts of a learning system you are prepared to defend to an inspector — and the part that most needs defending, the trained artifact and its ongoing behaviour, is precisely the part the categories don’t name. Get the split right first; the protocols follow from it.
