The useful question about AI in GxP validation is not whether it is allowed. It is which specific artefact, at which specific lifecycle stage, a model may produce — and what a qualified human must still decide before that artefact carries any weight. Answered stage by stage, the picture is much clearer than the general debate suggests: AI is strong at drafting structured documents from existing source material, and categorically excluded from deciding GMP-critical questions.
This walks the lifecycle in order. At each stage: what AI can draft, what a human must decide, and what evidence an inspector will ask for. The last two sections cover the hard regulatory boundary and what human-in-the-loop means when you have to operate it rather than describe it.
Planning and scoping
What AI can draft. The validation plan skeleton — scope statement, deliverable list, role assignments, acceptance criteria — assembled from the system inventory record, the intended-use statement and your SOP templates. It can also draft the system boundary description by reading the architecture and interface documentation, which is the section teams most often write too thinly.
What a human must decide. Whether the system is GxP-relevant at all, what the intended use actually is, and where the validation boundary sits. These are business and quality determinations. A model can propose a boundary from documentation; only the system owner knows that the reporting layer is used for a release decision and therefore sits inside it.
What an inspector will want. An approved validation plan signed by QA and the system owner, with a boundary that matches what was actually tested. Inspectors do not ask how the plan was drafted. They ask why the scope is what it is, and the answer must come from a person.
Requirements authoring
What AI can draft. This is the strongest use case in the lifecycle. Given a configuration export, a URS from a comparable system, vendor functional documentation and the process description, a model produces a structured, testable, uniformly-phrased requirements set far faster than a person can type one — and typically with better consistency, because uniformity is exactly what models are good at. It can also flag requirements that are not testable as written, which is the defect that later causes the expensive rework during test authoring.
What a human must decide. Completeness and correctness. A model drafts from what it is given; it cannot know about the undocumented workflow the QC team actually uses, or that a requirement copied from the reference system does not apply here. Someone who knows the process must read every requirement and confirm it reflects real need. They must also assign the GxP impact classification per requirement, because that classification drives test depth and is a quality judgment.
What an inspector will want. An approved URS with identified authors and approvers, and requirements specific enough to test. If requirements read as generic boilerplate that could apply to any system of that type, that is a finding regardless of how they were produced. Specificity is the signal that human review was real.
GAMP classification and risk assessment
What AI can draft. A proposed GAMP category with the reasoning laid out — what is configured, what is custom, what the supplier provides — and a first-pass functional risk assessment: for each requirement, a candidate severity, probability and detectability with a stated rationale. Drafting the rationale is the part that saves real time, because the mechanical burden of a risk assessment is writing 200 justification cells, not deciding 200 risk levels.
What a human must decide. Every risk conclusion, without exception. The category assignment and each risk rating are quality decisions that determine test coverage on a GMP-relevant system; a model may propose and must not conclude. This is the stage where the Annex 22 boundary bites hardest, because a risk rating is precisely the kind of GMP-critical determination that cannot be delegated to an adaptive model. The reviewer must be able to disagree with any proposed rating and have that disagreement carried through to the test plan.
What an inspector will want. A risk assessment approved by QA, dated before test authoring, with rationales that read as considered rather than templated — and a visible, traceable relationship between risk level and test depth. If every requirement got the same test treatment, the risk assessment did no work and will be treated as decoration. See AI Risk Assessment and Classification Engine for how this is structured in practice.
Test design
What AI can draft. Test scripts from approved requirements: preconditions, steps, expected results, and the trace reference back to the requirement. It generates negative and boundary cases that manual authors routinely omit under time pressure — invalid inputs, permission violations, concurrent-edit conditions, interface failure and recovery. Since test authoring is the largest line in package effort, this is where the arithmetic of adoption is usually decided. See Test case generation.
What a human must decide. Whether the test actually proves the requirement, and whether the expected result is correct. Generated tests fail in a specific way: the steps are plausible and the expected result is subtly wrong, because the model inferred behaviour from documentation rather than from the configured system. A reviewer who knows the system catches this in minutes; a reviewer skimming for formatting does not. The reviewer also decides test depth against the approved risk rating.
What an inspector will want. Approved protocols with an identified author and approver, complete traceability to requirements, and coverage proportionate to risk. Also — increasingly — whether the same person authored and approved. Independence of review is a control an inspector can check from the metadata alone.
Test execution
What AI can do. Less than the rest of the lifecycle, and that is the correct answer. Automated execution of scripted tests is well-established, and the tooling that drives it is deterministic automation, not a generative model — which matters, because a deterministic script produces the same result on the same input and can therefore be qualified. AI is genuinely useful around execution: summarising failure patterns across a run, drafting the initial deviation write-up from the failure evidence, and identifying which other tests share a root cause with a failure.
What a human must decide. Pass or fail, every time. The disposition of every deviation — defect, test error, environment issue, acceptable-as-designed — and whether the failure has implications beyond the test that caught it. A drafted deviation write-up is a starting point for an investigation, never its conclusion. Our inspection readiness guide covers how these dispositions read to an inspector months later.
What an inspector will want. Executed protocols with attributable results, contemporaneous timestamps, retained raw evidence, and deviations with real dispositions and named approvers. Where tests were automated, they will want the qualification evidence for the automation tooling itself — our guide to GxP test automation covers that, and it is the step most teams skip.
Traceability, periodic review and revalidation
What AI can do. Traceability is the second-strongest use case after requirements drafting, because the work is mechanical reconciliation across records that already exist. A live matrix derived from current requirements, risks, tests and results — rather than a spreadsheet rebuilt by hand after each change — eliminates the reconciliation pass and, more importantly, eliminates the window where the matrix is silently wrong. See Live RTM and the live-versus-static RTM comparison.
For periodic review, AI can assemble the review pack: change history since the last review, deviation and incident records, user access changes, supplier status changes, and a flagged list of changes that plausibly affect the original risk assessment. For revalidation after a change, it can draft the impact assessment — which requirements the change touches, which tests are therefore in scope — and regenerate the affected test scripts.
What a human must decide. Whether the system remains in its validated state. That is a quality conclusion, and the fact that an assembled review pack shows nothing alarming does not make it. The human also decides revalidation scope: the drafted impact assessment is a proposal, and a reviewer who knows the system will regularly extend it to something the change record did not obviously touch.
What an inspector will want. A traceability matrix that reconciles against the current state of the system, not the state at initial release; periodic review records with an approved conclusion and named approver; and, for each change, a documented impact assessment and the revalidation that followed from it. Change controls and Audit Readiness cover the mechanics.
The hard boundary: what AI may not decide
EU GMP Annex 22 draws a line that does not move: an adaptive or generative model may not make a GMP-critical decision. Static, deterministic, validated models can be used for defined purposes within their qualified scope. Models whose behaviour is not reproducible — which includes every large language model in ordinary use — may support work, but the decision remains with a qualified person.
In validation terms, the decisions on the wrong side of that line are: whether a system is fit for intended use; a GAMP category assignment; any risk rating; pass or fail on a test; the disposition of a deviation; whether residual risk is acceptable; whether a system remains in a validated state; and approval of any deliverable. None of these may be made by a generative model, and no configuration setting, sign-off delegation or internal policy can authorise it.
The correct architecture follows directly: the model produces drafts, the drafts are inert until a qualified person approves them, and the approval is what carries regulatory weight. This should be enforced in the system rather than in a procedure — a platform where the AI-drafted risk rating is simply the default value in an editable field, approved by the same click that approves everything else, is not implementing the boundary no matter what the SOP says. Annex 22 assurance and EU Annex 11 & Annex 22 readiness cover how this is enforced structurally, and AI governance covers the governance framework around it.
What human-in-the-loop means operationally
"Human-in-the-loop" is used often enough as a compliance slogan that it has lost most of its meaning. Operationally it is four specific properties, and a system either has them or it does not.
- The reviewer can see what they are approving and where it came from. Every AI-drafted element carries its source — which document, which configuration export, which requirement it was derived from. A reviewer who cannot check a draft against its source is rubber-stamping, and the provenance record is also the evidence that makes the review defensible.
- The reviewer is qualified and independent. Documented training on the procedure and the system, and not the same person who initiated the draft where the deliverable requires independent approval. Both are checkable from system metadata, and both get checked.
- Rejection is a real and recorded path. If your audit trail shows a 100% approval rate across hundreds of AI-drafted deliverables, the loop is not functioning, and an inspector will read that number exactly the way you would. Edits and rejections should be visible in the record, and their frequency is a useful internal health metric.
- Nothing takes effect before approval. The draft has no regulatory status until a qualified person signs it. Not a lower status — none. This has to be structural: an unapproved draft should not be able to flow into a downstream deliverable, appear in a traceability matrix, or be exported as evidence.
These four properties are what GxP Copilot implements: every deliverable drafted with its provenance attached, gated behind a qualified reviewer, with the approval — not the generation — recorded as the controlled event. why human-in-the-loop can't be a footnote argues the case at more length, and Human-in-the-Loop reviews covers the review workflow.
The net effect across the lifecycle is narrower than the marketing and more valuable than the scepticism. AI compresses the drafting and reconciliation work, which is the majority of the hours. It does not touch the judgment, which is the majority of the value and all of the regulatory weight. A validation practice that internalises that split gets faster without getting thinner. One that blurs it gets an inspection finding that is very hard to argue with. For the wider picture see the GxP AI hub and our GxP software overview, or book a demo to see the gated workflow on one of your own systems.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
