Most arguments about AI in validation go badly because they compress three different jobs into one word. "Can AI do the testing?" is unanswerable. Split it and it becomes three questions, two of which are easy.
Writing a protocol, approving it, and executing it are separate acts with separate regulatory weight. Keep them separate in the architecture and the compliance story mostly writes itself.
Drafting: the job AI is genuinely good at
Turning a requirement into a set of test steps is a translation task with a house style. It is repetitive, it rewards pattern-matching across hundreds of prior protocols, and being wrong is cheap because a person reads it next. That is close to an ideal use.
What matters is what the draft is grounded in. A model writing from the requirement, the system's own screens and your existing approved protocols produces something a reviewer edits. A model writing from its general sense of how validation documents look produces something a reviewer rewrites — and quietly teaches the team to skim.
Judge this the same way you judge any draft: what proportion survives review unedited, and does that proportion hold when the requirement is unusual.
Approving: the job that must stay human
This is the decision with regulatory consequence, and it belongs to a named, qualified person. EU Annex 11 & Annex 22 compliance is explicit that an adaptive or generative model may not be the thing that decides a GMP-critical question, and approving a protocol is exactly such a decision.
It follows that approval has to be a real review, not a formality — which in turn constrains the draft. A protocol an approver cannot fully understand is one they cannot meaningfully approve, which is the practical argument for a closed vocabulary of test steps: every step says what it will do in terms a quality reviewer can evaluate without reading code.
Record the approval as an electronic signature under FDA 21 CFR Part 11 compliance, against the exact version approved. If the protocol changes afterwards, the signature does not carry.
Executing: the job with no AI in it at all
This is where most designs go wrong, and the correction is simple: nothing about the run should involve a model. The approved protocol is a specification, and the engine executes it deterministically — same input, same steps, same result.
Two consequences, both good:
- A run is reproducible. Re-execute the same approved version and you get the same outcome. If you do not, something about the system changed, which is the thing you wanted the test to tell you.
- The model is out of the evidence chain. Nobody has to reason about model drift, temperature, or version at execution time, because the model was not there.
Put plainly: AI at draft time is a productivity question. AI at run time is a validation question you do not need to take on.
Writing it down so it survives review
The separation only counts if a reader can see it. In the validation plan, state which of the three roles AI performs, and say explicitly that it performs none of the others.
A sentence that does the job: "Draft protocols may be generated with AI assistance. Every protocol is reviewed and approved by a qualified person before execution. Execution is performed by a deterministic engine; no model is invoked at run time."
That is three lines, it is checkable against the system, and it answers the question an inspector was going to ask anyway. See AI validation services for where this fits in a wider AI validation approach.
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.