The organisations getting AI wrong aren’t short of technologists. They’re short of leaders willing to treat AI adoption as a judgement problem rather than a procurement problem — and the judgement part requires no code at all.
There is a peculiar abdication happening in senior teams right now. Leaders who would never sign off a new market entry without interrogating the strategy will approve an AI initiative on the strength of a supplier demo, because the technology feels like someone else’s department. It isn’t. Every consequential question in AI adoption — where it should be used, what risk is acceptable, who is accountable when it errs, what happens to the people whose work changes — is a leadership question. The code is the easy part, and someone else really can do that. The judgement cannot be delegated.
The most reliable predictor of a failed AI initiative is that it started with the technology. A team acquires a capability, then goes looking for somewhere to point it. Flip the sequence. List the places where your organisation is slow, inconsistent, expensive or blind — the backlog that never clears, the decisions that vary wildly by who makes them, the information nobody can find. Then ask, narrowly, whether current AI is actually good at that class of problem. Sometimes it is. Often the honest answer is that your problem is a process problem or an accountability problem wearing a technology costume, and automating it would simply produce the same mess faster.
A real pilot has three things most AI pilots lack: a defined decision it exists to inform, success measures agreed before it starts, and a pre-committed willingness to kill it. “Let’s try it and see” is not a pilot; it’s a way of adopting something without ever deciding to. Set the bar in advance — what accuracy, what time saved, what error rate, measured against what baseline — and write down what result would mean stopping. Leaders who do this discover something useful either way: a pilot that clears a pre-set bar earns genuine organisational confidence, and one that fails cheaply has saved you the expensive version of the same failure.
“Let’s try it and see” is not a pilot. It’s a way of adopting something without ever deciding to.
The moment an AI system starts touching customers, citizens or staff decisions, you need answers to questions that no vendor will volunteer: who is accountable for the system’s outputs, what data it may use, how errors are detected and corrected, where a human must stay in the loop, and how you would explain a decision it influenced to the person affected. This is not box-ticking — regulation from the EU AI Act to UK data-protection law is moving this way, but the deeper reason is trust. An organisation that cannot explain its own automated decisions will eventually be asked to, in public, at the worst possible moment.
People do not resist AI because they misunderstand it. They resist it because they understand precisely what unmanaged automation has historically meant for people like them. If the workforce story is an afterthought, quiet non-adoption will kill the initiative more surely than any technical fault: the tool gets rolled out, workarounds bloom, and a year later usage statistics tell the real story. Address the anxiety directly — what changes, what doesn’t, what people will get help learning — and involve the people who do the work in redesigning it. They know where the tool will actually break.
None of the above requires technical depth. It requires the discipline to ask plain questions and decline vague answers — the same discipline good leaders apply everywhere else, applied to a domain that has been allowed to feel exempt. The leaders who navigate this well over the next few years won’t be the ones who learned to code. They’ll be the ones who kept making leadership decisions when everyone around them was mesmerised by the technology.