The Short Answer
Enterprise AI initiatives are abandoned with an average of $7.2M sunk because eighteen months go into building a foundation every organization needs identically. On ibl.ai that foundation already exists and you own all the code and the data, so programmes reach production in weeks. It is model-agnostic with no per-seat pricing, and deploys anywhere, including fully air-gapped.
The average sunk cost per abandoned large enterprise AI initiative is $7.2 million. 88% of AI pilots never reach production at all, regardless of company size.
Capgemini's survey of 1,100 financial-services leaders across 14 markets found only 10% have deployed AI agents at scale, with 80% still in ideation or pilot.
These programmes rarely fail because the technology did not work. The demonstration worked — that is why it was funded.
Where does a $7.2M initiative actually spend the money?
On the 80% of the work that is invisible in the demonstration that justified it.
A working prototype is roughly a fifth of the effort.
The rest is what stands between a demo and something that passes a security review: permissions-aware retrieval that honours each user's real entitlements across several source systems, an evaluation harness built from real traffic, guardrails and prompt-injection defense, role-based access control, audit logging a compliance reviewer accepts, and model routing.
Every organization needs that list. None of it differentiates anyone.
And in a from-scratch engagement, each organization funds it separately — which is why 79% of enterprises reported AI cost overruns in the past twelve months, with 80–85% missing infrastructure forecasts by more than 25%.
The uncomfortable summary: most of a $7.2M write-off was spent on parity, not advantage.
Why do programmes get abandoned rather than finished?
Because the timeline outlives the conditions that authorised it.
An eighteen-month construction phase has to survive a budget cycle, an executive sponsor, a reorganisation, and a shift in the AI landscape that makes the original design look dated. Many do not survive all four.
The pattern is consistent. Months one to three produce visible progress and confidence. Months four to twelve are spent discovering that the foundation is harder than estimated.
Somewhere after that, the sponsor moves, the budget is re-examined, and a programme with no production workload and a large invoice history is difficult to defend.
Nobody decides to waste $7.2 million. The decision that produces it is made much earlier, when the plan commits to building a platform rather than integrating one.
Is "pilot purgatory" a technology problem?
No, and treating it as one is why the next pilot behaves the same way.
The instinct after a stalled pilot is to change the model, the vendor, or the use case. Those are the visible variables. But the same 80% of foundational work is required whichever model or vendor you choose, so a new pilot re-enters the same tunnel with fresh enthusiasm.
What actually changes the outcome is changing the starting point — reaching production in weeks rather than quarters, because the platform being deployed already exists.
That is not an argument against custom engineering. It is an argument about what should be custom: your data model, your workflows, your agents, your integrations. Not another implementation of audit logging.
We looked at how this plays out across different partner types in Who Should Build Your AI Platform in 2026?.
What separates the 10% that reach scale?
They resolved architecture before scaling, so the review happened once instead of per use case.
The organizations running agents in production generally did not find better models. They settled where the system runs, who holds the data, what the audit trail looks like, and who can operate it — and then added use cases against that foundation.
The 90% did the reverse: proved value in a pilot and left the architecture to be negotiated afterwards, which is exactly when the security review, the residency question, and the ownership question all arrive at once.
Deciding the foundation first sounds slower and is consistently faster, because it is done once.
How do you avoid becoming the statistic?
Three questions, asked before any engagement is signed.
What fraction of this scope is unique to us? Categorise the proposal into foundational platform work versus your data model, workflows and integrations.
If a competitor in your sector would need a capability built identically, it is not differentiating and you should not be funding its construction.
When does the first real workload serve real users? If the answer is measured in quarters, most of that time is construction. Ask what specifically is being built during it.
What do we hold if this is cancelled in month nine? A licensed platform running on your infrastructure with source rights is an asset that survives cancellation. A partially-built bespoke system is the $7.2 million.
ibl.ai is built to answer all three.
The platform is in production with 1.6M+ users from 400+ organizations and ships with the full source code under a perpetual licence, so forward-deployed engineers integrate and extend rather than construct — and the arithmetic is in our T&M vs owned-platform calculator.