The Demo That Never Ends: UK Boards Need a Kill Switch for AI Pilots

There is a sentence that has become the soundtrack of the UK boardroom over the past few years. It goes something like this: 'The pilot is going well, so we are extending it for another quarter to gather more data.'

Everyone nods. Nobody asks what would have to be true for the pilot to be declared a failure, because nobody wrote that down at the start. And so the experiment enters its ninth month, still being described in the present continuous, still not doing anything.

How organisations end up here

Pilot purgatory is rarely the result of stupidity. It is usually the result of a reasonable-looking shortcut taken at kickoff.

Success is never defined in numbers. The objective is to 'explore the potential of AI in the claims process', which is not a target, it is a mood. Six months later the team presents usage figures and positive feedback, both of which are true and neither of which answers whether the thing works.

Failure is never defined at all. Naming a kill criterion feels pessimistic in a kickoff meeting, so it gets left out, and then nothing can ever formally fail. The pilot can only be extended or quietly forgotten, and forgotten looks bad in the board pack.

Nobody budgeted for the boring part. The licence is funded. The change management is not, because the assumption was that the tool does the work. It does not. Someone has to redesign the process, train the team, rewrite the guidance and answer the same question forty times in the first month — and that someone was never allocated.

And procurement did its job a little too well. A pilot that sits under the threshold requires less scrutiny, which is exactly why so many pilots are sized to sit under the threshold. The threshold becomes the strategy.

What it costs

Pilot purgatory is expensive in three currencies, and only the first one shows up in the finance report.

There is the direct cost: licences, integration work, data science time, the internal meetings that multiply around anything with the word 'AI' in the title. This is usually smaller than people fear.

Then there is the credibility tax. By the third quarterly update that sounds identical to the first, the board stops listening, the finance director starts asking pointed questions and the executive sponsor quietly stops mentioning it in their own updates. You have spent political capital and bought nothing.

Then there is the human cost, which is the one that hurts longest. Staff who gave up time to test something, restructured their week around it, and then watched it evaporate learn a very specific lesson: that these initiatives are theatre, and volunteering for the next one is a poor use of their attention. Good luck running change in that team next year.

Why we keep doing it

Because a pilot is politically safe in a way that a decision is not. Scaling is a commitment with a budget and a name against it. Stopping is an admission. Extending is neither, and it lets everyone remain enthusiastic without allocating anything.

There is also the comparison problem. When every peer organisation claims to be doing something with AI, the pressure to have a programme becomes stronger than the pressure to have a result. A pilot satisfies the requirement to be seen doing something while deferring the requirement to prove it.

None of this is an argument against experimenting. Pilots are the correct way to test something uncertain. The argument is against pilots that are structured so they can never conclude.

The exit framework: scale, stop or rework

The fix is unglamorous and takes about a page. Agree it before anyone signs a licence.

Name the number. One business metric, a baseline, a target and a date. 'Reduce average claims handling time from nine days to six by the end of March.' If you cannot name the number, you are not ready to pilot — you are ready to research.

Write the kill criterion. Something like: if adoption among the pilot group is below 30 per cent by week eight, we stop and write up why. Say it out loud in the kickoff. It is the single most clarifying sentence in the room.

Fund the change, not just the tool. Hours and money set aside for process redesign, training and comms. If that line is zero, the pilot is already scheduled to fail quietly.

Name the decider. One person with the authority to stop it, not a steering committee that meets monthly. Committees extend; people decide.

Plan the day after. What happens to the data, the model, the licence and the workflow if the answer is stop? If nobody knows, the default answer will be to keep it running.

The three questions at the end

When the date arrives, put three questions to the room.

Did it move the number? Would anyone notice if we switched it off on Monday? Can we run it without the pilot team in the room?

Yes, yes, yes means scale — with an operational owner, a real budget and a place in the standard process. It moved the number but nobody can run it without the original team means rework, with a named change lead and a hard deadline. It did not move the number means stop, and write two paragraphs on what you learned so the next team does not repeat it.

Make stopping respectable

Here is the cultural bit that UK organisations find hardest. Stopping needs to be a normal, respected outcome, not a career risk. Keep a visible log of things that were tried and did not work. Say so at board level in the same tone you use for wins. Treat the pilot budget as a portfolio where some bets losing is the expected cost of finding the ones that win.

A pilot that never ends is not innovation. It is a subscription with a slide deck, and it is being paid for by the people who were told their ideas would be taken seriously.