Skip to content
Cost and ROI

What an AI Rollout Costs Beyond the Vendor Invoice

Editorial desk·9 min read··Composite scenario, no client described
The decision to take

The vendor invoice is the smallest line in an AI budget. Here is the full cost structure, which parts grow after launch, and when to stop.

Executive summary

Adoption is near universal and returns are not: 88 percent of organisations use AI regularly, 39 percent can point to any profit impact. The gap is mostly cost nobody budgeted. Model fees are the one line that behaves predictably, while integration, review time and maintenance grow with usage. This is how to price all of it before the budget is committed.

A finance director asks a simple question about the AI pilot that has been running for four months: what does this cost to operate next year. The team quotes the vendor’s price per million tokens. That number is accurate, and it answers almost nothing.

Twelve months later the same programme has a cost line that has grown several times over, and no one in the room can say which part grew. The model fees are roughly what was forecast. Everything around them is not.

This is the most common way an AI programme fails: not a dramatic technical collapse, but a budget that quietly stops making sense while the system keeps working. The failure is in the estimate, and the estimate was wrong because it priced the one component that is easy to price.

The gap shows up clearly in survey data. McKinsey’s State of AI survey, published in November 2025 with 1,993 respondents, found that 88 percent of organisations use AI regularly in at least one function while only 39 percent can attribute any EBIT impact to it at the enterprise level. Adoption is close to universal. Returns are not. A large share of that distance is cost that nobody put in the business case.

What you are actually buying

An AI implementation is not a subscription. It is a piece of production software with an unusual property: it degrades without anyone touching it. That property drives most of the cost structure.

The canonical description of this problem is a decade old and still the most useful thing written on it. In Hidden Technical Debt in Machine Learning Systems, Sculley and colleagues at Google described machine learning code as a small fraction of a real production system, surrounded by configuration, data collection, feature extraction, serving infrastructure, monitoring and process management. Their central finding was that these systems carry a distinct set of ongoing maintenance costs, arising from entanglement between components, undeclared consumers reading outputs nobody tracked, data dependencies that shift underneath the model, and configuration that accumulates faster than anyone documents it.

Nothing about the current generation of language models removed those categories. It changed which ones dominate. Feature engineering shrank. Integration surface, prompt and context management, output review and vendor dependency all grew.

The lines that behave predictably

Model and infrastructure fees scale with usage in a way you can model. If you know the volume, you can forecast the bill within a reasonable margin. This is the line everyone quotes because it is the line everyone can defend.

The lines that do not

Integration with systems that were not designed for a probabilistic component. Human review of output, which is a permanent operating cost and not a temporary safety measure. Monitoring, because a model that starts being wrong does not raise an exception. Ownership, meaning a named person who is on call for a system whose failure mode is a plausible wrong answer rather than an outage. And the cost of the decisions themselves, which is real staff time spent arguing about scope and thresholds.

These do not scale with token volume. They scale with how deeply the system is embedded in the business, which is the same thing as how much value it creates. That relationship is the uncomfortable part: the more useful the deployment, the faster its surrounding costs grow.

Where the economics genuinely work

The cases that pay back share a shape. High volume, so fixed integration cost is spread thin. Tolerance for a wrong answer, so review can be sampled rather than exhaustive. A stable input format, so the system is not chasing a moving target. And a process that was already documented, because automating an undocumented process automates the confusion in it.

  • High volume, low stakes per item. Classification, routing and triage across thousands of items a week. The precondition is that a wrong answer is cheap to correct and gets corrected downstream anyway.
  • Draft generation with a human already in the loop. Work where a person was going to review the output regardless, so review time is displaced rather than added. The precondition is that reviewing a draft is genuinely faster than writing one, which is not true for short or highly specific outputs.
  • Extraction from documents you receive constantly. Invoices, forms, claims. The precondition is a confidence threshold above which output is accepted and below which it goes to a person, plus someone who owns where that threshold sits.

Notice that every precondition is organisational rather than technical. None of them is about model quality.

Where the bill outruns the benefit

This is the section that decides whether a programme is worth starting, and it is the one most vendor material skips.

Low volume with real integration cost

