Why AI pilots stall, and it's rarely the model

I've now watched enough AI pilots up close to recognise the pattern. They almost never fail on the model. They fail on three questions nobody answers up front.

A pilot usually goes like this. Someone builds something impressive in two weeks. The demo works, the room is enthusiastic, budget appears. Three months later it still isn't running in production, and nobody can say precisely why not.

The answer is almost always the same, and it has nothing to do with AI.

Question 1: what happens when it's wrong

Every system that makes decisions eventually makes a wrong one. That isn't a defect, it's a property. The question isn't whether it happens but what follows, and that's an organisational question, not a technical one.

In the systems I build, I classify every action into three tiers. Green: just do it, the cost of a mistake is negligible and reversible. Yellow: prepare it and put it to a human. Red: don't touch it, only flag it.

You make that classification before you start building, together with the people accountable for the process. It takes an hour and it determines the entire architecture. A pilot that skips it can be technically flawless and still never roll out, because at the moment of rollout nobody is willing to sign off on what the thing may do autonomously.

Question 2: who owns the process underneath

An agent automates a process. If that process has no owner, you're automating chaos, only faster.

You cannot automate a process nobody owns. At best you can speed it up until someone notices.

This is the most common quiet cause of death. The project is driven by an innovation manager or a CTO, the process sits with operations, and operations weren't in the room when scope was set. At rollout it turns out the agent makes assumptions that don't match how the work actually happens, and there's nobody with both the mandate and the knowledge to correct it.

The remedy is banal: the process owner commissions the build. Not involved, not consulted. Commissions.

Question 3: who maintains it in six months

Agents age faster than ordinary software. Your CRM gains a field, an API changes, a vendor adjusts its model, the process itself shifts. An agent nobody maintains degrades quietly, and the awkward part is that it keeps answering while it gets worse.

Which means the question "who changes this" has to be answered before the first line of code. If the answer is "the external party", you haven't bought automation, you've bought a subscription to dependency. I consider that a bad outcome, even though it's commercially attractive for me.

What a pilot should actually prove

Most pilots prove the technology works. We knew that. What they should be proving is something else:

That the process is understood well enough to put rules on it
That someone is willing to sign off on the green actions
That the failure cases are manageable in number and in severity
That there's someone internal who will still understand it in six months

If those four hold, the build is the easy part. If one doesn't, no model is good enough to compensate.

A practical order

When I come in on an automation question, this is the order I hold to. First look at what actually happens, including the exceptions nobody documents. Then set the three tiers with the process owner. Only then build, against real data, in an environment where mistakes break nothing. Then roll out with logging, escalation and a threshold above which a human decides. Then hand it over, with documentation, to someone with a name.

That's slower than a two-week demo. It's also the difference between something that runs and something that impressed people.