Most AI pilots do not fail on the model. They stall at the point where something that works in a demonstration has to become something a team uses on a Tuesday. Four causes account for most of it. The data was cleaned by hand for the demo, nobody owns the output once the project ends, success was never defined in a way anyone could check, and the work sits in an environment the client cannot run.

The break is not in the modelling. It falls between proving a thing works and anyone changing how they work because of it.

The uncomfortable part is that a stalled pilot usually looks like a success right up until it stops. The model performed. The demo landed. Everyone in the room agreed it was impressive. What did not happen was anybody changing how they work, and that gap is rarely visible in the final presentation.

The data was cleaned by hand

Almost every pilot runs on an extract somebody tidied up. Duplicates removed, a date field normalised, two systems reconciled in a spreadsheet over a weekend. None of that is dishonest and all of it is necessary to get moving. The problem arrives when the same model meets the live feed and the tidying is not there.

Ask early what was done to the data before the model saw it, and ask whether that work is repeatable by a machine. If the answer involves a person and a spreadsheet, the pilot has not been tested against production conditions and the timeline is longer than it looks.

Nobody owns the Tuesday

A pilot has a project team. Production has an owner, which is a different thing. Somebody has to be accountable for the output being right on an ordinary Tuesday in March, for noticing when it drifts, and for deciding what happens when it is wrong.

This is the most common gap and the least technical. It is also the one most likely to be discovered after the budget closes, because the project team disbands on the assumption that operations picked it up, and operations never agreed to.

Success was never defined

A surprising number of pilots begin without a written statement of what result would justify continuing. Without one, the decision at the end is made on impression, and impression favours whoever presents well.

Write the threshold down before the work starts. Not a vague improvement, but a number against a current baseline, measured the same way both times. If the current baseline cannot be measured, that is the first piece of work, and it is worth knowing that before spending on a model.

The work lives somewhere you cannot reach

If the pilot ran in a supplier environment, moving it to production is a rebuild and not a deployment. The code, the model artefacts, the evaluation results and the runbook all have to arrive somewhere the client controls, and that transfer is usually scoped as an afterthought when it is scoped at all.

The test worth applying is whether the work could continue if the supplier stopped answering the phone next week. It is an uncomfortable question to ask in month one and a much more expensive one to answer in month nine.

What to do before the next one

Two things carry most of the weight. Decide who owns the output in production before the pilot starts, by name, and write down the result that would justify going ahead. Everything else on this page is easier to fix once those two exist.

It is also worth being honest about what a pilot is for. A pilot that proves a thing is possible has done its job even if it never ships, as long as that was the stated purpose. The waste comes from pilots that were meant to reach production and were never set up to.

On the numbers you may have seen. Widely quoted AI pilot failure rates mostly come from vendor surveys whose method is not published, so no percentage appears on this page. The failure modes above are observable and worth naming. How often each one occurs is not something NTWRK has measured, and stating it would be inventing a number. Related reading on what a first phase should leave behind sits in how to choose a data consultancy.