A process that runs forty times a month cannot absorb an integration that takes two engineers six weeks. The saved time is real and the integration is real, and the integration wins permanently, because it has to be maintained every year while the saving stays flat. This is the single most common case where the honest answer is to stop, and it is usually visible in the first week of scoping.

Review that never shrinks

Business cases routinely assume review effort declines as confidence grows. Sometimes it does. It does not when the cost of a wrong answer lands on a customer or a regulator, because then the review is not there to catch model errors, it is there to satisfy an accountability requirement. That requirement does not care how good the model is. If your process is in that category, price full review permanently and see whether the case still holds.

Agentic workflows priced like single calls

A pilot that answers one question per user action costs one call. A production workflow that plans, retrieves, calls a tool, checks its own work and retries makes many calls for what looks externally like the same action, and it pays for the intermediate calls even when the final step fails. Teams that modelled cost during a single-call pilot and then deployed a multi-step workflow are the ones most surprised by their bill. The fix is to model cost per completed task, not per call, and to measure it on real traffic rather than on the happy path.

No owner after launch

An unowned model degrades quietly. Inputs drift, an upstream team changes a field, a vendor updates a model version, and the outputs stay plausible while becoming wrong. The cost here is not the fix. It is the months of decisions made on bad output before anyone noticed, and that cost is unbounded. If nobody’s name is against the system, the correct decision is not to deploy it. We have written separately about which pilots to stop in the first month, and missing ownership is near the top of that list.

What the payback data actually says

Deloitte’s analysis of AI returns draws on a survey of 1,854 senior executives run between 15 August and 5 September 2025 across fourteen countries in Europe and the Middle East, and reports that only six percent achieved payback in under a year. The same analysis notes that observed payback periods run significantly longer than the seven to twelve months organisations typically expect from a technology investment.

Read that as a planning input rather than a warning. If your business case assumes payback inside a year, you are assuming an outcome that six percent of organisations achieved. That may still be the right call for a specific, well-shaped process. It is the wrong default.

The decision

The vendor invoice is the only line in an AI budget that behaves like a normal software cost. Everything else scales with integration depth and accountability requirements, not with usage, and those are the lines that decide whether the programme survives contact with a finance review. A case built on model pricing alone is not a case, it is a quote.

One concrete step, doable this week with people you already have. Take the AI initiative currently closest to a budget decision and write down five numbers: monthly volume of the process, engineering days to integrate, minutes of human review per item after launch, the name of the person who owns the system in production, and the cost of one wrong answer reaching a customer. If you cannot fill in all five, you do not have an estimate. If the fourth is blank, you do not have a project.

Deciding which of those numbers is acceptable is a standing responsibility rather than a one time exercise, and it usually needs someone whose job it is to say no. That is the function we describe in our note on what a fractional CAAO mandate covers. If you want that judgement applied to a specific decision rather than in the abstract, that is the work we do.

Frequently asked questions

What percentage of AI cost is the model itself?

There is no reliable universal figure, and any single percentage should be treated with suspicion. What is consistent is the direction: model and infrastructure fees are the line that scales predictably with usage, while integration, review and maintenance scale with how deeply the system is embedded in the business. Model your own case rather than importing someone else’s ratio.

How long should we expect an AI investment to take to pay back?

Deloitte’s 2025 survey of 1,854 executives found only six percent reported payback in under a year, and noted that observed payback runs longer than the seven to twelve months typically expected from technology investments. Treat sub-year payback as an exception you must justify, not as a default assumption.

Does human review cost go away as the model improves?

Sometimes, but not when review exists to satisfy an accountability requirement rather than to catch model errors. If a wrong answer reaches a customer or a regulator, the review requirement is independent of model quality. Price full review permanently in those cases and check whether the business case still holds.

Why do agentic workflows cost so much more than pilots suggested?

A single-call pilot and a multi-step production workflow are different cost structures. A workflow that plans, retrieves, calls tools and retries makes many calls for one apparent user action, and pays for intermediate calls even when the final step fails. Model cost per completed task on real traffic, not per call on the happy path.

What is the single strongest signal that a project should be stopped?

No named owner for the system after launch. An unowned model degrades quietly while its outputs stay plausible, so the cost is not the eventual fix but every decision made on bad output before anyone noticed. That cost is unbounded, which makes it the one gap that cannot be priced around.

Sources