“Validation, not AI”: what the pushback gets right

The most useful sentence I heard this quarter came from a Head of Quality who had just sat through her fourth AI vendor pitch of the month: “I need validation, not AI.” She meant an order of operations, and she had it the right way round. I have spent the last few years putting AI into live GxP processes, so you might expect me to argue with her. I mostly want to agree with her, carefully, and then push on the one place the phrase goes wrong.

What do people mean by “validation, not AI”?

When quality and validation leaders say “validation, not AI”, they are usually reacting to two years of pitches that treat GxP evidence as a detail to sort out after the sale. The phrase is shorthand for a position: the evidence discipline comes first, the technology second, and a tool that cannot survive an inspector's questions has no place in a regulated process, however clever the model behind it.

The frustration behind it is earned. The pitches this Head of Quality had been sitting through shared a shape I now recognise from a distance: a demo that works beautifully on curated data, a slide asserting the product is “GxP compliant” as if compliance were a property of software rather than of your use of it, and silence on the questions that decide whether the thing can go live. What is the intended use, precisely? What risk tier does it sit in? What does the validation package contain, and who maintains the evidence once the model is in production? A vendor who cannot answer those is selling you an inspection finding with a subscription attached.

Quality leaders are also finding AI in places they never approved. A model arrives inside an eQMS upgrade, or a data science team builds a classifier that operations quietly starts trusting, and the validation conversation begins after the dependency already exists. Anyone who has had to retrofit evidence onto a live system understands why the phrase has an edge to it.

Why do AI systems fail in regulated environments?

They fail on evidence far more often than on capability. The model usually performs. What tends to be missing is a written intended use, a risk tier, acceptance criteria that make sense for a probabilistic output, and monitoring that notices drift before an inspector does. An inspector examines your control of the algorithm, and control is exactly what the late-stage scramble fails to demonstrate.

A few failure patterns come up again and again. Acceptance criteria written for deterministic software get applied to a model that is right 94% of the time, and the project stalls because nobody agreed in advance what an acceptable error profile looks like or who reviews the misses. A vendor's model sits behind a boilerplate compliance statement, and when a question arrives about training data or change control, the answer is a shrug wearing a certificate. And after go-live, the model that was validated in March drifts quietly through September with no owner, no periodic review, and no threshold that would trigger one.

None of this is exotic. Intended use, risk assessment, evidence sized to risk, and controlled change have been the spine of computerised system validation for decades. The draft Annex 22 (which drew around 1,300 comments in its late-2025 consultation) and FDA's Computer Software Assurance guidance, finalised in February 2026, extend that spine to AI rather than replacing it. The regulators are asking validation questions. Organisations fail with AI when nobody in the room is fluent in answering them.

Does choosing validation mean saying no to AI?

No, and this is where the phrase, taken literally, starts to cost you. The strongest AI deployments I have seen were led by validation thinking from the first design conversation. In my own work I have deployed 20+ AI tools in live GxP, validated 4 AI applications (deviations, queries, and CAPA support among them), and taken 3 through health-authority inspection with zero compliance observations. The discipline the pushback defends is the same discipline that made those deployments possible.

Read as a verdict on the technology, “validation, not AI” quietly commits you to hand-processing deviations and queries your competitors will be triaging automatically within a few years. Read as a sequencing instruction, it is simply correct: validation first, then AI, and the AI earns its place tier by tier. The live choice in front of most organisations is between AI adopted under governance and AI that seeps in without it, because the second kind is already happening whether you approve it or not.

What should you do with the pushback in your organisation?

Treat it as a gift. The sceptics in your quality function are describing the control framework your AI programme needs, and they will become its best owners if the sequencing respects them. Four moves capture most of it. Write the intended use before anyone evaluates tools, in one page, in operational language. Tier the risk before the pilot, so the effort matches the exposure. Size the evidence to the tier: some AI needs no more than vendor evidence and a risk note, and a partner or platform that quotes a full package for everything is billing rather than thinking. And before go-live, name the owner, set the drift thresholds, and decide what triggers re-verification, because a model's assurance has to be maintained and drift doesn't announce itself.

Keep humans on the GMP decisions until your evidence, and your inspector, say otherwise. That single design choice keeps most early AI in the lower risk tiers, which is where an organisation should learn.

Sachin Bhandari runs Trust Bridge Compliance, a senior-led advisory for AI in GxP, CSV to CSA and digital validation in pharma, biotech and CDMOs. The sequencing argued here is worked through in full in Validating AI in GxP: A Practitioner's Guide, and the AI Governance Stack explainer is free to download. If you want to know where your own organisation stands before anyone pitches you anything, the free AI-in-GxP Readiness Index takes about 7 minutes.