Budget the engineers first. On most enterprise AI builds, 70% to 85% of first-year spend is engineering time, and the model bill is small enough to sit inside the rounding error. If a quote is dominated by licences, GPUs or a “platform” line, either your workload is unusual or somebody has repackaged labour as software.
That single fact tells you how to control the number. You are not buying a product with a price. You are buying a quantity of senior engineer-days, and everything that moves the cost moves it by changing that quantity.
The four lines in an AI budget
| Line | Share of year one | What moves it |
|---|---|---|
| Engineering time | 70-85% | Team size, elapsed weeks, day rate |
| Inference and model API | 5-15% | Requests per day, prompt length, model tier |
| Data platform and infrastructure | 5-10% | Whether a warehouse already exists |
| Evaluation, monitoring, rework | 5-10% | Accuracy target, regulatory exposure |
The shares only invert when you serve high-volume consumer traffic or train your own models on your own hardware. Almost nobody reading this does either. For an internal assistant, a document pipeline or a scoring model, labour dominates and keeps dominating.
Sizing the labour line
Cost equals team shape multiplied by elapsed weeks multiplied by day rate. Three shapes cover most first builds:
- Retrieval assistant over one document set, one business domain: two engineers, 10 to 14 weeks.
- The same assistant across three source systems with real access control and an automated evaluation suite: three engineers, 16 to 22 weeks.
- Production model with a feature pipeline and scheduled retraining: two ML engineers plus a data engineer at half time, 14 to 20 weeks.
A two-engineer, twelve-week build is roughly 120 engineer-days. Multiply by the day rate you can actually contract at, not the one you wish existed. Senior AI engineering in London, Munich or Amsterdam typically costs 1.8 to 2.5 times the Eastern European equivalent at the same seniority; our current day rates by role show where the band sits this quarter, and the project cost calculator turns a team shape into a monthly figure.
What doubles an estimate
Four things, in descending order of how often they catch buyers out.
Data readiness. If the source data has no owner, no schema documentation and no reliable refresh, the first four to eight weeks are data engineering, not AI. This is the single most common reason a twelve-week estimate becomes a twenty-four-week invoice.
Then the accuracy target. Moving a retrieval system from roughly 80% acceptable answers to 95% often costs as much again as reaching 80% did, because the work shifts from building to measuring, chunking, reranking and repair. The components of a RAG system each have their own failure mode, and you find them one at a time.
Integration surface adds two to four weeks per additional source system with its own authentication model. Compliance adds 10% to 20% when you need a DPIA, EU AI Act classification and audit logging that survives review.
What it costs to keep running
Plan for annual run cost of 15% to 30% of the build, plus inference. Models get deprecated, prompts drift as the underlying documents change, and every new content source needs its own evaluation set. Teams that skip automated evaluation to save four weeks pay for it here, usually within two quarters, because they cannot tell whether a change made the system better or worse.
Inference itself is easier to forecast than most people expect: requests per day times average prompt and response length times the published price per million tokens. Prompt length, not request volume, is what usually surprises the finance team.
Where fixed price stops helping
A fixed-price quote for AI work carries contingency of roughly 25% to 40%, because the vendor is pricing your unresolved data problems as their risk. You pay that premium whether or not the risk materialises. Time and materials moves the risk back to you, which is only sensible if you have someone technical who can read a burn-down. The trade-off is set out in our comparison of managed services against staff augmentation.
When renting engineers is the wrong answer
Three cases. If you want one fixed deliverable with no ongoing ownership and you genuinely cannot supervise the work, buy an outcome and pay the contingency. If your requirement is a commodity that a licensed product already solves, buy the product; a bespoke build will cost more and do less. And if you are pre-seed with no data and no internal engineer, hire one permanent person before you rent four.
Otherwise, decide the team shape, get a defensible day rate, and treat the rest of the budget as a small tax on top.