There is no such thing as a GxP-compliant AI product. Compliance is not a property a vendor stamps on software before it ships. It is a property of a specific system, doing a specific job, inside a specific quality management system — and it holds only as long as you can prove, on demand, that the system does what you say it does.

That distinction sounds pedantic until a regulator asks for it. A team buys a defect-detection model advertised as “21 CFR Part 11 ready,” deploys it on a fill-finish line, and assumes the label carries the burden. During an inspection they are asked one question: show me the documented evidence that this model performs as intended for your product, on your line, under your change control. The label does not answer that. The label was never going to answer that.

GxP is a documentation regime, not a software feature

GxP — Good Manufacturing, Laboratory, and Clinical Practice — is a family of regulatory expectations enforced by agencies like the FDA and EMA. When software touches a GxP process, the expectation is not that the software be perfect. It is that you can demonstrate control: over what the software is supposed to do, whether it does it, and what happens when it changes.

For conventional deterministic software, this maps cleanly onto validation practice built up over decades. AI software breaks the clean mapping in one specific place: the behaviour of a machine-learning model is defined by data and training, not by a specification an engineer wrote line by line. That does not exempt AI from GxP. It changes where the evidence has to live and how much of it you need.

Three requirements carry most of the weight, and none of them is optional.

Intended use must be defined before anything else. In our experience working on regulated life-sciences systems, this is where projects most often go wrong — teams validate a model’s raw accuracy without ever fixing, in writing, the narrow claim the model is allowed to make. A vision model that flags cosmetic vial defects is a different regulated object from one that makes a batch-release decision, even if it is literally the same weights. Intended use determines the risk class, which determines everything downstream.

Data integrity has to be intact end to end. The industry shorthand is ALCOA+: data must be Attributable, Legible, Contemporaneous, Original, Accurate, and — the plus — Complete, Consistent, Enduring, and Available. For an AI system this is broader than most teams expect. It covers the training data provenance, the audit trail of predictions, the immutability of logs, and the traceability from a given output back to the model version and input that produced it.

Change management must be defined for a system that learns. A model that is retrained, fine-tuned, or fed a shifted data distribution is, from a regulatory standpoint, a changed system. If your change-control procedure cannot describe when a retrain triggers revalidation, you do not have a compliant system — you have one that happens not to have been inspected yet.

What does GxP compliance require for an AI system, concretely?

Here is the requirement set most teams can extract and check against their own project. It is deliberately framed as obligations, not features.

Requirement	What it means for AI software	Where teams underestimate it
Defined intended use	A written, narrow claim about what the model decides and what it does not	Treating “detects defects” as a use claim instead of a scoped one
Risk classification	GAMP 5 category + process-risk assessment driving validation depth	Assuming all AI is automatically highest-risk (or lowest)
Validation evidence	Documented proof the system meets intended use, at defined thresholds	Confusing R&D model metrics with validation evidence
Data integrity (ALCOA+)	Provenance, audit trails, immutable logs, output→version traceability	Ignoring training-data lineage
Change control	Defined triggers for revalidation on retrain / data drift	Having no policy for what a retrain does to validated status
Electronic records / signatures	21 CFR Part 11 or EU GMP Annex 11 controls where records are regulated	Bolting Part 11 on after deployment

The single most useful move a team can make is to write the intended-use statement first and let it size everything else. A tightly scoped claim can be validated with proportionate effort. A vague claim expands the validation surface without bound.

Why “the vendor says it’s compliant” fails in practice

The compliance-by-purchase assumption fails for a structural reason: the regulated object is the system in its operational context, and the vendor does not control that context. A pre-trained model has no knowledge of your line’s lighting, your product’s tolerances, your batch record system, or your SOPs. Those are exactly the variables that determine whether the model performs as intended.

This is why the useful question during procurement is not “is this compliant?” but “what does this software let me evidence, and what do I still have to engineer myself?” The answer usually reveals a real gap — and that gap is engineering work, not paperwork. We explore the analogous line for AI note-takers, LLMs, and video systems in what makes an AI or video workflow HIPAA- or GxP-ready — and what it doesn’t, and the pattern is identical: the label covers a narrow slice; the workflow around it is where readiness is actually built.

The validation depth you owe is not fixed. It scales with risk, and the framework for that scaling already exists. GAMP 5 gives a software-category model, and the FDA’s Computer Software Assurance (CSA) guidance reframes the effort as risk-proportionate rather than documentation-maximal. Choosing between a lean CSA approach and full computer system validation is a real decision with real consequences — we work through it directly in when to use CSA vs full CSV for AI systems in pharma, and the mechanics of classifying an AI/ML system under the category model appear in how to classify and validate AI/ML software under GAMP 5 in GxP environments.

The failure mode nobody budgets for: silent drift

The dangerous compliance gap in AI systems is not the one you catch during validation. It is the one that opens after validation, when the model is running in production and the world it was validated against quietly moves.

A vision model validated on one supplier’s vials sees a second supplier’s slightly different glass. A predictive quality model trained on last year’s raw-material profile meets this year’s. Nothing throws an error. Predictions keep coming, formatted the same way, and the audit trail records them as clean. The system is now, in regulatory terms, operating outside its validated state — and no one knows, because deterministic software would have thrown an exception and this software just shifts its distribution.

Recognising this early requires two things the initial validation must build in: monitoring that tracks input distribution and output confidence against the validated baseline, and a change-control policy that treats a detected drift as a formal trigger, not a maintenance note. Under the EU regime these expectations are increasingly explicit; we map them in EU GMP Annex 11 requirements for computerised systems in pharmaceutical manufacturing. The consequence of ignoring drift is not an abstract citation — it is a batch produced under a system that was no longer doing what your records claim it does.

FAQ

Is any AI software “GxP compliant” out of the box?

No. Compliance is a property of a specific system doing a specific job inside your quality management system, not a property a vendor can pre-certify. A pre-trained model has no knowledge of your line, product, or SOPs — the exact variables that determine whether it performs as intended. The label may cover technical controls like electronic records, but the validation evidence for your context is yours to produce.

What are the core GxP requirements an AI system has to meet?

At minimum: a written intended-use statement, a risk classification that sets validation depth, documented validation evidence that the system meets that intended use, end-to-end data integrity per ALCOA+, and a change-control procedure that defines when retraining or data drift triggers revalidation. Where the system creates regulated records, 21 CFR Part 11 or EU GMP Annex 11 controls also apply.

Does retraining an AI model break its validated status?

From a regulatory standpoint, a retrained, fine-tuned, or distribution-shifted model is a changed system. Whether that change requires revalidation must be defined in advance by your change-control procedure. If you have no written policy describing what a retrain does to validated status, you do not have a compliant system — you have one that has not yet been inspected.

How much validation does an AI system actually need?

Validation depth scales with risk, not with how novel the AI is. GAMP 5’s software-category model and the FDA’s Computer Software Assurance guidance both frame the effort as risk-proportionate. A tightly scoped intended-use claim can be validated with proportionate effort; a vague claim expands the validation surface without bound, which is why the intended-use statement should be written first.

The teams that stay inspectable are not the ones with the most impressive model metrics. They are the ones who can, at any moment, trace a single production output back to the version, input, and validated claim that produced it — and who wrote down, before deployment, what would have to change for that chain to break.