AI Integration Cost: A Budget Model to Copy

What are the lines of an AI integration budget?

AI integration cost has five lines: build, usage (tokens), infrastructure, evaluation, and people, plus a contingency reserve. Build is one-time. The other four recur every month. Most budgets fail because they fund the first line and treat the rest as rounding.

Here is the model to copy. Fill each line with your own volumes before anyone quotes you.

• Build and integration (one-time). Driven by the number of systems touched, data cleanup and security review. Estimate it as a fixed scope per workflow, quoted separately.
• Token usage (monthly). Driven by requests per day × tokens per request × provider rate. Multiply, then add a growth factor.
• Infrastructure (monthly). Driven by vector store, queues, logging, hosting and any GPUs. Use provider calculators at year-2 volume.
• Evaluation (monthly). Driven by test set size, review hours and regression runs. Estimate hours per release × releases per month.
• People (monthly). Driven by the owner, on-call, and prompt and data maintenance. Estimate a fraction of a named engineer's time.
• Contingency (reserve). Covers volume spikes, model changes and scope creep. Hold it back rather than allocating it.

Keep the lines separate. A single blended number hides which line is growing. When usage doubles, only the token line moves, and separate lines let you see that. They also let a vendor quote the one-time work on a fixed scope, and they give finance a way to ask about one line without reopening the whole budget.

Build cost vs run-rate: where the money goes

Build cost is paid once and is easy to compare across vendors. Run-rate is paid monthly for as long as the system lives. Treat them as two budgets with two owners.

Build covers integration with your CRM, ERP or document stores, data preparation, the first prompt and retrieval design, security review and launch. If the integration work is substantial, it is closer to custom software development than to a plug-in, and it should be scoped that way. It is the number on the proposal, so it gets negotiated hardest. It is also the line with the most predictable scope.

Run-rate begins on launch day and does not stop. Gartner predicted in 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value.

Escalating cost can come from either side of the budget. Run-rate is the likelier culprit, because it is the part nobody priced at approval. That is an inference from how the lines behave, not a measured finding.

If you are comparing vendors, ask each one for a year-2 monthly run-rate estimate alongside the build scope. A vendor who will not give one is leaving the hard part to you. Total cost of ownership accumulates in that run-rate, so it belongs in the comparison from the first proposal.

What does the monthly run-rate include?

Monthly run-rate is tokens plus infrastructure plus evaluation, with people covered in the next section. Tokens scale with volume, infrastructure with data size and uptime, and evaluation with how often you change the system. Each can be estimated before you build.

How do you estimate and reduce token spend?

Start with arithmetic, not a rate card. If a support-triage workflow handles 10,000 requests a day at 3,000 input tokens each, that is 30 million input tokens a day, before output tokens. Multiply by your provider's published per-million-token rate, which changes often, so read it from the pricing page on the day you budget.

Two levers are documented by the providers. Anthropic's prompt caching documentation states that cache reads are billed at a fraction of the base input price, which matters when every request repeats a long system prompt. Its batch processing guide and OpenAI's Batch API guide both describe a 50% discount for asynchronous work that can wait up to 24 hours.

Model routing is the third lever. The FrugalGPT paper reports that cascading queries across models of different size can match a top model's quality at a large cost reduction on the benchmarks it tested. Treat that as a direction to test on your own data, not a promise.

What does evaluation cost?

Evaluation is reviewer time plus compute. You need a fixed test set, a scoring method, and a regression run before each prompt, model or data change. Budget hours per release multiplied by releases per month. It is the line teams skip, and the one that tells you whether the system is getting worse.

Who carries the people cost after launch?

AI integration does not remove headcount from the budget. It moves it: someone owns quality, someone handles incidents, and someone keeps the underlying data current. Name these roles before launch, even if each is a fraction of one person. People is a recurring line like the others, so it belongs in the monthly total.

Which roles do you need to name?

You need a product owner who defines what a correct answer is, an engineer who can debug retrieval and prompts, and a domain reviewer who samples outputs. Each can be a fraction of a person, and the fractions depend on volume and release cadence, so estimate them from your own workload rather than from a rule of thumb. If nobody is named, the system drifts and the first signal is a customer complaint.

Where does a partner fit, and what about training?

