What it costs to keep an AI system running after go-live

Running an AI system costs four things: cloud and model usage, maintenance hours, ownership and coordination, and retraining where a trained model is involved. For most business workflows the infrastructure lands in the tens of euros a month and the maintenance hours are the larger line, which is the opposite of what most budgets assume.

That inversion matters more than it sounds, because it is what turns a sound business case into a rejected one. Gartner expects that more than forty percent of agentic AI projects will be cancelled by the end of 2027, and the first reason on their list is escalating costs. Escalating usually means unbudgeted rather than enormous. Something recurring was treated as a one-off.

This article sets out what each line is actually worth, where the estimates go wrong in both directions, and what belongs in a support agreement so the running commitment is visible before you sign for the build.

Why do running cost estimates go wrong?

Because two of the four lines are misjudged in opposite directions, and the errors do not cancel out.

Infrastructure gets overestimated. On a recent project the client had budgeted roughly two hundred euros a month for the Azure components and our engineer put it closer to sixty, because the workload was event-driven rather than continuously running. That difference is not negotiation, it is architecture: a workflow that wakes up when a document arrives consumes a fraction of a service that polls all day. Nobody had done anything wrong, they had simply priced the shape of system they were used to.

Maintenance gets underestimated, usually to zero. The assumption is that a finished system is finished, and AI systems are less finished than most software because their inputs keep moving. A supplier changes an invoice layout, a source system gets upgraded, a rule changes, a new document type appears in a stream that was stable for a year. None of those are defects and all of them are work.

There is a third pattern that is harder to see. The costs that appear at handover, such as hosting, credentials and repository access, do not belong to either the build or the run in most contracts, so they end up unowned until somebody needs them.

What are the four cost lines?

1. Cloud and model usage is the line everyone thinks of first and it is usually the smallest. The main variable is not volume but architecture. Event-driven processing, where the workflow is triggered by an incoming document or message, is cheap because nothing runs between events. Continuously available services cost considerably more, and so do compute-heavy workloads. A routing optimisation that runs a thirty-minute solve is a different cost profile from a document classifier, and it is worth knowing which of the two you are building.
2. Maintenance hours is the line that dominates for most systems. It covers changes driven by the outside world, small improvements that come out of use, and the occasional incident. A workable planning assumption is a modest number of engineering hours a month at a normal rate. For reference, a senior engineering hour in the Dutch market sits around a hundred and fifty euros, so even a few hours a month is a larger number than the infrastructure line.
3. Ownership and coordination is real work that rarely appears in a budget. Somebody has to decide what happens when an exception pattern shows up, prioritise change requests and judge whether output quality still holds. As a rule of thumb we allow around ten percent of development effort for project management during a build, and something in that region applies afterwards for the smaller but continuous business of deciding things.
4. Retraining and evaluation applies only when a model was actually trained on your data. Prompt-based solutions built on a general model do not retrain, although they still need re-evaluation when the underlying model version changes, which is a real event with real consequences. Where a trained model is involved, the loop of retraining, evaluating and redeploying is recurring work that needs a home, and building the pipeline for it is part of going to production rather than an afterthought.

How should you estimate before you have any of this running?

Start from the shape of the system rather than from a percentage of the build cost, because the ratio between build and run varies enormously.

Three questions get you most of the way. Does the system wait for events or run continuously? Does it depend on external formats that other parties control, such as supplier documents or partner systems? And does it involve a model trained on your own data? A yes to the first and no to the other two describes the cheapest possible profile. A no, yes, yes describes something you should budget properly.

Volume matters less than people expect, once the architecture is settled. A process handling several hundred documents a week and one handling several thousand often sit in the same cost band, because the fixed costs dominate and the per-item cost is small. That is worth checking early, because volume anxiety sometimes stops projects that would have been affordable.

One number that does scale is the human review step. If a person checks a proportion of the output, that proportion is a running cost in salary terms and it usually exceeds every other line combined. Designing the review step so it shrinks as confidence grows is therefore a cost decision as much as a quality one.

What belongs in a support agreement?

Five things, and the fifth is the one that causes arguments when it is missing.

1. Scope of covered changes, stated as categories rather than a list, so that “supplier changes their layout” is clearly in and “add a second language” is clearly out.
2. Response time for incidents, with a definition of what counts as one.
3. Who may raise a request, because an open channel turns into an unmanaged backlog.
4. A monthly hour allowance with a stated rate for anything beyond it.
5. Whether model and infrastructure consumption is billed through or included, which is the most common source of disagreement precisely because it is the line nobody discussed during the build.

Worth noting is that support agreements are a relatively recent addition to AI work. In our own proposal archive they only start appearing in 2026, alongside implementation projects, and their arrival is a reasonable signal that the market has moved past experimentation. A client asking about uptime is a client who intends to depend on the thing.

Which costs only appear at handover?

Three, and each of them is cheap to arrange in advance and awkward to arrange afterwards.

1. Hosting is the first. A solution transferred as source code moves onto the client’s own infrastructure, which means somebody has to run it there, and that is a different arrangement from the build contract. It can be arranged either way, but the assumption gap is real: the supplier assumes the client will host, the client assumes hosting was included.
2. Repository history and logs are the second. These are often outside standard project scope, ours included, and nobody thinks to ask until an audit or a debugging session needs them. Deciding this before the final invoice costs nothing.
3. Credentials and access are the third. An application nobody can authenticate into has not really been handed over, and service accounts created during development have a habit of belonging to the person who created them.

The useful test for all three is whether a competent engineer who has never seen the system could deploy it, run it and fix a common failure using only what was handed over. If that needs a phone call, the handover is incomplete and the cost of that call has just become somebody’s problem.

How does this fit the wider picture?

The gap between building AI and operating it is now the defining constraint in enterprise adoption. Deloitte surveyed more than three thousand leaders across twenty-four countries for its 2026 State of AI in the Enterprise report and found twenty-three percent using agentic AI at least moderately today against seventy-four percent expecting to within two years, while only twenty-one percent have a mature governance model for those agents. Governance and running cost are the same problem seen from two angles: both are about what happens after the demo.

The practical conclusion is unglamorous. Ask for the running cost during the proposal rather than after go-live, insist that it is broken into the four lines rather than quoted as a single monthly figure, and treat a supplier who cannot produce that breakdown as a supplier who has not run many systems.

The one question worth asking early

Before a build starts, ask what this will cost to keep running in year two. A supplier who answers with four lines and a range has thought about it. A supplier who answers with a single number, or with reassurance, is quoting the build and hoping the rest sorts itself out.

The answer does not need to be precise at that stage. It needs to exist, because a business case that only counts the build is not a business case, it is an invoice with optimism attached.

Frequently asked questions (FAQ) about AI running costs