The pilot with no exit

Definition. A pilot with no exit continues to consume time and money while nobody decides whether to expand it, change it or close it.

A pilot is meant to answer a question. Can the system handle this decision well enough, under the conditions that matter, to justify the next step? If the team cannot say what evidence would settle that question, the pilot may keep running after it has stopped producing useful evidence.

How to recognise it

• The team reports encouraging results, but each review ends with another extension and no named decision owner.
• The pilot handles only unusually simple cases, or relies on people and manual checks that wider use could not sustain.
• Technical quality is discussed, while the business outcome, operating cost or customer experience remains unclear.
• A move to live use depends on an approval or workflow change that nobody has planned.
• New requests keep being added to the pilot without revisiting what it was built to test.

These signs do not mean the system should be released more widely. They mean the team needs an explicit decision about what it has learned and what remains unresolved.

Decide what the pilot must prove

Before starting, record the decision the sponsor will make at the review point: expand, redesign, run a targeted test or stop. Agree on the business result, the quality and safety conditions, the cases in scope and the cost of operating the process. Name the person who owns the decision and the people whose review is required for the proposed next step.

Include difficult cases in the evaluation, or state clearly that they are out of scope and where they will go. Record the extra conditions supporting the pilot: selected staff, cleaned data, manual reconciliation or close supervision. Expansion planning must either provide those conditions at scale or change the design so they are no longer needed.

A Dual Run can compare AI proposals with decisions made under the current process before the system gains more authority. The comparison can reveal errors and exceptions, but it does not turn a threshold into automatic permission. The process owner still needs to judge the consequences of mistakes and the readiness of the team and controls.

Hold the exit review

At the agreed review, put the evidence next to the original question. If the case is strong, define the next scope, controls and owner. If a specific uncertainty remains, design a short test that can resolve it and set another decision point. If the process is not viable, close the pilot and record why. Leaving it open simply because the work already happened ties up people who could address a better opportunity.

Some pilots cannot expand because the intended workflow needs a policy decision, a different budget owner or changes in how managers work. Treat that as part of the product decision, not a model defect. The Frozen Middle article explores the organisational side.

A careful rollout has clear boundaries and recurring decisions. A pilot with no exit has activity without a decision. The difference is visible in the written record: what was tested, what the team found and what it chose to do next.