What AI automation actually costs — and what it doesn't

Every quote for AI work looks the same from the outside: a number, a timeline, and a paragraph about "leveraging cutting-edge models." What that number is actually buying is almost never explained, which is why two proposals for the same job can differ by a factor of five and both be defensible.

Here is what the money goes on, roughly in the order it gets spent.

The model is the cheap part

This surprises people. The API bill for a well-scoped internal assistant — one that answers questions from your own documents for a team of fifty — is usually a rounding error next to one engineer's monthly cost. Model pricing has fallen steeply and keeps falling.

So when you see a large number on an AI proposal, it is not paying for intelligence. It is paying for everything around the intelligence:

• Getting your data somewhere the model can reach it, in a shape it can use
• Deciding what the system is allowed to do on its own and what needs a human
• Making it fail safely when it is wrong, because it will sometimes be wrong
• Putting it in front of people in a way they will actually use

If a quote is mostly model costs, someone has mis-scoped the project. If it is mostly the four bullets above, it is priced honestly.

Where the budget really goes

Data plumbing: usually the largest line. Your knowledge does not live in one place. It is in a CRM, a shared drive, six years of email, a wiki nobody has updated since the last reorg, and three people's heads. Getting it into one queryable store — de-duplicated, permissioned, and kept fresh — is unglamorous integration work, and it is where most of the hours go.

The good news is that this cost is paid once and then reused. The second AI feature you build on the same foundation costs a fraction of the first.

Guardrails and evaluation. A demo that works on five questions tells you nothing about the fiftieth. Someone has to build a test set of real questions with known-good answers, run it on every change, and watch the failure modes. Skipping this is how you end up with a system that quietly got worse in March and nobody noticed until August.

The human handoff. Every serious deployment needs an answer to "what happens when the model doesn't know?" Escalation paths, confidence thresholds, an audit trail of what was said to whom. This is ordinary software engineering, and it is a large share of any responsible build.

Change management. The most common reason an automation project fails is not technical. It is that the six people who were supposed to use it kept doing the thing they had always done. Budget for training and for a fortnight of someone sitting with the team.

What you can skip

Plenty of AI budget goes on things you almost certainly do not need:

• A fine-tuned model. Retrieval over your own documents solves the overwhelming majority of business use cases, costs far less, and updates the moment a document changes. Fine-tuning is for teaching a model a format or a behaviour, not facts.
• Self-hosting. Running your own inference makes sense at a scale most companies never reach, or under a compliance rule that genuinely forbids the alternative. Otherwise it converts a small variable cost into a large fixed one, plus an on-call rota.
• A custom interface. If your team lives in Slack or Teams, the automation should live there too. A separate web app is a second place to remember to check, which means it is a place nobody checks.
• The rewrite. You do not need to replatform before you can automate. Almost anything with an API — and most things without one — can be reached where it stands.

A rough shape

For a first project, targeted at one well-defined process, most of the useful range sits between a few thousand and the low tens of thousands. What moves you within that range is not the sophistication of the AI. It is:

• How many systems have to be integrated, and whether they have APIs
• How clean the underlying data is
• How wrong the system is allowed to be, and what happens when it is
• How many people have to change how they work

Projects above that range are usually not one project. They are a platform, and they should be scoped and priced as a sequence with something useful shipping at the end of each step.

The question that prices the project

Before asking what an automation costs, work out what the current process costs. Not a guess — an actual number:

How many hours a week does someone spend on this, at what loaded rate, and what does it cost us when they get it wrong?

Multiply by fifty. That is your annual figure, and it is the only sensible thing to compare a quote against. A project that pays for itself inside a year is straightforward to justify. One that pays back in three is a strategy call, not a purchase. One where nobody can produce the number at all is not ready to start, and no amount of good engineering will fix that.

If you can produce that number, any competent firm can tell you within a call whether the work is worth doing. If a firm cannot tell you that, or will not, the number they quote is not the problem.