What an AI system actually costs over three years

Most AI business cases compare one number against one benefit: the build quote against the hours it saves. Both numbers are usually wrong in the same direction, and the build quote is the smaller mistake.

A system that runs for three years costs money in nine places. Six of them arrive after the invoice you approved, which is why the second year is where projects are quietly abandoned rather than the first.

The nine lines

Put these in a sheet, one column per year, before you approve anything.

1. Build. The quote. The only line most people have.
2. Integration surface. Every external system the thing touches is a standing liability, because every one of them changes on its own schedule. Two systems is a build. Six is a commitment.
3. Hosting and infrastructure. Servers, storage, the database, the queue, the monitoring stack. Small, predictable, and usually the only recurring line people remember.
4. Model usage. Per-token or per-seat, and it moves with volume rather than with headcount. Worth modelling at three volumes: today, plausible growth, and the accident (a loop that retries, a batch job pointed at the wrong dataset).
5. Monitoring and alerting. Not the tooling cost, the human one: somebody has to receive alerts and act on them. An unmonitored system is cheaper on paper and more expensive in practice.
6. Maintenance. Dependency updates, API versions being retired, authentication changes, a connector that stops working because a vendor shipped a redesign. This is a recurring line, not a contingency.
7. Model drift and re-testing. Covered below, because it is the line nobody has seen before.
8. Change requests. The process will change. Every change to how the work is done is a change to the system, and after the first year those are the bulk of the spend.
9. Internal time. The person who reviews the output, handles the exceptions and owns the thing. Automation moves work, and the work it moves has a salary attached.

If you want one planning assumption rather than a sheet: treat the build as the first year's cost and assume the following years are not free. That single correction changes more business cases than any refinement of the model pricing.

Model drift, in concrete terms

A prompt is written against a model. Then the provider updates that model, or retires the version you pinned, and the same prompt produces slightly different output. Nothing broke, nothing threw an error, and the classification that used to be right 97 times in 100 is now right 92 times in 100. Nobody notices until someone downstream complains about the numbers.

That is the recurring cost: a test set of real cases with known answers, re-run whenever a model or a prompt changes, plus the work of fixing what the test set catches. It is not large, but it is permanent, and a system without it does not degrade visibly. It degrades quietly, which is worse.

Deprecation is the harder version. Providers publish end-of-life dates for model versions, and when one arrives you migrate on their timetable rather than yours. Budget a re-test and a small migration per year for anything model-based, in the same spirit as certificate renewals.

The cost of breaking quietly

Ask what the system does when a step fails. There are three possible answers and only one is acceptable.

It stops and tells someone. Fine. It stops silently. Recoverable, because the gap is visible eventually. Or it continues with wrong data, which is the expensive one: a pipeline that writes plausible but incorrect records for three weeks does not cost you three weeks of downtime, it costs you the remediation, the reconciliation and the trust of whoever made decisions on those numbers in the meantime.

Price that scenario before you build. If the answer is that nobody would notice for a fortnight, the monitoring line in your sheet is too small, and it should grow until somebody would notice the same day.

A worked example, entirely hypothetical

Suppose a workflow runs every five minutes. That is 12 runs an hour, 288 a day, roughly 8,640 a month. Now suppose a step fails intermittently and retries three times before giving up. Your usage has quadrupled on the failing path, silently, and you find out through the invoice.

The arithmetic matters more than the numbers. Recurring cost scales with runs, not with users, and schedules are set once and rarely revisited. Before you sign anything with usage-based pricing, multiply the schedule out and add a retry factor. Before you sign anything with per-seat pricing, do the same exercise against your hiring plan, because per-seat costs scale with the team while the value often does not.

When a full cost model is the wrong approach

For a genuine experiment, this exercise is theatre. If you are spending a week to find out whether something works at all, timebox it, accept that it may be deleted, and do not dress it up as an investment case.

The same goes for small internal tooling. A script one person uses to save themselves an hour a week does not need a three-year view, and demanding one is how organisations end up with no tooling at all.

And if the process is still changing every quarter, the cost model is not your problem yet. Whether to automate at all comes first, because an accurate three-year cost for the wrong build is still the wrong build.

What the sheet is really for

Two things, and neither is precision.

The first is comparison. A per-seat tool, a no-code workflow and a custom build have completely different cost shapes, and they only become comparable across three years. A subscription that looks expensive is often the cheapest total, and a build that looks expensive stops looking that way at volume. The honest version of that comparison is in no-code automation versus a custom build.

The second is ownership. Filling in line nine forces the question of who runs this thing when the person who asked for it moves on. If that line is empty, the project has a problem no budget fixes.

A shortlist of what is worth building, with the costs that follow it, is the point of the audit and advisory work we do before anything gets built, and the rest of the comparison guides cover the individual trade-offs.

Frequently asked questions

What share of the total is the initial build?

There is no reliable industry ratio, and anyone quoting one is selling something. Build the sheet for your own system instead: the recurring lines are driven by how many external systems you touch and how often the process changes, and both of those you already know.

How do we budget for maintenance we cannot predict?

Put a fixed recurring amount in the sheet rather than a contingency, and review it annually against what was actually spent. Teams that budget maintenance as a percentage of the build tend to be closer than teams that treat each fix as an unexpected event.

Does a fixed-price build protect us from this?

It protects you during the build. Nothing about a fixed price changes what happens in year two, when an API version is retired or the process changes. Ask what support looks like after handover, and what it costs, before you compare quotes.

Is it cheaper to keep paying per seat?

Often, yes, especially for a stable team using a tool that fits. Owning a system pays off when the seat count grows, when the tool almost fits but not quite, or when the data cannot sit in someone else's product. Do the three-year arithmetic against your actual headcount plan rather than the list price.