What GAMP 5 2nd Edition Actually Says About AI
GAMP 5 2nd Edition, published in 2022, introduced explicit guidance on artificial intelligence and machine learning for the first time. The core position is consistent with GAMP 5's overall philosophy: the appropriate level of validation effort is proportional to the GMP risk and complexity of the system. AI and ML are not categorically exempt from validation, nor do they automatically require extraordinary treatment. What they do require is a validation approach that accounts for their specific characteristics — particularly the ones that distinguish them from conventional deterministic software.
The key characteristics GAMP 5 highlights for AI/ML systems in GMP contexts are: the model may learn and change its behaviour over time; the decision logic may not be fully interpretable; performance depends heavily on training data quality; and the system's outputs may be probabilistic rather than deterministic. Each of these creates validation challenges that standard V-model approaches do not fully address — and GAMP 5 2nd Edition's guidance provides the framework for addressing them.
GAMP 5 2nd Edition states that AI/ML systems used in GMP-regulated activities must be validated to demonstrate they are fit for intended use, with the approach scaled to the intended use, GMP criticality, and the inherent characteristics of the AI model type. The validation requirement does not disappear because the system uses a neural network instead of deterministic logic. It changes shape.
GAMP Category Classification for AI Systems
AI and ML systems in pharma typically fall into GAMP 5 Category 5 — custom software — because the trained model itself represents bespoke, purpose-built logic that is specific to the training data and intended application. A pre-trained commercial AI platform configured for a specific use case may have elements of Category 4, but any system where the model training, architecture, or decision boundaries are specific to the pharmaceutical application will carry Category 5 obligations.
Category 5 classification means the full software development lifecycle applies: a Software Design Specification describing the model architecture and training approach, documented version control of the trained model as well as the application code, unit testing and integration testing evidence, and full functional qualification through IQ, OQ, and PQ. For AI systems, the SDS needs additional content that is not standard in conventional automation projects: training data provenance and quality assessment, model performance metrics and their acceptance criteria, and the retraining trigger conditions and change control process for model updates.
The Explainability Problem — Why Black-Box AI Is Difficult in GMP
One of the most distinctive compliance challenges AI introduces in GMP environments is explainability. In a conventional PLC programme, every output has a traceable, deterministic cause: the pump started because the level sensor crossed threshold X and interlock Y was satisfied. You can write a test case that confirms this logic, and you can explain it to an auditor in unambiguous terms.
A deep learning model that classifies tablet coating quality from camera images may achieve 98% accuracy on the test set, but the decision pathway from input pixels to classification output is not directly interpretable. The model works — the evidence shows it works — but the question "why did it reject this tablet?" does not have the same kind of traceable answer that a rule-based system provides.
GAMP 5 2nd Edition addresses this through the concept of explainability requirements in the URS. Depending on the GMP criticality of the AI decision, the URS should specify what level of explainability is required. For a decision that directly affects product release — such as an automated batch disposition recommendation — a higher level of explainability (feature importance, confidence scores, human-in-the-loop review) may be required. For a decision that affects process efficiency but not product quality — such as a predictive maintenance alarm — lower explainability may be acceptable with compensating controls.
For AI systems making decisions that directly affect GMP-critical outcomes — batch release, critical process parameters, product quality attributes — GAMP 5 2nd Edition guidance and current regulatory expectation strongly favour maintaining a human review step rather than allowing fully autonomous AI decisions. An AI recommendation reviewed and approved by a qualified person is far easier to defend than an autonomous AI decision, regardless of the model's demonstrated accuracy.
AI Use Cases in Pharma — Ranked by GMP Risk
Not all AI applications in pharmaceutical manufacturing carry the same GMP risk. The validation depth and ongoing monitoring requirements scale with the criticality of what the AI system is deciding or predicting.
Training Data as a GMP Record
A validation consideration that is easy to overlook for AI systems is the status of training data. A trained ML model is only as reliable as the data it was trained on. If the training dataset contained labelled errors — misclassified samples, out-of-specification readings logged as in-spec, sensor readings from a miscalibrated instrument — the model will have learned from corrupt data, and its outputs reflect that corruption regardless of how sophisticated the model architecture is.
GAMP 5 2nd Edition and the broader industry guidance position training data as a critical artefact that must be controlled and documented. This means: the training dataset must be version-controlled, the data sources must be documented and qualified, any labelling process must be described and the labellers identified, and the data quality assessment must be included in the SDS. For a GMP-critical AI application, the training data is effectively a GMP record — it must be retained, it must be reproducible, and it must be available for regulatory inspection.
Model Drift and Change Control
The most distinctive lifecycle challenge for AI systems in GMP environments is model drift — the gradual degradation of model performance as the real-world data the model encounters diverges from the distribution it was trained on. A visual inspection model trained on images from one tablet press may perform poorly on images from a second tablet press with different lighting. A predictive maintenance model trained on data from new equipment may give misleading predictions as the equipment ages and its failure signatures change.
Managing model drift in a GMP context requires defining, in the URS, the performance metrics that will be monitored and the thresholds that trigger retraining. When retraining occurs, it constitutes a change to the validated software baseline and must go through formal change control. The retrained model is a new validated version — it needs a new model hash, updated documentation, and re-execution of the relevant qualification test cases before it can be deployed in a GMP-regulated application.
This is the area where the difference between AI validation and conventional software validation is most practically significant. A PLC programme does not spontaneously change its behaviour over time. An ML model's effective behaviour can degrade without any human intervention. The ongoing monitoring and change control discipline required for AI systems is therefore more intensive than for conventional automation, and this must be reflected in the lifecycle plan from the start of the project.
What Your Validation Package Needs for an AI System
The structure of a GAMP 5 validation package for an AI or ML system follows the same V-model as any Category 5 custom application, with additional content at each stage. The URS must define the intended use with enough precision that a holdout test set can be constructed to verify it — which means specifying performance metrics, not just functional requirements. The SDS must describe the model architecture, training methodology, training/validation/test data split, and performance acceptance criteria. The IQ must establish the version-controlled model baseline including the trained model hash.
The OQ testing approach for AI systems is fundamentally different from rule-based software testing. Rather than writing test cases that verify specific logical conditions, OQ for an ML model involves executing the model against a holdout dataset that was not used in training and verifying that the pre-defined performance metrics are met. Edge cases, adversarial inputs, and out-of-distribution inputs should be included. The PQ phase then verifies performance under real process conditions over a defined period, with ongoing metric monitoring.
| V-Model Stage | Conventional Automation | AI/ML System — Additional Content |
|---|---|---|
| URS | Functional requirements | Performance metrics, explainability requirements, drift thresholds, human oversight scope |
| SDS | Application code description | Model architecture, training data provenance, data split methodology, performance acceptance criteria |
| IQ | Software version, config baseline | Trained model version hash, training infrastructure, data lineage documentation |
| OQ | Scripted functional test cases | Holdout dataset performance tests, edge case testing, adversarial input testing |
| PQ | Process performance under production conditions | Live performance monitoring, drift detection, KPI tracking over defined period |
| Lifecycle | Change control for code changes | Change control for retraining events + ongoing drift monitoring programme |
AI in GMP environments is not a future consideration — it is a present one. The validation framework exists. The categories are defined. The lifecycle requirements are documented in GAMP 5 2nd Edition. What the industry is still developing is the practical experience of executing these requirements at scale, and the regulatory confidence to accept AI-assisted decisions in the most critical GMP applications. For automation engineers building these systems now, the approach is clear: treat the AI model as a Category 5 custom software component, document the training and performance evidence with the same rigour as any other validated software, and build the ongoing monitoring and change control discipline into the project from day one.