GxP compliance for software is not a certificate you can buy. The regulated company has to demonstrate it, and it does so with three things: validated systems, controlled documentation, and data that meets integrity rules an inspector can test. EU GMP Annex 11 applies that to all forms of computerised systems used in GMP-regulated activities. The rules come from several good practices (manufacturing, laboratory, clinical, distribution and pharmacovigilance), and they share core concepts: traceability, accountability and data integrity under ALCOA.
This page covers what those requirements mean for software, AI included. Whether a given activity falls under GxP or only under GMP is a scoping question, and GxP vs GMP and scope is covered separately.
Which good practices apply to GxP compliance software, and who writes them
WHO defines GxP as the group of good practice guides that govern preclinical, clinical, manufacturing, testing, storage, distribution and post-market activities for regulated pharmaceuticals, biologicals and medical devices. Each region writes and enforces its own rules, but the basic concepts and requirements are much the same everywhere. For a broader walk through each domain, see our practical guide to GxP in pharma.
| Practice | What it governs | Texts that set the software expectations |
|---|---|---|
| GMP | Manufacture of medicines, and of APIs from receipt of materials through to distribution | FDA CGMP for drugs in 21 CFR parts 210, 211 and 212, clarified by FDA’s data integrity Q&A; FDA’s Q7 guidance for APIs; EU GMP Annex 11 on computerised systems; the PIC/S GMP Guide; WHO GMP main principles |
| GLP | Non-clinical health and environmental safety studies | OECD Principles of GLP, adopted by the OECD Council in 1981 and revised in 1997 |
| GCP | Clinical trials involving human participants | ICH E6(R3) Guideline for Good Clinical Practice |
| GDP | Wholesale and distribution | EU GDP guidelines (interpreted in EMA’s Q&As), with PIC/S expecting the same computerised-system controls wherever automated systems and electronic records are used |
| GVP | Pharmacovigilance | Named by WHO as one of the GxP family |
Three regulator texts set out data integrity expectations. The status of these texts varies. Annex 11 interprets the GMP principles laid down in EU directives. FDA’s Q7 document carries nonbinding recommendations. OECD GLP underpins mutual acceptance of study data between member countries. For the US manufacturing texts in more depth, see what the cGMP regulations actually require.
Where is the boundary between GxP and non-GxP use of AI in a pharma manufacturing workflow?
The line is drawn by impact, not by technology. EMA’s first risk-assessment question to determine a system’s GMP criticality is whether it affects patient safety, product quality or data integrity. PIC/S defines GxP-critical systems as those that can affect product quality and patient safety, either directly (control systems, for example) or through the integrity of product data. FDA adds a test that catches many AI projects: any data generated to satisfy a CGMP requirement becomes a CGMP record.
Two consequences matter for AI. First, the boundary reaches well beyond production. PIC/S lists procurement, dispensing and weighing, testing, inventory control, training, calibration and maintenance among GxP-related activities that need compliance evidence. Second, one system can serve both CGMP and non-CGMP functions. When one system performs both CGMP and non-CGMP functions, FDA expects the firm to assess and mitigate the risk that the non-CGMP functions affect CGMP operations.
Here is how we would draw it. A model that forecasts site utility consumption for the finance team is one we would place outside GxP. A vision model that rejects tablets on an inspection line is inside, because FDA names automated visual inspection records among those it expects access controls to protect. If AI replaces a manual check, Annex 11 sets a clear bar: replacing a manual operation must not lower product quality, process control or quality assurance, and must not raise the overall risk of the process. Record each decision in the system’s risk assessment, ranked critical or not critical with the reasons written down. Then carry it into the site inventory of computerised systems, which shows each system’s validation status and risk ranking.
ALCOA+ is the test an inspector applies to GxP data
ALCOA+ stands for attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available. In WHO’s 2021 wording, those last four must hold throughout the data life cycle for the defined retention period. WHO, EMA, FDA and PIC/S all use the acronym. EMA calls compliance with ALCOA principles the main regulatory expectation for data integrity.
| Attribute | What it requires of a computerised system |
|---|---|
| Attributable | It is possible to identify the individual or computerised system that performed a task and when, and for changes who made them, when and why. Shared logins should not be used for systems that generate, amend or store GxP data. |
| Legible | Data stays readable. Often only the original application, or a specific version of it, can read electronic data, so check readability before any upgrade. |
| Contemporaneous | Data is recorded when it is generated, and electronic data is time-stamped automatically. |
| Original | The first capture, and everything needed to reconstruct the GxP activity, is kept and available. |
| Accurate | Data is a truthful record, supported by qualification, calibration, computer validation, deviation management and trained staff. |
| Complete | All data is retained for review, including obvious errors and failing, passing and suspect results. |
| Consistent | System time and time zones are configured and verified, and the ability to change them is restricted. |
| Enduring | Archived data is protected, retrievable and readable for the whole retention period, and backed up under written procedures. |
| Available | Records can be retrieved and copied accurately in human-readable and electronic form throughout retention. |
A validated system is not automatically a system with low data integrity risk. EMA warns that validation alone may leave risk in place when users can influence what gets reported. PIC/S asks for validation to be backed by administrative and physical controls and by user training.
Which GxP rules apply to AI training data, models and inference outputs?
We would apply the general rules to all three, through the way each one is used. An inference output generated to satisfy a CGMP requirement becomes a CGMP record under FDA’s reading. So it needs its metadata (timestamp, user ID, instrument ID, audit trail), because FDA treats a value without its context as meaningless.
We treat the model itself like an analytical processing method. WHO requires each version of a processing method to be recorded, with audit trails that allow every step of data processing to be reconstructed over the data life cycle. Applied to a model, that means you can say which version produced which output, from which inputs. FDA’s description of dynamic records is a useful comparison. Its example is a chromatographic record that can be reprocessed until the peaks look different. A model that can be re-run with a new threshold has the same property and needs the same audit-trail discipline.
We would place training data under data-lifecycle and criticality rules. EMA notes that data crosses boundaries between IT systems, organisations and cloud storage, and that integrity can be lost at any stage. Criticality depends on the decision the data influences. On that reasoning, the dataset behind a model that gates batch release is as critical as the release data itself. Two further requirements apply to the pipeline. Interfaces that move data between systems need built-in checks for correct and secure transfer. True copies must keep their metadata, and PIC/S prohibits converting to PDF where metadata could be lost.
What does GxP compliance require when the software is AI/ML rather than deterministic code?
The requirements themselves do not change for AI/ML software. What changes is where the evidence has to come from. User requirements still describe the system’s functions, rest on a documented risk assessment and stay traceable through the life cycle. Risk management still sets how much validation and data integrity control is needed.
The difference lies in a principle PIC/S quotes from FDA: quality cannot be inspected or tested into finished software, so every phase of development must be controlled. In deterministic code, behaviour comes from source code you can review. In a trained model, behaviour also comes from the data and the training run. Those therefore become part of the development life cycle that has to be controlled. EMA’s data integrity risk factors point the same way. Complex processes with open-ended and subjective outcomes raise data integrity risk, while simple, well-defined, objective tasks lower it. A probabilistic classifier with a tunable threshold sits nearer the risky end than a fixed calculation does.
PIC/S notes that GAMP’s software categories are hard to apply to integrated systems that span several levels. For critical systems it calls for a holistic risk-based approach and for user judgement where a system does not fit. A typical AI pipeline (data platform, training code, model artefact, inference service) is one of those systems. A regulation-by-regulation reading of GxP for AI and software is also available. A draft revision or a new AI-specific annex binds no one until it is adopted, so design against the current Annex 11 text and watch the drafts.
GAMP 5 and the validated lifecycle that shows compliance
GAMP is industry guidance on GxP computerised systems. It began as a supplier guide written by a UK validation forum, is now sponsored by ISPE, and sets out best practice for specifying, building, testing, qualifying and documenting computerised systems. The second edition, which ISPE’s Pharmaceutical Engineering described in early 2023, keeps the first edition’s framework, key concepts and ICH Q9-aligned quality risk management. It adds coverage of IT and cloud service providers, iterative and incremental development, and greater use of software tools and automation. It also states plainly that the life cycle need not be linear and fully supports Agile methods.
The life cycle runs from initial requirements to retirement, through design, specification, programming, testing, installation, operation and maintenance. Validation is not one test or one report. It is documented evidence across that whole span. Qualification is part of it. FDA’s Q7 defines installation qualification (IQ) as verifying that systems as installed match the approved design, operational qualification (OQ) as verifying that they perform as intended across their operating ranges, and performance qualification (PQ) as verifying effective, reproducible performance under the approved process. PIC/S expects the test approach to be tailored to the specific system and justified by the regulated user. New systems need prospective validation, because retrospective validation is not an option for them. Our piece on what GxP validation evidence looks like goes further into the documents.
Where do ISPE’s GAMP AI guidance and AI maturity model sit in an existing GxP programme?
They belong inside the GAMP 5 programme you already run, not beside it as a second compliance track. Inspectors still use Annex 11 when inspecting computerised systems, and users must justify their standards against their own documented risk assessments. In practice, AI-specific guidance shapes how you fill in the existing artefacts: model risks in the user requirements and risk assessment, retraining in change control, and performance in periodic review. The second edition supports iterative methods and keeping records in software tools. We read a maturity model as a planning aid that creates no compliance obligation of its own.
Handling model retraining and drift through change control and periodic review
Two existing mechanisms do the work. We treat retraining as a change to a validated system, so it goes through change control. Drift is a performance question, so it goes into periodic review. FDA’s Q7 requires changes to computerised systems to be formally authorised, documented and tested, with records showing the system is maintained in a validated state. PIC/S expects the change procedure to assess the full impact of a change, including regression analysis and regression testing. It also expects no change to be made without review and authorisation on behalf of the stakeholders who own the user requirements, which may be the system owner and a QA representative.
Periodic evaluation covers performance, deviations, upgrade history and the cumulative effect of changes. The interval is set by the system’s criticality. FDA’s Q7 adds that revalidation is not normally needed when nothing significant has changed and a quality review confirms consistent output. For a model, the real question is which retraining counts as significant. Q7 offers a useful analogy here: in-process adjustments within limits approved in advance by the quality unit need no prior approval. In the same way, we would write the permitted retraining envelope (data sources, acceptance metrics, rollback) into the requirements, so routine retraining within it is a documented, pre-approved change and anything outside it triggers full change control. Monitoring design and acceptance thresholds are covered in our piece on validating AI continuously.
Assigning AI model decisions to the GxP roles you already have
Responsibility for GxP work already sits with existing roles in the regulatory texts, and how the cGMP regulations allocate those responsibilities is covered separately. We would assign AI risks explicitly to those existing roles.
| Role | What the texts give it | Where it is documented |
|---|---|---|
| Regulated user and senior management | Ultimate responsibility for making validation evidence available to inspectors, and for an effective data governance system | Quality system and data governance policy |
| System owner | Manages access to the system, and authorises changes together with QA | System description and change records |
| Quality unit (QA) | Independent of production; reviews and approves validation protocols | Approved protocols and reports |
| Persons responsible for validation | Documented in the validation policy as responsible for the design, review, approval and documentation of each validation phase | Validation policy or Validation Master Plan, which identifies key personnel and their responsibilities |
| Qualified Person (EU) | Final responsibility for compliance throughout the supply chain at batch certification, with access to the data and systems needed for that decision | Batch certification records |
We would watch the model-specific decisions: who approves a training dataset, who accepts a retrained model, and who decides that drift calls for revalidation. Name an owner for each in the Validation Master Plan and the risk assessment. PIC/S requires computerised-system training for developers and anyone whose work could affect the system’s documented operability.
A GxP compliance software checklist
- The system is validated for its intended use and kept in a validated state.
- User requirements are based on risk and traceable through the life cycle.
- A documented risk assessment ranks the system critical or not critical and gives the reasons.
- Audit trails are enabled from installation, verified periodically, and record who, when, the original value and the reason for each change.
- Each user has an individual login, roles follow least privilege, and administrators are independent of the record content.
- Changes go through formal change control with impact assessment, including regression testing as appropriate.
- Periodic review covers performance, deviations and cumulative changes.
- Backups keep data and metadata in the original or a compatible format.
- Retention meets the rule. Under FDA’s Q7, API production records are kept at least one year after batch expiry, or at least three years after full distribution where retest dates apply.
- Electronic signatures are attributable, cannot be altered, are permanently linked to their record, and are time-stamped.
- Suppliers are assessed for their ability to develop software to recognised quality standards.
- Everyone who handles GxP data is trained in data integrity principles.
Inspectors test the evidence, so build AI to produce it
Even though the reliability of the software still depends on the supplier’s engineering process, ultimate responsibility for the validation evidence stays with the regulated user. So the useful question for an AI build is not whether the model is accurate. It is whether the build produces the records a validation team needs: versioned models tied to their outputs, audit-trailed inference, controlled training data, and a retraining path that change control can sign off. TechnoLynx builds model pipelines and inference services designed to produce this evidence (AI engineering for life sciences). Validation evidence and batch release stay the regulated company’s responsibility. Before any vendor is involved, the open question is the GxP impact of each AI use, because that decides how much of the checklist applies.
FAQ
Which FDA rules set the data expectations for drug manufacturing software?
For drug manufacturing, FDA’s requirements sit in the CGMP regulations at 21 CFR parts 210, 211 and 212. FDA expects all data to be reliable and accurate, and allows flexible, risk-based strategies for preventing and detecting data integrity problems.
What are examples of regulatory requirements?
FDA treats shared login credentials as non-conforming with its CGMP requirements, because they prevent actions being attributed to one individual.
