What an AI System Actually Costs to Run in Year Two

The build is quoted. The second year is not, and it is where AI programmes are abandoned. Six recurring costs routinely missing from the business case, four of which are people rather than compute, and the single figure worth tracking instead of build cost or projected saving.

The build is quoted. The second year is not, and it is where AI programmes are abandoned. Six recurring costs are routinely missing from the business case, and four of them are people rather than compute.

Why year two is where things break

A pilot is funded as a project. It has a budget, an end date, and somebody's attention. When it succeeds it becomes an operational system, and operational systems have running costs that nobody assigned an owner or a line item to.

The failure is rarely dramatic. The content stops being updated, so the answers drift out of date. The evaluation set is never rerun, so a model change degrades quality and nobody notices until a customer does. The token bill grows because usage grew and nobody was watching. Twelve months later somebody asks what this is costing and whether it is still working, and nobody can answer either question.

The six costs

The six recurring costs of year two

Four of the six are people rather than compute, and those are the ones routinely missing from the business case.

Source: Thinklytics AI readiness practice, 2026.

1. Inference and compute

The one everybody counts, and usually the smallest. It is also the one that behaves least predictably, because cost scales with usage and usage scales with success.

Two things drive bills higher than forecast. Retrieval puts large amounts of context in front of the model on every call, and context is the dominant term. And chatty interfaces produce long conversations where the whole history is resent each turn.

Controllable, with attention: cache what repeats, route easy requests to a smaller model, cap context, set per-team budgets and alerts. Uncontrollable if nobody owns it.

2. Keeping the content current

The largest hidden cost and almost never in the proposal.

A retrieval system is exactly as good as the corpus behind it. Policies change, products change, prices change, the SOP gets superseded. Somebody has to notice, update the source, remove the old version, and reindex. If that person is not named, the system is on a slow timer.

This is a standing part of somebody's job. In a mid-sized deployment it is regularly a day a week, and it is the single best predictor of whether the system is still trusted at eighteen months.

3. Evaluation and regression testing

You hold a fixed set of real inputs with known-correct outputs, and you rerun it on every change, yours or the vendor's. Models are updated underneath you. Prompts get edited. A retrieval tweak that improves one class of question degrades another.

Without this you cannot distinguish an improvement from a regression, so every change becomes a matter of opinion. Building the set is a one-off cost. Maintaining and running it is not.

4. Monitoring and drift

Accuracy decays quietly. Inputs change character, a new product line, a new supplier, a new customer segment, and performance falls on the new cases while the aggregate number looks fine.

What is needed: input distribution monitoring, output quality sampling by a human on a schedule, and alerting on refusal rates and escalation rates, which move before accuracy does.

The cost is partly tooling and mostly the recurring human hours to review the samples.

5. Integration maintenance

The AI system sits between other systems, and those systems change. The CRM is upgraded. An API version is retired. A field is renamed. The ERP migration nobody told you about breaks the connector.

Budget for this the way you budget for any integration estate. It is not an AI cost, it is an integration cost, and it arrives regardless.

6. Adoption, training and support

People join. People forget. Behaviour reverts under pressure. The team that was trained in March has different membership by December.

There is also an internal support load: the questions about why it said that, the requests to change behaviour, the misuse that has to be corrected. Somebody answers those.

What to ask for before you sign

What to ask for before you sign

A year-two operating estimate, itemised, with the people included.

• Projected inference cost at three times pilot volume. With the assumptions written down.
• Who updates the content, how often, and how many hours a week. The largest hidden cost, and the best single predictor of whether the system is still trusted at eighteen months.
• Who owns the evaluation set, and how often it runs. Without it you cannot distinguish an improvement from a regression, so every change becomes a matter of opinion.
• What is monitored, who reviews the samples, and on what schedule. Accuracy decays quietly, and the aggregate number can look fine while performance falls on new cases.
• What the vendor's support covers and what falls to your team. Whatever is not covered is a standing load on somebody in your organisation.
• What happens to all of the above if the person who built it leaves. A named owner, a budget line and a quarterly review is what separates a system still working at year three from one that quietly stopped being right.
• Under-scoping the first build to make the business case work. The saving is real and the running cost was omitted, so the programme is under water in year two and gets cancelled with the sunk cost intact. Better to fund a smaller thing properly.
• Treating it as a project rather than a service. Operational systems have running costs that nobody assigned an owner or a line item to.

