GxP is a scope boundary, not a blanket requirement The letters GxP — where x stands for any of the “good practice” domains (manufacturing, laboratory, clinical, distribution, pharmacovigilance) — describe the regulatory framework governing activities that affect pharmaceutical product quality, patient safety, and data integrity. When a software system operates within that scope, it falls under GxP regulation and must meet specific requirements for validation, documentation, data integrity, and change control. When it does not, those requirements do not apply. This distinction sounds obvious, and yet pharmaceutical organisations routinely misapply it in both directions. The common error is treating non-GxP business software as if it required the same validation as a GxP-critical batch release system. The less common but more dangerous error is deploying AI in a GxP-impacting context without recognising the regulatory implications until an auditor raises them. Both are expensive. Both stem from the same root cause: insufficient clarity about where the GxP boundary actually sits for AI systems. As reported in the ISPE Good Practice Guide on Data Integrity (2021), over 50% of FDA warning letters reference data integrity deficiencies — a directional industry-scale figure from the published guide, not an operational benchmark for any specific firm. PIC/S PI 041-1 (2021) establishes that data governance must cover the complete data lifecycle across all GxP-regulated activities. Both signals point in the same direction: the regulators care less about whether a tool is “AI” or “deterministic code” and more about whether it touches data and decisions that are already in scope. Which “x” applies to AI in pharmaceutical manufacturing? The most relevant GxP domain for AI software inside a pharmaceutical manufacturing facility is GMP — Good Manufacturing Practice. GMP governs the production and quality control of pharmaceutical products, and any software system that participates in GMP-regulated activities falls under its requirements. The other domains (GLP, GCP, GDP, GVP) come into play in adjacent contexts, but on the manufacturing floor, GMP is where the weight of the framework sits. A handful of regulatory instruments do most of the work. 21 CFR Parts 210 and 211 (United States) define current Good Manufacturing Practice for finished pharmaceuticals. Part 211 establishes requirements for production and process controls, laboratory controls, and records. AI systems that participate in any of these functions — process parameter control, in-process testing, quality control analytics, batch record management — are GMP-regulated software. EU GMP Annex 11 (European Union) governs computerised systems used in GMP-regulated environments. It applies to any computerised system that creates, modifies, maintains, archives, retrieves, or transmits data required under GMP. An AI model that generates quality predictions, classifies inspection images, or flags process deviations falls within Annex 11 scope if its output informs a GMP decision. 21 CFR Part 11 (United States) governs electronic records and electronic signatures. It applies when electronic records are used to meet a predicate-rule requirement — any GMP requirement that could be satisfied by a paper record but is instead satisfied electronically. An AI system that produces electronic records used for batch release, deviation documentation, or quality review is a Part 11 system, regardless of whether it is also validated under GMP. ICH Q10 (International) provides a harmonised pharmaceutical quality system framework. It does not impose specific software-validation requirements, but it establishes the management responsibility and continuous-improvement expectations that govern how AI systems should be integrated into the quality system. In our experience across pharma engagements, most AI systems being proposed in manufacturing settings touch GMP processes somewhere — observed pattern, not a benchmarked rate. The useful question is rarely “does GxP apply?” It is almost always “which GxP requirements apply, and with what intensity?” The three dimensions of GxP scope for AI Whether an AI system is GxP-regulated — and what that regulation actually demands — depends on three dimensions that should be assessed independently for each system. Product quality impact. Does the system’s output directly or indirectly affect the quality of the finished pharmaceutical product? A computer-vision model that decides whether tablets meet specification has direct product-quality impact and is unambiguously GxP. A predictive-maintenance model that forecasts equipment failure has indirect impact: if the equipment failure would affect product quality, the model’s GxP status depends on whether it is the primary control or a supplementary signal. A meeting-room scheduling algorithm has no product-quality impact and is not GxP regardless of where it runs. Patient safety impact. Does the system’s output affect patient safety? This dimension overlaps with product quality for many manufacturing applications, but it extends further for systems involved in clinical decision support, pharmacovigilance signal detection, or drug-device combination products. The threshold here is lower than for product quality — if there is any credible pathway from the model’s output to a patient-safety consequence, the system warrants a GxP classification assessment rather than a casual dismissal. Data integrity impact. Does the system create, modify, or manage data subject to GxP data-integrity requirements? Under the ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available), data supporting GMP decisions must maintain integrity throughout its lifecycle. An AI system that processes, transforms, or stores GxP data — even if it does not make the GMP decision itself — falls within the data-integrity scope of 21 CFR Part 11 and EU GMP Annex 11. The decision rubric is simple to state and harder to apply honestly: Dimension scored Regulatory response Zero across all three Not GxP. Sound IT governance only. One dimension, low intensity GxP-lite: documented intended use, risk-based controls, no full CSV. Two or more dimensions, or any high-intensity score Full GxP treatment proportionate to risk class. A system that scores zero on all three is not GxP-regulated. A system that scores on any dimension requires a proportionate regulatory response — which is where the distinction between CSA and full CSV for AI systems becomes operationally important. What GxP-regulated AI software must demonstrate Once an AI system is classified as GxP-regulated, the requirements are not optional and do not depend on the organisation’s comfort level with AI. They are recognisable to anyone who has validated traditional GMP software, with model-specific nuances layered on top. Intended use documentation. The system must have a documented intended use that specifies what it does, in what context, and what decisions it supports. For AI systems this includes the model’s input data, the type of output it produces, and the manufacturing context in which that output is used. Intended use is the foundation for everything that follows — validation scope, risk assessment, and ongoing monitoring all derive from it. Write it ambiguously and the rest of the dossier inherits the ambiguity. Risk-based validation. The system must be validated proportionate to its risk, as determined by the GxP scope assessment. We see this step stall regularly because quality teams interpret “validation” as exclusively meaning the full CSV lifecycle — IQ, OQ, PQ with comprehensive scripted testing. The current regulatory landscape, particularly the FDA’s Computer Software Assurance guidance, explicitly allows risk-proportionate validation. The validation must demonstrate that the system performs its intended use reliably, but the evidence required to demonstrate that reliability scales with risk. Data integrity controls. The system must maintain the integrity of any GxP data it creates, processes, or stores. For AI systems specifically, that means: an audit trail for model outputs, version control for model artifacts (weights, configuration, preprocessing logic), and access controls that prevent unauthorised modification of the model or its training data. These controls apply under both US and EU regulatory frameworks; the specific implementation details differ but the underlying expectations do not. Change control. Any change to the validated AI system — model retraining, preprocessing pipeline modification, infrastructure changes that could affect model behaviour — must go through a documented change-control process. The intensity scales with risk: high-risk changes may require revalidation, while low-risk changes may need only a documented impact assessment. This is where AI-specific governance matters most. A retrained model is not a “configuration change”; it is, in practice, a new artifact that needs to be re-evaluated against the original intended use. Periodic review. EU GMP Annex 11 requires periodic review of computerised systems. For AI systems, that translates to ongoing performance monitoring against the acceptance criteria established during validation. The validation-ready AI approach for GxP operations treats monitoring infrastructure as part of the validated system, not as a separate operational concern. A GxP AI system without continuous performance monitoring cannot demonstrate that it continues to meet its intended use — and from a regulatory perspective, a system that cannot demonstrate ongoing compliance is not compliant. The systems that are not GxP — and why that matters The practical value of a clear GxP boundary is not just knowing what requires validation. It is knowing what does not. A substantial proportion of operational software inside a pharmaceutical manufacturing facility — including many potential AI applications — sits outside GxP scope entirely. Production scheduling optimisation, energy management, workforce planning, supply-chain forecasting, equipment procurement analytics, and general business intelligence systems do not affect product quality, patient safety, or GxP data integrity. They require sound IT governance — access control, change management, backup — but not GxP validation. The relevant ISO controls and the company’s internal IT policies are the right frame, not Annex 11. As reported in the ISPE GAMP 5 Second Edition (2022), applying risk-based approaches such as CSA can reduce validation documentation effort by 30–50% compared to traditional CSV for non-GxP and low-risk systems — a directional industry-scale figure from the published guide, not an operational benchmark — primarily through reduction in scripted testing and protocol documentation. Per ISPE’s GAMP Community of Practice benchmarking (2022), pharmaceutical manufacturers spend billions annually on software-validation activities, with a meaningful share directed at systems that fall outside GxP scope (directional industry-scale figure, market-direction). Treating these systems as GxP-regulated wastes validation resources on documentation that no regulator requires. It delays deployment of tools that could improve manufacturing efficiency. And — perhaps most importantly — it dilutes the quality team’s attention from the systems that genuinely need rigorous validation. When everything is treated as high-risk, the actual high-risk systems do not receive proportionate attention; they get the same envelope as the scheduling dashboard, which is either too much for the dashboard or too little for the batch-release system. The first step in any AI deployment programme inside pharmaceutical manufacturing is a system-by-system GxP scope assessment that draws this boundary clearly. A GxP Regulatory Scope Analysis maps each planned AI system against the three dimensions — product quality, patient safety, data integrity — and classifies the appropriate regulatory response before the first line of validation documentation is written. FAQ What does GxP compliance specifically require when the software is AI/ML rather than deterministic code? The same five obligations as any GxP computerised system — documented intended use, risk-based validation, data integrity controls, change control, and periodic review — but with model-specific evidence. That means version control over model weights and preprocessing logic, audit trails on inference outputs, and ongoing performance monitoring tied to the acceptance criteria fixed at validation. Which GxP rules apply to AI training data, models, and inference outputs? If the model informs a GMP decision, EU GMP Annex 11 governs the computerised system itself, 21 CFR Part 11 governs any electronic records and signatures it produces, and 21 CFR 211 sets the underlying production and quality requirements. ALCOA+ data integrity principles apply across training data, model artifacts, and inference outputs whenever those data support a GMP decision. How is a GxP-validated AI system kept compliant as the model retrains or drifts? Retraining is a change-control event, not a configuration tweak. The change must be assessed for impact on intended use, and high-risk changes trigger revalidation. Periodic review under Annex 11 requires ongoing performance monitoring against the acceptance criteria established during validation; a system that cannot demonstrate stable performance against those criteria is, from a regulatory perspective, no longer compliant. Where is the boundary between GxP and non-GxP usage of AI inside a pharma manufacturing workflow? The boundary runs along three dimensions: product quality impact, patient safety impact, and GxP data integrity impact. A system that scores zero across all three is not GxP-regulated. A system that scores on any dimension warrants a proportionate regulatory response, calibrated to the intensity of the impact rather than to a blanket category. Which GxP roles (system owner, QA, validation lead) own AI-specific risks and how is that documented? The standard GxP roles still apply: a system owner accountable for fitness for intended use, QA accountable for compliance with the quality system, and a validation lead accountable for the validation evidence. AI-specific risks — drift, training-data lineage, model-update governance — are typically documented in the intended use document, the risk assessment, and the change-control SOP, with explicit ownership assigned for each. How do ISPE’s GAMP AI guidance and the ISPE AI maturity model fit into an existing GxP programme? They sit on top of GAMP 5 Second Edition rather than replacing it. The GAMP framework still classifies the system and drives validation rigour; the AI guidance and maturity model extend it with AI-specific considerations — model lifecycle, training-data governance, monitoring, explainability — that an existing GxP programme needs to absorb rather than treat as a parallel track. The boundary is the work The GxP question for AI in pharmaceutical manufacturing is not “how do we validate AI?” It is “which of our AI systems are inside the regulated scope, and which are not?” Answer that honestly, and the validation effort sizes itself. Skip it, and the programme either over-validates everything into paralysis or under-validates the systems that actually carry patient-safety weight. The boundary is the work; everything downstream is execution.
