Navata
← All Library

Validation & Evidence

What Verification Is Needed Before Relying on AI-Drafted Test Scripts and Acceptance Criteria as GxP Validation Evidence?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 18 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

This is a different question from whether automated execution can generate validation evidence, and different again from whether AI-generated text may become a controlled GxP record in general. Here the AI is not executing a test and it is not producing the deliverable itself. It is authoring the test design artefact, the script, the acceptance criterion, the expected result, that a human or a machine will later execute. If that authored artefact is wrong, incomplete, or subtly misaligned with the approved requirement, every test run against it produces confident, well-documented, wrong evidence.

Know what the tool is actually good at

Current industry experience with AI-assisted test generation is consistent on one point: these tools are strongest on the ordinary, well-trodden path, and weakest on negative testing, domain-specific business rules, and judgement calls about whether a behaviour is actually correct for the regulated process, rather than merely technically functional. Treat any specific coverage percentage quoted for a given tool as a vendor- and moment-specific snapshot rather than a stable industry figure; the durable pattern worth planning around is the shape of the gap, not a number that will read differently a year from now.

Treat that as a starting assumption about where reviewer effort belongs, not as a licence to skip review of the parts the tool is reportedly good at. An AI tool that reliably drafts the happy-path script can still get the expected result wrong if it infers the expected behaviour from a system's apparent behaviour rather than from the approved requirement.

Anchor every AI-drafted artefact to the approved requirement, not to system behaviour

The single most important reviewer check is whether the AI-drafted script or acceptance criterion actually traces to an approved requirement, as described in How to Write Testable Requirements and Acceptance Criteria for a GxP System, rather than to an inference about what the system currently does. A drafting tool given access to the system, its documentation, or prior test scripts can produce a fluent, plausible test that faithfully describes existing behaviour and never surfaces that the behaviour itself is wrong or undocumented.

For every AI-drafted item, the reviewer should be able to point to the specific requirement or risk it tests, not just judge whether the script reads sensibly. Where no clear requirement exists for something the AI has tested, that is a finding about the requirement set, not a reason to keep the test.

Give negative, boundary and business-specific scenarios extra scrutiny

Because AI-generated coverage concentrates on standard paths, deliberately audit AI-drafted test sets for the categories most likely to be thin: rejected inputs, permission failures, concurrent or out-of-sequence actions, boundary values, and rules that depend on domain-specific business logic rather than generic software behaviour. Where an AI tool has been used to draft an entire test set, require an explicit statement of which negative and exception paths were included and which were added by a human reviewer afterwards, rather than assuming the set is complete because it is large.

Record what the AI produced, what changed, and why

Two things need retaining, and they are not the same obligation. The accepted artefact, the version a human reviewer actually approved for execution, needs a record of what the AI produced, what the reviewer changed, and why, in the same way When Can AI-Generated Text Become a Controlled GxP Record? requires provenance and acceptance evidence before generated text becomes authoritative. A test script or acceptance criterion is exactly the kind of GxP record that framework already covers; this reference applies it specifically to test-design artefacts rather than restating it. This does not require a line-by-line diff, but it does require more than a generic statement that "AI assistance was used": a reviewer who corrects an AI-drafted expected result because it described current behaviour rather than the approved requirement has made a decision worth recording.

Whether every raw AI draft, including versions the reviewer rejected outright or rewrote from scratch, is separately retained is a different question, and one this reference does not settle generally. That is an organisational records-retention policy choice, not a fixed GxP requirement; what the validation record must contain is evidence of what was accepted and why, not necessarily a complete archive of every intermediate draft.

Do not let tool fluency substitute for reviewer competence

An AI-drafted script is often better written, more consistently formatted, and more complete-looking than a rushed human first draft, and that fluency is precisely what makes shallow review dangerous. A reviewer who is not independently competent to judge the requirement and the risk will find a well-formatted AI-drafted script harder to challenge than a rough human one, not easier. Assign review of AI-drafted test artefacts to reviewers who are competent to assess the requirement and risk and who exercise independent judgement, just as they would for human-authored test designs, and do not treat AI drafting as a reason to lower the reviewer's seniority or the depth of the review.

Use a risk-based lens on where AI drafting is acceptable at all

Current FDA computer software assurance guidance establishes the general principle that the assurance activity should fit the risk of the software function being assured; it does not name AI-drafted test artefacts or prescribe specific verification tiers for them. Applying that general risk-proportionality principle to this specific practice is a Navata practitioner recommendation, not something CSA itself mandates: a low-risk, easily reversible, non-critical function may need only confirmation that the AI-drafted script traces to its requirement and covers the obvious negative case, while a test protecting a critical GxP function, a required control, or an audit-trail behaviour, in my view, warrants full independent authoring or, at minimum, line-by-line reviewer verification against the approved requirement and risk assessment, not a spot check.

Sources