A firm that cannot produce this has not run one of these past the first year, which is worth knowing before rather than after.

Source: Thinklytics AI readiness practice, 2026.

Ask for a year-two operating estimate, itemised, with the people included. Specifically:

1. Projected inference cost at three times pilot volume, with the assumptions written down. 2. Who updates the content, how often, and how many hours a week that is. 3. Who owns the evaluation set, and how often it runs. 4. What is monitored, who reviews the samples, and on what schedule. 5. What the vendor's support covers and what falls to your team. 6. What happens to all of the above if the person who built it leaves.

A firm that cannot produce this has not run one of these past the first year, which is worth knowing before rather than after.

Two cheaper ways to be wrong

Under-scoping the first build to make the business case work. The saving is real and the running cost was omitted, so the programme is under water in year two and gets cancelled with the sunk cost intact. Better to fund a smaller thing properly.

Treating it as a project rather than a service. A named owner, a budget line, and a quarterly review is the difference between a system that is still working at year three and one that quietly stopped being right some time in year two and nobody can say when.

The figure that actually matters

The figure worth tracking

• Build cost. Quoted. A pilot is funded as a project, with a budget, an end date and somebody's attention. None of that tells you what the system costs once it is operational.
• Cost per unit of work in year two. All in. Per document processed, per ticket deflected, per forecast produced, including the people who keep it alive.

Compared against the same figure for the current manual process, measured before anything was built. If nobody captured that baseline, the programme will never be able to prove it worked, whatever it does.

Source: Thinklytics AI readiness practice, 2026.

Not the build cost, and not the saving. Cost per unit of work, in year two, all in. Cost per document processed, per ticket deflected, per forecast produced, including the people who keep it alive.

Compared against the same figure for the current manual process, measured before anything was built. If nobody captured that baseline, the programme will never be able to prove it worked, whatever it does.

Frequently asked questions

What does an AI system cost to run after the build?

Six recurring costs. Inference and compute, keeping the content current, evaluation and regression testing, monitoring and drift, integration maintenance, and adoption and internal support. Four of the six are people rather than compute, and the people costs are the ones routinely missing from the business case.

Which running cost is most often forgotten?

Keeping the content current. A retrieval system is exactly as good as the corpus behind it, and policies, products, prices and SOPs all change. Somebody has to notice, update the source, remove the superseded version and reindex. In a mid-sized deployment that is regularly a day a week, and it is the best single predictor of whether the system is still trusted at eighteen months.

Why do inference bills come in higher than forecast?

Two reasons. Retrieval puts large amounts of context in front of the model on every call, and context is the dominant term. And chatty interfaces produce long conversations where the whole history is resent each turn. It is controllable with caching, smaller models for easy requests, context caps and per-team budgets, and uncontrollable if nobody owns it.

What is an evaluation set and why is it a recurring cost?

A fixed collection of real inputs with known-correct outputs that reruns on every change, yours or the vendor's. Building it is a one-off cost. Maintaining and running it is not. Without it you cannot distinguish an improvement from a regression, so every change becomes a matter of opinion.

How does AI accuracy decay without anyone noticing?

Inputs change character: a new product line, a new supplier, a new customer segment. Performance falls on the new cases while the aggregate number still looks fine. Input distribution monitoring, scheduled human sampling of outputs, and alerting on refusal and escalation rates catch it, because those move before accuracy does.

What should we ask for before signing?

A year-two operating estimate, itemised, with the people included. Projected inference at three times pilot volume with assumptions stated, who updates the content and for how many hours a week, who owns the evaluation set, what is monitored and by whom, what vendor support covers, and what happens if the person who built it leaves.

Which figure actually matters?

Cost per unit of work in year two, all in. Cost per document processed, per ticket deflected, per forecast produced, including the people who keep it alive, compared against the same figure for the current manual process measured before anything was built. If nobody captured that baseline, the programme can never prove it worked.