The phrase “status quo bias” turns up in almost every AI rollout I have watched from the inside. A consultant reaches for it within the first week, usually to explain why staff on the shop floor, in customer service or in administration are not cheering for the new system. The explanation is tidy: people resist change because of a cognitive pattern, a mental shortcut borrowed from behavioural economics, and the pattern has a name. Once it has a name, the consultant files the objection away. Nobody has to answer it.

I have watched the same consultants apply a different standard to themselves. Ask them to run a draft, an analysis or a strategy paper through an AI tool and a good number decline, because the output is not good enough yet. They are sceptical of the technology in their own domain, and that scepticism earns them credit for judgement.

Put the two side by side and the asymmetry is plain. An employee who doubts a new system gets a diagnosis. When a consultant doubts the same category of tool, the employer calls it good judgement. The behaviour is identical: a person with direct experience of a task decides that a piece of software is not yet good enough to trust with it. Only the label changes, and it follows the position of whoever is doing the judging.

What the shop floor knew

I have had more than enough occasion to watch this play out on real projects, in digitisation, transformation and automation work. The pattern repeats. Someone on the shop floor, in customer service or in administration says the new process will not work as designed. The project flies in a consultant to explain that this is resistance, and to manage it.

Two years later the administrator turns out to have been right. The process the project wanted to automate had dependencies that never showed up in its diagram, and the customer system behaved differently from its own documentation. Exceptions the project plan had treated as rare turned out to happen daily. The administrator knew all of this before the project started, and said so at the time. The consultant filed what they said as resistance, then as bias. It was a working description of how the system actually behaved, and it cost the project two years to catch up with it.

A term doing work it was not built for

“Status quo bias” is a concept from behavioural economics, describing a measurable tendency to prefer things as they are. Applied to one worker with one objection about one system, it stops being a measurement and becomes a label. It does not ask what the objection contains, or whether the person raising it has seen exceptions the model has not. The label ends the conversation before it starts, and does so under the cover of a scientific-sounding word.

Here is a fair test. If a consultant defends their own reluctance to trust an AI draft as a professional call, the same right belongs to the warehouse worker who says the AI-driven inventory forecast does not match what actually happens on the floor. That worker is reporting a finding the model does not have, drawn from watching the same shelves every day.

Scepticism as a hypothesis

An organisation that took this seriously would treat the objection as an input: a hypothesis to test. “This will not work” is a claim, and a claim can be tested, confirmed or disproved. That requires asking what the sceptic has seen that the model has not, and running the comparison before the rollout. Most organisations skip that step: they explain the resistance instead of testing it.

Consultants can afford their own scepticism about AI output. They sit at a desk, review a draft and decide the tool is not there yet, and their employer pays for that judgement. The people whose objections a consultant files under status quo bias mostly work at the sharp end of the process a consultant is paid to redesign, and that position does not come with the same licence to doubt. Until it does, the shop floor keeps its findings to itself, and the project spends two years finding out what the administrator already knew before it started.