Most pharmaceutical GenAI programmes are stuck in the same place: a successful pilot that cannot be put into production. The pilot worked, people liked it, and then somebody asked what happens when the output is wrong and the conversation stopped.
That is not a technology problem and it is not obstruction from Quality. It is the predictable result of piloting something without deciding in advance what it would take to deploy it. The governance questions do not get easier later; they get asked at a worse moment.
This is the sequence we use on GenAI adoption engagements, which is deliberately boring.
Pick a use case by its review characteristics
The usual selection criterion is where the most time is spent. That produces pilots on high-volume work, which is exactly where human review becomes impossible and the deployment stalls.
Better criterion: pick work where a qualified person can meaningfully check the output, and where checking it is faster than producing it. That is the whole test. If verifying the output takes as long as doing the work, there is no benefit regardless of how good the model is.
Document drafting passes this test well, which is why it is where real adoption has happened. A reviewer can read a drafted risk assessment against the source and judge it. Anything resembling a decision — a disposition, a causality assessment, a release — fails the test, because checking the decision means making it.
Write the intended use statement before building anything
This is the single most useful discipline available and it takes an afternoon. State what the system is for, what it is explicitly not for, what inputs it accepts, what it produces, who reviews the output, and what happens when it is unavailable.
The negative scope is the part that matters and the part teams skip. A system described only by what it does will be used for adjacent things that nobody assessed, because it appears to work on them. Writing down what it is not approved for converts that from an accident into a policy decision.
This document is also what makes validation possible. You cannot demonstrate fitness for intended use without a statement of intended use, and a great many AI pilots have no such statement, which is precisely why they cannot be validated. The AI intended-use statement covers how to write one.
Define acceptance criteria before you evaluate
The order matters. Criteria written after seeing results describe the results.
Decide what good enough means before testing: on what sample, measured how, at what threshold, and who judges. For a drafting use case the measure is usually the proportion of outputs a qualified reviewer accepts with no material change, plus an explicit limit on a category of error you will not tolerate at all.
That second part is important. An average accuracy figure hides the failure that matters. A drafting system can be acceptable on average and still produce an occasional fabricated reference, and a fabricated reference in a regulatory document is not an averaging problem. Define the unacceptable failure separately and test for it specifically. AI acceptance criteria and the AI validation test set go into the mechanics.
The fallback is not optional
Every deployment needs a working answer to one question: what happens to the regulated process when the AI is switched off.
Not a documented intention — a path people have actually used. If the only way the work gets done is through the AI, you have created a single point of failure in a regulated process, and both the draft EU GMP Annex 22 and plain operational sense point the same way.
The practical test is to run the fallback once, deliberately, before go-live, and record that you did. Organisations that skip this discover during an outage that the fallback requires a template nobody has maintained since the AI arrived.
Why pilots do not convert
Four reasons, in the order we encounter them.
- No intended use statement, so there is nothing to validate against and no way to scope the risk assessment.
- Acceptance criteria written retrospectively, which Quality correctly declines to accept.
- A review step that cannot work at production volume. It was fine for twenty documents a week and is nominal at four hundred.
- A model reached through a service that changes without notice, with no monitoring and no re-qualification trigger. This is the one teams are least aware of, because the pilot was stable. Model change and revalidation
All four are cheaper to address before the pilot than after it, and none of them is technically difficult.
A realistic first six months
Build the register of what AI is already in use, because there is more than you think and a governance model built without it governs an imaginary estate. Pick one use case that passes the review test. Write the intended use statement and the acceptance criteria. Evaluate against a held-out set. Deploy with a named review role, a monitoring measure with a threshold, and a fallback you have exercised. AI validation services is the practice that carries it.
Then do the second one, which will take a fraction of the time because the pattern exists. Resist running several pilots in parallel before one has reached production — parallel pilots produce several stalled proofs of concept and no operating model.
AI governance is the governance side, AI CoE is how we help structure the function, and book a demo if you want the first one taken through end to end.
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.
