The acronym most pharma teams use without defining GxP stands for “Good x Practice,” where x is a placeholder for the specific domain of pharmaceutical regulation: manufacturing (GMP), laboratory (GLP), clinical (GCP), distribution (GDP), pharmacovigilance (GVP). Each domain has its own regulatory guidance, enforcement body, and documentation requirements. Together, they form the regulatory framework ensuring that pharmaceutical products are consistently produced, tested, distributed, and monitored to quality standards appropriate for their intended use. For engineering and IT teams, the practical consequence for engineering and IT teams is that any system touching GxP-relevant data — batch records, test results, environmental monitoring, adverse event reports — must meet specific requirements for validation, audit trails, electronic signatures, and change control. Systems outside that scope do not carry these obligations, regardless of where they physically sit in the facility. What does each GxP domain actually cover? Domain Full name Scope Key regulation GMP Good Manufacturing Practice Production, packaging, labelling, storage EU GMP Annex 11, 21 CFR Part 211 GLP Good Laboratory Practice Non-clinical safety studies 21 CFR Part 58, OECD GLP GCP Good Clinical Practice Clinical trials and human subject data ICH E6(R2) GDP Good Distribution Practice Storage and transport of finished products EU GDP Guidelines 2013/C 343/01 GVP Good Pharmacovigilance Practice Adverse event monitoring and reporting EU GVP Modules I–XVI In our experience, a common misconception is that GxP applies uniformly to every system in a pharmaceutical facility. It does not. A meeting-room booking system in a GMP facility is not GxP-relevant. A warehouse management system that tracks temperature-controlled product storage is. The determining factor is whether the system creates, modifies, maintains, or transmits data that affects product quality, patient safety, or data integrity. Where AI software intersects with GxP AI and machine learning systems in pharma manufacturing trigger GxP requirements when they participate in quality-affecting decisions. A computer vision system performing automated visual inspection of injectable vials is GxP-relevant because its output directly determines whether product reaches patients. A predictive maintenance model forecasting HVAC filter replacement schedules is typically not GxP-relevant unless the HVAC system directly controls a classified manufacturing environment. The challenge for AI systems is that traditional GxP validation (IQ/OQ/PQ) assumes deterministic software — given the same input, the system produces the same output. Machine learning models do not behave this way. Their outputs change as training data changes, as model weights are updated, and as input distributions shift. This is why the GAMP 5 Second Edition (2022) introduced a risk-based approach that moves away from rigid category-based testing toward continuous monitoring and critical thinking. The full scope of what GxP compliance requires for AI software depends on the system’s risk classification, the data it processes, and the regulatory market it serves. GxP compliance is a scope decision, not a blanket mandate Three questions determine whether a system falls under GxP: Does the system affect product quality? If a failure or error in the system could lead to a product defect, contamination, or mislabelling, it is GxP-relevant. Does the system generate or manage GxP data? Batch records, analytical results, environmental monitoring data, deviation records, and stability data are all GxP data. Systems that create, modify, or store this data inherit GxP obligations. Does the system support a GxP process? Even if the system itself does not generate data, if it enables or controls a GxP process (e.g., a SCADA system controlling a bioreactor), it falls within scope. If the answer to all three is no, the system is not GxP-relevant. Treating non-GxP systems as GxP-relevant wastes validation effort and creates compliance noise that makes real quality issues harder to identify. How do engineering teams interact with GxP in daily work? For engineering teams building or maintaining systems in pharmaceutical environments, GxP affects three daily activities: development practices, change management, and incident response. Development practices: code changes to GxP-regulated systems must follow documented procedures. Each change requires a change request (describing what will change and why), impact assessment (which validated functions could be affected), test plan (how the change will be verified), and approval (by authorised personnel including quality representation). This does not prohibit modern development practices like continuous integration — it requires that CI pipelines include the documentation and approval steps. Change management: deploying changes to production GxP systems requires formal release procedures. Emergency changes (critical bug fixes) have expedited procedures but still require post-deployment documentation and review. The key discipline is that no change reaches production without documented evidence that it was tested, reviewed, and approved. Incident response: when a GxP system fails or produces unexpected results, the incident must be documented, investigated, and resolved through the quality system’s deviation handling process. The investigation determines whether the incident affected product quality or data integrity, what corrective action is needed, and what preventive action will prevent recurrence. We train engineering teams on these practices through hands-on workshops that integrate GxP requirements into their existing development workflow rather than treating compliance as a separate activity. The goal is to make compliance a natural part of the development process rather than an overhead that is bolted on after development is complete.
