Every AI programme in a regulated company meets the same wall, and it is usually in the quality function. The common response is to call it a culture problem and book training.
That diagnosis is wrong, and acting on it makes things worse. The resistance is mostly rational, and it is pointing at something real.
What they are actually objecting to
"I will be the one explaining this to an inspector." The person whose name goes on the approval carries the consequence of a decision someone else was excited about. That is not fear of technology; it is an accurate reading of where accountability sits.
"Nobody could tell me how it reached that answer." Quality professionals are trained to require evidence. A confident output with no traceable basis is, correctly, something they distrust.
"We were told the last system would save time too." Many have lived through an eQMS implementation that promised efficiency and delivered more clicks. That memory is data.
"If it drafts and I approve, what exactly am I approving?" The sharpest objection, and the one most worth taking seriously. Reviewing generated work is genuinely different from reviewing a colleague's, and pretending otherwise insults their judgement.
Arguments that don't work
- Cost savings. The quality function is not measured on cost. Leading with efficiency tells them the project's purpose is to do less quality work, which is precisely their worry.
- "Everyone is doing it." In an industry built on independent verification, this is an anti-argument.
- Vendor demos on clean data. A quality reviewer's instinct is to ask what the demo did not show. They are right.
- Executive mandate. Produces compliance in the weakest sense: the system gets used, the reviews become rubber stamps, and you have built automation bias into your quality system on purpose.
What actually changes minds
Put them in control of the scope. Let QA write the intended use statement, including the "must not" list. People defend what they helped define, and the resulting scope is usually better — they know which decisions are dangerous.
Show it being wrong. The single most effective demonstration. Run it on genuinely difficult real documents in front of them, let it fail, and discuss the failure. Trust comes from seeing the failure mode, not from seeing success.
Answer the inspector question directly. Walk through what you would show: the intended use, the risk assessment, the test set, the review record, the audit trail. If that walk-through is thin, their objection was correct and the project is not ready — see what inspectors ask about AI.
Start where a mistake is cheap. Not the release decision. Something where wrong output is obvious and recoverable, so the first experience of failure happens somewhere safe.
Measure review quality, never review speed. The moment throughput becomes the metric, you have built an incentive against the control the whole design depends on. See SOPs and training for AI.
When the resistance is correct
Sometimes the right answer is that they are right and the project should stop. If the output cannot be traced to a source, if nobody can describe how a reviewer would detect a wrong answer, if the proposed workflow quietly removes an approval step — those are design faults, and the quality function is doing its job by blocking them.
A programme that cannot survive informed scepticism from its own QA function will not survive an inspection either. Treating that scepticism as the first real test, rather than as an obstacle, is both the honest framing and the one that gets you a system worth having.
Related: running a 90-day pilot and GxP AI.
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.