Insights

What AI automation actually costs (the line items nobody quotes)

By Darshan R Krishnan · 11 August 2026 · 7 min read

When someone asks what an AI automation costs, they mean the build. What will you charge to make the thing.

That number is real, and it's usually the smallest of the costs involved. The rest don't appear in the proposal — not because anyone's hiding them, but because they land later, on different budgets, and never get added back to the original figure. So the automation gets judged against the build cost alone, which is a bit like judging a mortgage on the deposit.

I run delivery at a company that builds these systems, so this is me arguing partly against my own commercial interest. But a client who understands the real cost buys the right things and stays a client. A client who only sees the build cost buys the wrong things, gets disappointed, and blames the technology. The second outcome is worse for everyone, including the vendor.

Here's what's actually in the number.

The build (the part you're quoted)

The visible cost. Design, development, testing, deployment. For most business automations this is genuinely well-understood and increasingly commoditised — models are capable, tooling is mature, and a competent team can scope it accurately.

Precisely because it's the understood part, it's the part people over-focus on. They negotiate hard on the build quote and pay no attention to the four costs below, which are larger and where the actual risk lives.

Integration with what you already have

An automation almost never operates in isolation. It has to read from systems you already run and write to others, and those systems were not designed to be integrated with. They have quirks, undocumented behaviours, permissions nobody fully understands, and an owner who left two years ago.

This is routinely the most underestimated line item, because it's invisible until you're inside it. The automation itself might be simple; connecting it to a fifteen-year-old system of record that has three sources of truth for the same field is where the time goes. And you often can't see this cost accurately until you've started — which is an uncomfortable thing to tell a client who wants a fixed number up front, but pretending otherwise just relocates the surprise to later.

Verification, forever

Covered this in the piece on why automations fail, because it's that central: most automations don't remove human work, they convert it into checking work. And checking work is a permanent operating cost, not a one-time build cost.

Someone verifies the outputs. Someone handles the cases the system declines. Someone corrects the confident errors. Depending on how wrong a wrong answer can be, this ranges from a light touch to a substantial ongoing commitment — and it's ongoing, which means over any reasonable time horizon it can exceed the entire build cost and keep going.

The honest way to quote an automation includes an estimate of the steady-state verification load. "This will save X hours of doing and add Y hours of checking" is the actual proposition. If a vendor won't give you Y, they're either inexperienced or hoping you won't ask.

Maintenance as the world moves

An automation is built against how things work today. The world it operates in keeps moving — the business changes its process, an upstream system updates, a rule changes, the shape of the input drifts. Every one of those requires the automation to be updated, or it silently degrades.

This cost is invisible at build time and shows up distributed across many small updates that never get totalled. Nobody computes the annual maintenance cost of an automation. If they did, some automations would clearly cost more to keep current than the manual process they replaced — especially for processes that change often. The faster your process changes, the more this dominates, and the more a "cheaper" rigid build turns out to be the expensive option.

Adoption and the productivity dip

New systems are slower before they're faster. There's a period — sometimes weeks — where the people using the automation are less productive than they were, because they're learning it, distrusting it, working around it, and doing both the old and new way while they build confidence.

This is a real cost and it's almost never budgeted. Worse, it's when most automations get abandoned: the dip arrives, someone concludes it's not working, and the plug gets pulled right before the point where it would have started paying off. Naming the dip in advance — "productivity will drop for roughly N weeks, this is expected, don't panic and don't cancel" — is one of the cheapest and highest-return things you can do, and it costs nothing but candour.

Putting it together

A rough and honest way to think about total cost:

Total cost ≈ Build
           + Integration        (often ≥ build, hard to see up front)
           + Verification × time (permanent operating cost)
           + Maintenance × time  (scales with how fast your process changes)
           + Adoption dip        (one-time, front-loaded, unbudgeted)

None of this is an argument against automation. Plenty of automations are worth several times their total cost — but you can only know that if you're comparing against the total, not the build. The projects that disappoint are almost always the ones justified against the build cost alone, where the other four line items quietly ate the return.

The question to ask a vendor isn't "what does it cost to build?" It's "what does it cost to run for two years?" A vendor who can answer that clearly is one worth working with. A vendor who's never thought about it is telling you something.