The Short Answer
AI budgets overrun because they price models and compute while the real cost sits in the foundation — retrieval, evaluation, guardrails, access control, audit logging. On ibl.ai that foundation already exists and you own all the code and the data, so spend goes to your workflows instead. It is model-agnostic with no per-seat pricing, and you can deploy anywhere, including fully air-gapped.
The figures for the past twelve months are stark. 79% of enterprises experienced AI cost overruns. Between 80% and 85% missed their AI infrastructure forecasts by more than 25%, and 85% systematically misestimate AI costs at the forecast stage.
When 85% of organizations get the same estimate wrong in the same direction, the explanation is not carelessness. It is that they are estimating the wrong thing.
What actually drives AI cost overruns?
Not the models, and not the compute — which is where nearly every AI budget concentrates its attention.
The largest gaps arise from data infrastructure, network access, and workforce readiness: exactly the areas standard IT budgeting frameworks fail to capture, because they do not appear as procurable line items.
Data preparation and pipeline work, rather than compute, is the primary driver of cost overruns in production deployments.
That is worth restating, because it inverts the usual conversation. Organizations negotiate hard on token pricing and GPU rates, then overrun on the work of making their own data usable.
Model licensing is a visible, quotable, negotiable number. The foundation underneath it is none of those things, so it is not forecast — and it is where the money goes.
Why does every organization pay for the same foundation?
Because in a from-scratch engagement, every organization builds it separately.
The list barely varies: permissions-aware retrieval that honours each user's real entitlements, an evaluation harness built from your own traffic, guardrails and prompt-injection defense, role-based access control, audit logging a compliance reviewer will accept, and model routing across providers.
None of that is differentiating. A competitor in your sector needs it built identically. It is also the majority of the engineering effort in most AI programmes, and it is the portion that cannot be estimated in advance precisely because nobody has designed it yet.
The scale of the duplication is visible in the market. Accenture alone reported cumulative advanced-AI bookings of $11.5 billion through Q1 FY2026 across more than 1,300 clients and 11,000 projects. A large share of those projects built the same layers again.
We put numbers to this in the T&M vs owned-platform calculator, which separates foundational effort from work that is genuinely yours.
Why don't the overruns show up until late?
Because a prototype hides them, and a prototype is what gets funded.
A working demonstration is roughly 20% of the effort. The remaining 80% is what stands between that demo and something that survives a security review — and none of it is visible in the demo that justified the budget.
The consequence is a predictable timeline. Months one to three look excellent.
Months four through twelve are spent discovering that permissions-aware retrieval across four source systems is genuinely difficult, that the evaluation set nobody built means acceptance is a negotiation, and that audit logging was assumed rather than specified.
By the time this is apparent, the programme is committed, and the response is usually a re-baseline rather than a rethink.
What does the failure rate look like at the end?
Severe enough that the overrun is the better outcome.
88% of AI pilots never reach production at all, and the average sunk cost per abandoned large enterprise AI initiative is $7.2 million.
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.
Those three figures describe one phenomenon. A large number of organizations are spending heavily on AI programmes that do not reach production, and the spend concentrates in exactly the foundational work that is identical everywhere.
We looked at what that means for one sector in Banks Are Building AI Workforces on Infrastructure They Rent.
How do you forecast AI cost accurately?
Stop forecasting the models and start forecasting the foundation.
Three practical changes make most of the difference. Categorise the proposed scope into foundational platform work versus work specific to your organization, and ask each bidder which of the first list they already have running in production.
Define done as a held-out evaluation set with a passing threshold, drawn from your own data, so acceptance is measurable rather than negotiated. And price data preparation explicitly, because it is the single largest under-forecast item.
The fourth change is structural rather than procedural: reduce how much has to be built. A platform already in production has a known cost because someone else incurred it and amortised it, which leaves integration against named systems as the only variable.
That is why ibl.ai engagements are comparatively efficient.
The platform runs today with 1.6M+ users from 400+ organizations and ships with the full source code, so the budget covers your data model, your workflows and your integrations rather than another implementation of retrieval and audit logging.
The contracting side of the same argument is in Time and Materials Is an Admission, Not a Pricing Model, and the acquisition mechanics in Time & Materials for AI Infrastructure.