How to Move AI Pilots Into Production

Chief Information Officer (Transport and Mobility Operator)

We have eleven AI pilots. Nine of them demonstrated well and none of them is in production. The board is losing patience and I am starting to think the problem is not technical. What actually stops a pilot from crossing?

AI Leadership Agent — Delivery Advisory

It is almost never technical. Pilots are designed to prove that something is possible, and production requires proof that something is sustainable. Those are different tests, and most pilots are never subjected to the second.

A pilot answers can it work. Production answers who owns it, who fixes it at two in the morning, and what happens when it is wrong.

Five conditions decide whether a pilot crosses, and they are all knowable before it starts:

1. A business owner whose objectives improve if it works. Without this, production is somebody else's project.
2. Integration into the actual workflow, not a parallel tool. Anything requiring a second screen dies on contact with a busy day.
3. A stated accuracy or quality threshold agreed in advance, with the behaviour below the threshold defined.
4. Monitoring and support: who is paged, who retrains, what the fallback is when the system is unavailable.
5. A budget line for run costs. Pilots are funded from innovation money; production needs an operating budget somebody has agreed to carry.

Of your nine successful pilots, how many had a named business owner from the start?

Chief Information Officer (Transport and Mobility Operator)

Two, and unsurprisingly those two are the closest to going live. For the rest, IT sponsored them. How do I retrofit ownership without it looking like I am dumping work on the business?

AI Leadership Agent — Delivery Advisory

You retrofit it by offering a trade rather than a transfer. Ownership comes with something the business wants: capacity, a measured improvement to their own targets, and the right to stop the thing.

1. Present each pilot as a proposition in their terms — hours returned, errors avoided, cycle time — with the evidence from the pilot attached.
2. Offer resourced support for the first six months: your team runs it, they own it, with a defined handover.
3. Give them a genuine right to decline. Two or three will decline, and those should be retired publicly. That is a good outcome, not a failure.
4. Attach the run cost to the offer honestly. Ownership without cost transparency breeds resentment later.

Retiring four pilots deliberately is a stronger signal to your board than keeping eleven alive in perpetual evaluation.

What does your production environment look like for these systems — is there a path, or would each be bespoke?

Chief Information Officer (Transport and Mobility Operator)

Each would be bespoke, which is part of the problem. Every pilot was built differently by a different vendor. Is the answer a platform, or is that just another year of work?

AI Leadership Agent — Delivery Advisory

Not a platform programme. A production path — a documented set of requirements any system must meet to be operated by your teams: how it is deployed, logged, monitored, secured, supported and evaluated. Written down, it can be applied to bespoke systems immediately, and it becomes the specification for anything vendors build next.

1. Write the production path in a fortnight with your operations and security leads. It should be pages, not a programme.
2. Take the two owned pilots through it first and fix the path where it breaks.
3. Make it a contractual condition for all new AI work, including vendor-built systems.
4. Only then consider consolidating tooling, based on what the path showed you actually needed.

Organisations do not have a pilot problem. They have a missing production path, and pilots pile up in front of it.

Build the path, retire what does not deserve to cross, and the eleven becomes three that matter.