Written by: Kacper Osiewalski, Lead Backend Engineer, Digital Colliers

Most AI pilots die predictable deaths. More than 80% of AI projects fail, roughly twice the failure rate of conventional IT projects. According to IDC, 88% of AI proof-of-concepts never reach widescale deployment. For every 33 POCs a company launches, only four graduate to production. The problem is not the technology. The problem is that most pilots get funded without answering three basic questions. If you cannot answer them in the first conversation, you are buying an expensive lesson in month four.

Can you measure the cost if we do nothing?

This is not "what is the opportunity?" This is "what does inaction cost us per month?" If you cannot quantify the burn rate of the status quo, you cannot measure whether your pilot succeeded. A large minority of teams pitch AI projects with upside narratives but no baseline. The pattern I keep seeing: they build something that works technically, but nobody can say whether it mattered.

The operators who ship AI to production start with a number. How many hours does the manual process consume? What is the error rate costing us? How much revenue are we leaving on the table because we cannot respond in time? If you do not have that number before you fund the pilot, you will not have it after. You will have a working prototype and a room full of people asking "so what?"

Research from MIT shows that 95% of enterprise GenAI pilots deliver zero measurable P&L impact. That is not a technology failure. That is a selection failure. You cannot hit a target you never defined.

Who owns this when it breaks?

AI systems break differently than conventional software. They degrade silently. They produce plausible-looking garbage. They inherit bias from training data you did not vet. If you cannot name the person who takes the call when it goes wrong, you are building a liability without a budget line.

Most teams fund pilots without assigning operational ownership. The data science team builds the model. The engineering team wraps it in an API. The business unit uses it. Nobody owns the system. When it starts hallucinating, or drifting, or violating a compliance rule, the incident bounces between teams until someone kills the project.

The pattern that works: one person owns the system end to end, with a clear escalation path and a maintenance budget. That person attends the funding conversation. If they are not in the room, you are not ready to fund.

What changes on Monday if this works?

This is the honest question. If your pilot succeeds beyond your wildest expectations, what specific behavior changes next week? If the answer is "we will explore additional use cases" or "we will scale it out," you are admitting that nobody is waiting for this. Real demand shows up as a queue. Someone has a backlog they need cleared. Someone is working nights because the manual process cannot keep up. Someone has a customer contract they cannot fulfill without this capability.

The projects that reach production have a user who is counting the days. They have a process that is visibly broken. They have a number that goes up or down when the AI ships. If your pilot does not have that, it will not survive the next budget review.

S&P Global reports that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% in 2024. The survivors are not the ones with better models. They are the ones who answered these three questions before they wrote the first line of code.

You already know whether your next pilot will ship. If you can answer these three questions in one sentence each, you are building something real. If you cannot, you are buying a learning experience. Both are valid. Just know which one you are funding.

Can you measure the cost if we do nothing?

Who owns this when it breaks?

What changes on Monday if this works?

Sources

AI moved the work, it didn't remove it

Count connections, not licences

Design for the compliance boundary first