Every AI programme eventually meets a person who is described as resistant.
They ask irritating questions. They want to know where the answer came from. They point out an exception. They say the workflow will not work in the real world. They do not look impressed by the demo, which is unfortunate because the demo has lovely gradients.
Sometimes they are protecting a comfortable old way of working. Sometimes they are worried about their job. Sometimes they just do not want to learn another tool.
And sometimes they are the only person in the room who understands what the work is actually for.
That distinction matters.
A demo shows the centre of the problem
Most AI systems look best in the centre of a task.
Give the model the ordinary customer request, the standard contract, the clean data, the familiar product question, and it can be very persuasive. It may be fast. It may be useful. It may even be right.
The experienced person often lives at the edge.
They know the customer whose history changes the answer. The regulation that appears only in a rare case. The strange exception that becomes expensive if mishandled. The bit of context nobody writes down because everyone in the team has quietly learned it over years.
That can make expertise look like pessimism. The expert keeps saying, “Yes, but what about…?” while the rest of the room is enjoying the future.
But “what about?” is often the work.
Resistance is not one thing
Treating all reluctance as a skills gap is intellectually lazy. It lets leaders avoid the harder diagnosis.
Is the person worried about quality? That may be a request for better evidence.
Are they worried about accountability? That may be a request for clear decision rights.
Are they worried that the tool will make them easier to monitor or replace? That may be a request for an honest conversation about power, not a better prompt-writing course.
Are they worried that a new workflow will remove the human contact through which they spot problems? That may be a design issue.
Or are they simply attached to doing the work the old way? Fine. That is also information. But it is not the only explanation, and it should not be the default one.
Research on workplace adoption keeps finding that trust is built through concrete things: checking sources, comparing systems, asking colleagues, understanding when a tool is and is not reliable. It is not built by announcing that adoption is now a mindset. Qualitative study of a multinational workforce
The distinction is important because a company that suppresses informed skepticism does not become more innovative. It becomes worse at noticing the difference between a useful tool and a polished mistake.
The people closest to the work should design the challenge
There is a better role for the skeptic than “blocker.”
Ask them to help define the cases where the system must not be trusted. Ask what a plausible but damaging answer looks like. Ask which exception would never appear in a training deck. Ask what they would need to see before they would put their name behind the output.
This is not an invitation to let every expert veto every change. Expertise can become territorial. Any organisation that has tried to replace a spreadsheet knows that.
It is an invitation to make resistance earn its place as evidence.
The test is simple: can the concern be turned into a condition the system must satisfy, a boundary it must respect, or a risk the team must consciously accept?
If yes, it belongs in the design.
If no, perhaps it is fear. Perhaps it is habit. Perhaps it is still worth hearing, because people do not need to be technically correct to tell you that a change has made their work feel smaller.
The goal is not unanimous enthusiasm. That is usually a bad sign anyway.
The goal is a system that survives contact with the people who know where it will break.