Article
Correct is not the same as defensible.
Why AI in GxP work needs structure before it needs more capability.
Article
Why AI in GxP work needs structure before it needs more capability.
I have written before that in our industry a result is not finished when it is correct. I want to explain what I mean, because it is the reason Verheim exists — and because it applies to every AI use in your organisation, whoever supplies the method.
General-purpose AI is already good at a great deal of GxP work. It reads large document sets quickly, turns a conversation into structured text, compares versions, and proposes test cases and risks a person might not think of. Many quality and validation teams have seen that for themselves. That part is real, and it is not the problem.
The problem is what happens next.
A GxP deliverable has to be correct. It also has to be defensible: someone who was not there — a reviewer, a successor, an inspector years later — must be able to see what was done, against which requirement, by whom and why, and reach the same conclusion. Quality systems are built to make that possible. Procedures, templates, defined roles, review and approval exist so that the work does not depend on remembering who did it and how. This is what a QMS is for: it makes quality something an organisation can show, not only claim.
You cannot defend a way of working that changes every time it is used. If two qualified engineers reach the same deliverable by two different routes, a reviewer can still judge each result — but nobody can say how the organisation does this work. If the route changes from one month to the next, the honest answer to an inspector’s simplest question — how do you do this here? — is “it depends who did it”.
That is where much AI use sits today. The method lives in a prompt. The prompt lives with the person who wrote it, differs from their colleague’s, and changes when they do. Unless someone has put it under control, nobody has reviewed it, and when the person moves on, it goes with them. The output may be excellent. The way it was produced is not something an organisation can stand behind.
Repeatable does not mean identical. Two good engineers will not write identical protocols, and an AI will not either. It means the same questions are asked, the same steps are taken, the same inputs are used and the same review is applied — so that the differences which remain are visible and can be explained.
A method becomes repeatable when it lives outside any one person: written down, owned, reviewed and changed under control. That is true for people, and it is true for AI.
Quality already has a simple test, and it was written for people. If you hired a validation engineer on Monday, you would not let them produce a single GxP deliverable until they had a defined role, documented training, an SOP for how the work is done here, a template for the output, a place in the project, and someone who reviews and signs. Your quality system exists to make sure of it. For a tool, the equivalent of that training is your own assessment and validation.
Your people now work alongside capable AI. So the question worth asking is whether that AI has the same working arrangements you would insist on for a person:
Where the answer is yes, the AI’s work can be reviewed against a defined method rather than reconstructed from one person’s prompt. A prompt library kept under your own document control, with an owner and a review, can pass this test too. Where the answer is no, the output may still be good — but its quality depends on who happened to be using it that day.
There is a second reason, and in GxP it may be the more important one. Your quality system assesses a computerised system against an intended use you define. That is far easier when the use is bounded by something you can inspect — a defined role, scope and method — than when it is whatever a user asks on the day. Your CSV team will rightly ask how the boundary is enforced, not only how it is described. Structure does not answer the intended-use question for you. It gives you something definite to answer it about.
Structure does not answer the intended-use question for you. It gives you something definite to answer it about.
Structure makes a method repeatable and reviewable. It does not make an output correct. It does not make a review real — a reviewer can still accept what they should have questioned. And it does not move accountability anywhere: the person who reviews and signs is exactly as responsible as before. No tool changes that.
This is the argument Verheim is built on, so read it knowing that. Our answer to it is standard professional roles — each with a defined scope and method, built for specific workflows, and adapted to a customer’s own procedures and templates — so that every person does not have to build their own. They do not remove your own assessment and validation, which still has to cover them, and they do not replace your review, your approval or your accountability.
The test above does not depend on us. Apply it to every AI use in your quality and validation work, including the ones you have built yourselves. The useful question is not how capable the AI is. It is whether you could defend how the work was done.
Klavs Esbjerg is co-founder of Verheim.