Some teams cannot spare that engineer. A partner can carry the maintenance under a scoped support arrangement, or a fractional CTO can own the architecture and vendor decisions without a full-time hire. Either way, the cost is real. It is only a question of whose payroll carries it, so put a figure on it in the budget rather than leaving it as unpaid goodwill from an existing team.

Training belongs in the same line. The people who use the system need to learn when to distrust it. Budget a few hours of onboarding per user group and a feedback channel into the evaluation set. Without that channel, your best test cases are lost in support tickets.

How do year 1 and year 2 totals compare?

Year 1 is build plus a partial year of run-rate plus the reserve. Year 2 is a full year of run-rate with no build. Any time your team spends learning a first deployment belongs in the people line, so count it there.

Here is an illustration with the total year 1 budget indexed to 100 units, assuming a three-month build and nine months of run-rate in year 1:

• Year 1: build 45, run-rate 40 over nine months, reserve 15. Total 100.
• Year 2: run-rate 55 over twelve months, reserve 8. Total 63.
• Monthly run-rate: about 4.4 units in year 1 against about 4.6 in year 2.

Year 2 is lower than year 1 in absolute terms. Its monthly run-rate is higher, though, because year 2 pays for twelve months of usage at adoption volume. These figures are planning assumptions, not measurements.

Why model year 2 before approving year 1?

Approval decisions are made on year 1, and regret arrives in year 2. A pilot at 500 requests a day looks cheap. The same system at 20,000 requests a day, after other teams ask to use it, has a very different token and review bill. Run the model at the volume you expect after adoption, not the volume you launch with.

Build drops out between the two years. Token spend rises with adoption. Evaluation shifts from setting up test sets to maintaining them, and infrastructure grows with the size of your indexed data. Providers also retire models, so plan one migration and re-evaluation cycle per year, which is a recurring line, not an incident.

When you present this to finance, show three columns: build, year 1 run-rate, year 2 run-rate. Put the contingency reserve on its own row. Finance teams accept a recurring line far more readily when it is labelled and capped than when it appears as a surprise at renewal.

Three budget tiers: how the split changes with scope

The larger the scope, the smaller the share that goes to build and the more that goes to running and checking the system. The three tiers below show that shift as percentages of an annual envelope. They are illustrative allocations, not quotes, and not measurements from any deployed system. Apply them to whatever total your own volumes produce.

Tier 1: one narrow workflow

• Build: 50%
• Usage and infrastructure: 20%
• Evaluation: 15%
• Reserve: 15%

This funds one workflow, one hosted model API, no fine-tuning and no new infrastructure. It suits a single document-handling or triage task where a human still approves outputs. Build dominates because there is little to run yet.

Tier 2: one workflow done properly

• Build: 45%
• Usage and infrastructure: 25%
• Evaluation: 15%
• Reserve: 15%

This buys integration with one or two internal systems, a retrieval layer, a proper test set and monitoring. A partner or an internal team can deliver it, and the evaluation line is what makes it production-grade.

Tier 3: two or three workflows on shared plumbing

• Build: 40%
• Usage and infrastructure: 25%
• Evaluation and operations: 20%
• Reserve: 15%

The saving comes from shared components: one retrieval layer, one logging and evaluation setup, one access model. If you need that plumbing run continuously, treat operations as its own line rather than hiding it inside build.

What do you cut when the CFO halves it?

Cut scope, not evaluation. Fewer workflows, a smaller first release and human approval in the loop all reduce cost safely. Removing testing, monitoring or the reserve saves money now and creates the incident that costs more later.

What is safe to cut, and what is not?

Cut the number of workflows first. Cut the integration count: start with one source system and export the rest. Cut real-time requirements: batch processing is documented at a 50% discount by both Anthropic and OpenAI, and many back-office tasks do not need an instant answer. Defer fine-tuning, since prompting and retrieval usually get you most of the way.

Never cut the test set, the named owner, or the contingency. A system without a test set cannot show whether a model change helped or hurt. A system without an owner decays quietly.

If the budget is still too small, shrink the experiment, not the standard. Test one workflow with real users before committing the larger budget. A narrow release also gives you real usage numbers to put into the model above, which is more reliable than any estimate made before launch.

What is the next step?

Put your own volumes through the five lines, then pressure-test the result against the year-2 case. To see where automation fits in your current process before you size anything, take the broken workflow assessment and bring the output to a scoping conversation.