Most AI projects that stall were never going to ship. You can usually tell before anyone has spent a penny.
I've sat on both sides of this. For around twenty years I sold technology into large organisations. Now I build it, and I chair the group that has to answer for it. The pattern hasn't changed. Projects get funded on the strength of a demo, then meet real data, real systems and the question of who owns it on a Monday morning. That's where they stop.
So before anything gets built, I ask five questions. I call it the Working Test, because every one of them is really asking the same thing: can this system show its working?
If the answer to any of them is "we'll figure that out later", don't fund it yet.
1. Who owns it?
Not who sponsors it. Who owns it. One named person who will be accountable for what it does in production, who gets the call when it goes wrong and who decides when it changes.
If the answer is "the AI team" or "IT", that's not an owner. That's a department. The projects that ship have a person in the business whose name is on the outcome.
2. What can it do on its own?
Write it down. What actions can the system take without a person approving them? What are the limits: amounts, customer types, data it can touch? And what happens to everything outside those limits?
Most AI in production should do the routine volume on its own and hand anything unusual to a named person with the full history attached. If nobody can tell you where that line sits, the system isn't ready, and neither is the business.
3. What's the number?
What does this process cost today, in hours, errors, delay or cash? Measured, not guessed. And what will it cost afterwards?
Agree the baseline before anything is built. Agree how you'll measure the result, and who will measure it. If you can't put a number on the problem now, you won't be able to put a number on the result later, and the project will end up being judged on how people feel about it.
4. Where's the record?
Six months from now, someone will ask why the system made a particular decision. It might be a customer, an auditor or your own board. When they do, can you open a file and show them what the system did, under whose permission, with which data, and where a person made the call?
If the honest answer is "we'd have to investigate", you're building something you can't defend. In a regulated business that's not a technical risk. It's a personal one, for whoever signed it off.
5. What happens when it's wrong?
It will be wrong. Every system is, people included. The question is what happens next. How quickly do you find out? Who fixes it? Does the fix go back into the rules so it doesn't happen again?
A good answer here is specific: the exception queue, the person who works it, the review that changes the rules. A bad answer is "the model is very accurate".
Using it
Run the five questions in the first meeting, not the last. They take an hour. They'll kill some projects, which is the point: better to stop a weak idea cheaply than to fund a pilot that was never going to ship.
The projects that pass tend to look alike. One process. One owner. A number agreed up front. A record of every decision. A plan for when it goes wrong. None of that is about the technology, and all of it decides whether the technology ever pays.
That's what I mean by AI that shows its working.
Show Your Working is a fortnightly piece on building and buying AI that pays its way. If this was useful, subscribe and send it to the person who'll be signing off your next AI project.