What drives the cost of an AI automation project
The model call is the cheapest part. The seven factors that decide what an automation project costs to build and run, and the two that most estimates leave out.
The short answer
The model call is the cheapest part of an AI automation project and the only part most demos show. What actually decides the cost is everything around it: how clean the data is, how many systems must be connected, how high the stakes are and therefore how much guardrail and review design is needed, how much evaluation work it takes to know it works, what it costs to run each month, and how much effort it takes to change how people work. Two of those are left out of most estimates: the ongoing monitoring and maintenance, and the time of your own people who label cases and review exceptions. There are no amounts here on purpose; the factors are what you can control.
The seven drivers
| Driver | What raises the cost | What lowers it |
|---|---|---|
| 1. Data state | Documents scattered, duplicated, stale; fields empty; no source of truth | One clean, current source per topic |
| 2. Integrations | Several systems, weak APIs, two-way sync, money involved | One system, a good API, read-mostly |
| 3. Stakes | Customer-facing, financial, regulated: strict guardrails, validation, audit | Internal, reversible, low consequence |
| 4. Evaluation | Many categories, subtle judgement, expert labelling needed | A narrow task with clear right answers |
| 5. Review design | Complex exception handling, many roles, custom screens | A simple queue with approve, edit, reject |
| 6. Running costs | High volume, large inputs, expensive model everywhere | Small models for routine steps, caching, minimisation |
| 7. Change management | New ways of working for many people; resistance | One team, a clear benefit, early involvement |
Where the budget actually goes
- Understanding and data: mapping the process, finding the data, cleaning what must be cleaned. Frequently a third of the build.
- Integration: connecting to the systems where the inputs live and the outputs go, with error handling and idempotency.
- Guardrails and review flow: the layers that make it safe and the screen where a person handles exceptions.
- Evaluation: building the case set with your experts, running it, iterating until it clears the bar.
- The model and prompt work: smaller than expected.
- Launch and adoption: training, changing procedures, the first weeks of close watching.
- Running: usage, hosting, monitoring, monthly reviews, updates.
Making it cheaper without making it worse
Pick a first project with clean data, one integration, low stakes and a clear right answer. Use a small model for routine steps and the strong one only where measured. Keep the review flow simple. Let your experts label the evaluation cases early, when it is cheap, not late, when it is a rescue. Budget the monthly running line from the start. These choices usually cut the cost by more than any negotiation on the model price.
What this means for you
Budget the system, not the model. Data state, integrations, stakes, evaluation, review design, running costs and change management decide the price, and you influence all seven by which project you choose and how you scope it. Insist that quotes show each, including the monthly line and your own people’s time. The projects that pay back are the ones budgeted that way from the start.
Frequently asked questions
Why is the quote so much more than the model's price?
Because the model is a component and the project is a system: connecting to your tools, cleaning and indexing your data, building guardrails and a review flow, testing against real cases, monitoring, and helping people change how they work. Each is real work. The model call is the part vendors show; the rest is the part that makes it dependable.
What makes one automation cheap and another expensive?
Mostly stakes and integrations. A system that drafts internal summaries from clean documents, reviewed by a person, is cheap. A system that reads invoices from many suppliers, matches them to orders in an accounting system and posts them with money attached needs data work, integrations, strict guardrails and a careful review flow. Same technology, very different projects.
What are the running costs after launch?
Model usage at your volume, hosting for the application and index, monitoring, a monthly quality review, document refreshes, retests after model updates and small changes as the business moves. Budget a steady monthly line; an automation with no running budget is one that will decay.