Most AI recommendations are built to say yes. They're often commissioned by teams who have already been told to "do something with AI", and whoever writes them usually knows which answer the room is hoping for. So the output is a roadmap, and everything on it goes ahead.
If a recommendation can only ever say yes, I don't think it's really a recommendation. It's closer to a stage in a sales process.
I've told clients to stop more than once. I've come to think that being willing to say it is one of the most useful things an adviser can bring into the room.
Why I've said stop
Every time I've recommended stopping, it has come down to the same thing. I could see that even if the pilot worked, production wouldn't.
The reasons varied. In some cases the people who'd have to use it weren't going to adopt it. In others the technology wasn't ready for what was being asked of it, or the data wasn't clean enough to trust. And occasionally, frankly, it just wasn't worth the organisation's time compared with everything else on the list.
I wrote recently about a large retailer whose innovation team built agents for personalization, recommendations and customer service before the data, the skills or the integrations were in place. It stalled and was quietly shelved. If someone had said early on, "stop, fix the data first, then come back to this", I'm certain it would have become a live shopping assistant, handling more customers and bringing in more revenue. The idea itself was right, but the work was done in the wrong order.
People often miss this about a recommendation to stop. In most cases it doesn't mean never. It means not in this form, or not yet.
Advise the way you'd advise a friend
I've always tried to work as the client's adviser first, and to give the advice I'd give a friend. Now and then, that has meant recommending something that wasn't in my employer's interest.
When I was drawing up the generative AI strategy for an airline, one of the use cases was in legal. When we looked at it properly, buying an existing product made more sense than building something custom, so that's what I recommended. The firm I was with made more of its money through implementation, and a custom build would have been the more comfortable answer for us. It wasn't the right answer for them.
A recommendation to stop can look like that too: pausing, buying instead of building, or trying a smaller version first. What matters is that the recommendation is free to land anywhere, including somewhere the adviser would rather it didn't.
What makes a no believable
Anyone can say they're willing to recommend stopping. For a board to believe it, the work has to be set up so that stop is a real possible outcome from the first week, not something bolted on at the end. There are a few things I'd put in place.
The most important, by far, is writing down what you believe before the evidence arrives. In the first week, the leadership team records what they expect: which workflows matter, how big the value is, and what's in the way. Then the evidence gets compared against those beliefs. If you skip this step, what usually happens is that the evidence gets quietly reshaped to fit what everyone already wanted, and the business case says yes because it was always going to.
It also needs an owner. If no executive is willing to put their name against the outcome of a workflow, it shouldn't get full funding, however good the demo looks. In my experience that's often the clearest signal in the whole exercise. People are usually happy to sponsor a pilot, but they're much more careful about putting their name against a number.
And I'd test the riskiest assumption first. Rather than prototyping the whole thing, find the one assumption that would sink the economics if it turned out to be wrong, and test that cheaply. In retail it might be whether the supplier-terms data is accurate enough to use, or whether store stock counts can be trusted. If it fails, you stop there, weeks in rather than quarters.
All of this happens before anyone builds anything. That can feel slow at the start, but it's a lot cheaper than finding out two quarters into a build.
The question to ask
Stopping a workflow early can feel like wasted effort. In practice it saves the several quarters a drifting pilot would have eaten, and it frees up money and people for the workflows that have an owner, usable data and a result someone can measure.
So if you sit on a board, or you're a CFO being handed an AI investment recommendation, here's the question I'd ask before anything else: what would it have taken for this to tell us not to go ahead?
If the honest answer is nothing, then I don't think the recommendation has done its job.
Written by Akshay Bardia, with AI help for research, drafting and editing. The views and experience are his.
