The demo went well. The model read the invoice, pulled out the supplier, the amount and the due date, and everyone in the room nodded. Three months later the pilot is "still being evaluated" and nobody can say when it will go live.
We see this pattern often enough to describe it. The model is rarely the problem. The trouble sits at the handoff: the point where the AI's output has to become somebody's actual work.
The pilot answers the wrong question
A pilot usually asks, can the model do the task? Often it can. But a business does not run on tasks. It runs on a chain of them, and each link has an owner, a system and a deadline.
Take that invoice. Extraction is one step. Someone then has to match it to a purchase order, check it against the budget, route it for approval and post it to the ledger. The AI shortened the first step from four minutes to ten seconds. The other four steps are untouched, and they are where the days go.
If the pilot measures only the step the model handles, it will look like a triumph while the process around it stays exactly as slow as before.
Three places the handoff breaks
Nobody owns the output. The AI produces a result, and then what? In a pilot, a project lead checks it. In production, a finance clerk is meant to, but nobody told her, her queue has not changed, and she does not trust what she did not ask for. Work with no owner does not get done.
The output does not fit the next system. A model returns a paragraph. The ledger wants a supplier ID, a currency code and a tax category. Someone ends up retyping, and the saving evaporates. Fit is an engineering problem, and it is dull, which is why it is left until last.
Errors have nowhere to go. Models are wrong sometimes. In a demo that is a funny moment. In operations it needs a path: who sees the doubtful ones, how they correct them, and whether the correction improves anything. Without that path, the first visible mistake gets the whole project paused.
What we do differently
We start from the end of the process, not the beginning. Before choosing a model, we ask where the result lands, who acts on it, and what that person needs to see in order to act without redoing the work.
Then we shape the output for that person and that system. Confidence shown plainly. The source of each extracted value visible beside it. A one click correction. The doubtful cases routed to a named role, and the confident ones passed straight through.
We also change the measure. Not "accuracy of the model" but "time from invoice received to invoice posted". It is a less flattering number, and a truer one.
Where this advice runs out
Sometimes the handoff is not the problem. The task may be genuinely too hard for current models, or the data too messy, or the volume too low to justify any automation. A pilot that stalls for those reasons should be stopped, and stopping it is a good outcome.
And redesigning a handoff means changing how people work, which is political in a plain, human sense. Someone may lose a task they valued. Say so early.
A hypothetical from the shop floor
Imagine a distributor that pilots AI to read incoming purchase requests from email. The model does well. But the requests arrive from forty different people, each describing items in their own way, and the stock system accepts only product codes. The pilot team never had to solve that, because they tested on a clean sample. In production, a clerk spends the saved minutes translating the model's answer into codes by hand.
Nothing about the model changed between the demo and the failure. The only thing that changed was that the output met the real process.
A question for your pilot
Ask who will open the AI's output on a Tuesday afternoon, in a real queue, with real deadlines. If you cannot name the person, you have a demo. Find the person first, and the pilot will have somewhere to go.