Before You Switch It On, Write the Switch-Off: Rethinking How UK Firms Run AI Pilots

There is a particular kind of project that has become familiar in UK businesses over the past few years. It began as a twelve-week experiment, sponsored by an enthusiastic director, staffed by a small team and celebrated in an internal newsletter. Eighteen months later it is still running. It has a Slack channel, a monthly cost line, a part-time owner and no end date. Nobody can say with confidence whether it works, but nobody is willing to switch it off either.

This is not a technology failure. The models generally do what they were asked to do. It is a governance failure, and it is remarkably common because the incentives of a pilot are almost entirely toward continuation.

The pilot that outlives its purpose

Pilots are designed to be cheap to start and expensive to stop. Starting requires a sponsor, a budget small enough to approve without debate and a supplier willing to run a proof of concept on favourable terms. Stopping requires someone to declare that a visible initiative, often associated with a named senior person, has not delivered. That asymmetry explains most of the pattern.

The result is a portfolio of quiet permanent commitments: a document-processing assistant used by three people, an automation that duplicates a workflow the operations team already handles, a chatbot whose usage statistics are measured but never interpreted. Individually they are modest. Collectively they consume licence fees, integration maintenance, security review capacity and the scarcest resource in any SME — management attention.

Four mechanisms that keep a pilot alive

Sunk cost reasoning. Money already spent becomes an argument for spending more. The pilot's original budget is treated as an investment to protect rather than a completed test.

Metric drift. Because no measure was fixed at the outset, the team reports whatever looks favourable: conversations handled, hours saved in theory, satisfaction scores from a friendly user group. Activity is substituted for outcome.

Ownership ambiguity. The pilot sits between IT, operations and a business unit. Nobody holds the decision rights to end it, so the default — continuation — prevails.

Renewal physics. Commercial terms do much of the work. A trial converts to a paid subscription on a notice period nobody diarised, and the decision to stop becomes a procurement problem rather than a management one.

What a kill switch actually is

A kill switch is not a pessimistic gesture. It is a written commitment, made while everyone is still optimistic, about the conditions under which the work stops. It has three components and all three are necessary.

Named metrics, with a baseline

A pilot needs one primary measure and, at most, two secondary measures, each with a baseline captured before the trial begins. "Reduce invoice processing time" is not a metric. "Reduce median invoice processing time from 4.2 working days to under 1.5, measured over the final four weeks of the trial" is. The baseline matters more than the target: without it, the improvement claim can never be tested.

It is also worth naming a guardrail metric — the thing that must not get worse. Accuracy, complaint volume, security exceptions or staff escalation rates are common choices. A pilot that hits its efficiency target while doubling error rates has failed, and the charter should say so in advance.

A fixed review date with a fixed decision

Set the date before the pilot starts, put it in the calendar of the person who can actually stop the work, and make the decision binary at that meeting: scale, extend with a written justification and a new end date, or stop. "Extend" should be permitted once, not indefinitely, and any extension should require a change to the design rather than simply more time.

A useful discipline is to hold the review even if the pilot is going well. The point is to make continuation an active decision rather than a passive one.

A pre-agreed answer to failure

This is the part most often skipped. If the pilot does not meet its metrics, what happens to the data, the integration, the licence, the staff time and the supplier relationship? Answering those questions at the start is straightforward. Answering them at month fourteen, with a renewed annual contract and a team that has reorganised around the tool, is not.

A one-page pilot charter

A workable charter fits on a single page and takes under an hour to complete. It should cover:

• Problem statement: the specific operational problem, in one sentence, with the current cost or time impact quantified.
• Hypothesis: what the tool is expected to change, and by how much.
• Primary metric and baseline: as above, with the measurement method named.
• Guardrail metric: the measure that must not deteriorate.
• Scope boundary: which users, which data, which processes are in and out.
• Duration and review date: a calendar date, not a duration in weeks.
• Decision owner: one named person with the authority to stop the work.
• Exit plan: data deletion or return, integration removal, licence termination notice, staff redeployment.
• Spend ceiling: the total cost, including internal time, beyond which a fresh approval is needed.

Two supporting practices make the charter stick. First, agree the commercial terms with the supplier before the pilot begins — notice periods, data-processing terms and what happens at conversion. A pilot that converts automatically has already surrendered the exit. Second, record the charter somewhere the finance team can see it, so the cost line is tied to a decision rather than an assumption.

Clarity is the cheapest risk management available

The argument for this rigour is not bureaucratic. It is financial. A one-page charter costs an afternoon. An unexamined pilot that runs for three years costs licences, integration upkeep, security reviews and, most expensively, the opportunity to have spent that attention on something that worked.

AI adoption in UK SMEs will be judged less on how many experiments were started than on how decisively the unsuccessful ones were ended. Designing the switch-off at the same time as the switch-on is the simplest way to make that possible — and it is the kind of clarity that a modern business can put a price on.