Written by: Jakub Pietroszek, Partnership Manager, Digital Colliers
The average company scrapped 46% of its AI proofs-of-concept before they reached production. That stat tells you half the story. The other half is what those teams paid to find out. Some teams killed bad POCs in three weeks and moved on. Others dragged them out for nine months, burned six figures, and arrived at the same conclusion. The difference was the stop rule.
Why most POCs drift
Most teams write success criteria but skip the inverse. They define what good looks like at the end of twelve weeks. They do not define what bad looks like at week three. So when the POC starts missing milestones, there is no clear trigger to pull the plug. The team extends the timeline, adjusts the scope, and hopes the next sprint will be different.
More than 80% of AI projects fail, roughly twice the failure rate of conventional IT projects. The ones that fail slowly do the most damage. They occupy your engineers, they consume your budget, and they signal to the rest of the business that AI is a slow-moving science experiment rather than a tool you ship.
What a stop rule actually is
A stop rule is a predefined condition that ends the POC immediately. It is not a success metric in reverse. It is a threshold that says if we hit this, the entire bet is off.
The pattern that works: three binary tests, each with a hard date. If the POC cannot pass all three, you stop. No recovery plan, no extended runway, no second phase. You document what you learned and you move on.
Here is what those tests look like:
- Week 1: Can the model produce any output that resembles the target format? If it cannot generate coherent responses or structured data by day five, stop.
- Week 3: Can a subject matter expert use the output without significant rework? If your domain expert still has to rewrite 80% of what the model produces, stop.
- Week 6: Can you measure a cost per transaction that lands within 3x of your target economics? If the unit cost is wildly off and there is no clear path to compression, stop.
Each test is binary. You either pass or you stop. No maybes.
The checkpoint conversation
The stop rule only works if you schedule the conversation in advance. Week three arrives and you sit down with the team. You look at the output. You ask the subject matter expert if they can use it. If the answer is no, you thank everyone and you close the POC.
This is harder than it sounds. The team will want another two weeks. The vendor will suggest tuning the prompt. The engineer will say they just figured out the issue. You cannot let that meeting turn into a negotiation. The stop rule was the negotiation, and it happened before you started.
Around 95% of enterprise GenAI pilots deliver zero measurable P&L impact. Half of that waste is funded by teams who knew the POC was not working but kept going anyway. The checkpoint conversation is where you catch that early.
What you do after you stop
Killing a POC is not failure. It is information. You now know that approach does not work for that use case with that model at that cost. That is valuable.
The pattern the shipping teams follow: write a two-page post-mortem within 48 hours of stopping. What did we test, what did we learn, what would we do differently if we tried again. Then you decide if there is a different angle worth testing or if the entire use case is off the table for now.
42% of companies abandoned most of their AI initiatives in 2025, up from 17% in 2024. The ones who abandoned them early paid less. The ones who abandoned them after months of drift paid the full cost and got nothing to show for it.
The stop rule is not pessimism. It is the tax you pay to fail fast. Write it before you write the POC. Make it binary. Schedule the checkpoint. And when you hit it, stop.