The demo worked. Everyone in the room nodded. Four months later it's still a demo. Here's the pattern we see almost every time.
There's a particular kind of AI project that dies quietly. It isn't a failure — that's the confusing part. The prototype does the thing. Someone senior sees it, likes it, and asks how quickly it can go live. And then nothing happens for a quarter, and by the next budget round it's a slide about "learnings".
The reason is nearly never the model. It's that a demo only has to work on the examples you chose, and production has to work on the ones you didn't.
The last 20% is three specific things
When we're brought in to rescue a stalled pilot, the gap is almost always some combination of the same three problems.
1. Nobody designed the exception path
The prototype handles the clean case. Real work is full of the other kind: the invoice with two purchase order numbers, the contract that's a scan of a fax, the customer who asks three questions in one email. A system that's right 90% of the time and silent about the other 10% is worse than no system, because someone now has to check all of it.
The fix isn't a better model, it's a confidence threshold and a queue. Decide in advance what "unsure" looks like, and where unsure work goes.
If your design doesn't say what happens when the system is wrong, you don't have a design yet.
2. It was never given the right access
Prototypes run on an export. Production runs on the live system, behind SSO, with permissions that differ by team. That's a real integration project with a real security review, and it doesn't fit in the gap between two other pieces of work.
Teams that get this right treat access as the first conversation with IT, not the last. The question to ask early: which system of record does this write to, who's allowed to write to it today, and does the assistant get the same permissions as the person it's acting for?
3. No one's name is against the output
This is the one that sinks the most projects, and it never appears on a technical risk register. If the system drafts a customer reply, someone has to be accountable for what goes out. If nobody has been asked to be, everybody quietly opts out, and the tool becomes optional. Optional tools don't get used.
What to do instead
- Pick the success measure before you build. Not "improves efficiency" — hours returned per month, or percentage of cases closed without escalation. Agree it in writing with the person who'll be asked whether it worked.
- Design the exception path in week one. What the system does when unsure, where that work goes, and who empties that queue.
- Bring IT in at the start. Access is the long pole in the tent. Everything else can be rebuilt in a fortnight.
- Name an owner inside the business. Someone whose job improves when this works. Not the project sponsor — the person doing the work.
- Ship narrow. One team, one process, one measure. A small thing running in production teaches you more in a week than a broad pilot teaches in a quarter.
None of this is glamorous, and none of it is really about AI. It's the same operational discipline that any new process needs. But it's the difference between a system your team relies on by Christmas and another very good demo.
Got a pilot that's stuck? Tell us where it got to — first call is free.