Inspectors are not hostile to automation. In our experience they are mildly relieved by it — automated evidence tends to be more consistent than the handwritten kind, and it does not have gaps where somebody got busy.
What they object to is evidence they cannot follow. The questions below are the ones that come up, and each has a good answer if the system was built with them in mind.
"Show me the protocol that produced this result."
The opener, and it is a trap only if your results reference a protocol by name rather than by version. Revise a protocol after a run and the name now points at something that was never executed.
A good answer pulls up the exact approved version, its signature, and the run that used it, in that order. If getting there involves a spreadsheet mapping run IDs to document revisions, the follow-up questions will be harder.
"Who approved this test, and what did they see?"
The second part is the real question. An approval signature against a protocol that reads run: verify-all.sh is a signature against a filename — and that is the moment a closed vocabulary stops being an architectural preference and starts being the answer to an inspector.
What you want to be able to say: the approver saw every step in the terms you are reading now, because there is no layer underneath them.
"How do you know the tool reports failures correctly?"
This is the question teams are least ready for, because all their evidence is of things passing. The answer is a negative test set — deliberately failing tests that the tool must report as failures — run as part of tool qualification and re-run on version change.
It takes a day to build and it converts a difficult question into a short one. More on the scope in qualifying the tool itself.
"What happened to this failed run?"
They will find one. A system with no failed runs looks less credible, not more, and an inspector who sees only passes will start wondering what happened to the rest.
The good answer is a closed loop: the failure, the investigation, the conclusion, and the deviation if there was one. The bad answer is a failed run followed by a passing re-run and nothing in between — see why a passing re-run is not an explanation.
"Is AI involved in this?"
Increasingly common, and it is a fair question rather than a hostile one. The answer is much easier if the three roles were kept apart from the start: AI may have drafted the protocol, a named person approved it, and a deterministic engine executed it with no model involved at run time.
That sentence answers the question completely, and it is checkable. See the three roles and AI validation services.
"Can it reach production?"
The last one, and the shortest. "No — it is configured to reach these hosts, here is the configuration" ends the line of questioning. "It could, but our procedure says not to" opens a longer one about how that procedure is enforced. Configured reach is a much easier thing to defend than a rule.
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.