What an AI project actually costs in 2026
A line-by-line budget for an AI build — discovery, data work, model spend, engineering and the running costs nobody quotes for.
Almost every AI budget we see is wrong in the same direction: the build is estimated carefully and everything around it is estimated at zero. The model call is the cheap part. The expensive parts are getting data into a usable state, proving the thing works, and keeping it working after launch.
Here is how the money actually splits on a typical production AI feature, and which lines get underestimated most.
Where an AI budget actually goes
Typical split on a production AI feature. Data work is the line most often underestimated — frequently budgeted at 10%.
- Engineering40%
Retrieval, orchestration, interface, integrations
- Data work35%
Extraction, cleaning, labelling, pipeline
- Evaluation12%
Eval harness, golden sets, regression runs
- Discovery8%
Workflow mapping, data audit, success metrics
- Deployment & ops5%
Monitoring, cost controls, runbooks
Discovery: 5–10% of the budget, and it saves the rest
Two to three weeks of structured discovery — mapping the workflow, auditing the data, agreeing what 'good' means numerically — is the cheapest insurance you can buy. It is also the line most often cut. Projects that skip it do not save the money; they spend it later rebuilding on assumptions that turned out to be wrong.
The output should be concrete: a target metric, a baseline for it, a data inventory with known gaps, and a written definition of the failure modes you will not tolerate.
Data work: routinely 30–40%, usually budgeted at 10%
This is where estimates break. Extraction from legacy systems, cleaning, deduplication, labelling, and building the pipeline that keeps it fresh — none of it is glamorous and all of it is on the critical path.
If your documents live in scanned PDFs, or your product data is spread across three systems with different identifiers, that reconciliation is the project for a while. Better to see it in the plan than discover it in week five.
Engineering: 35–45%
The application around the model: retrieval, orchestration, the interface people actually use, integrations with the systems of record, authentication, audit trails. For most business AI, this is a normal software project with a model in the middle.
Evaluation: 10–15%, and treat it as a deliverable
You cannot ship what you cannot measure. An eval harness — a curated set of cases with expected outcomes, scored automatically on every change — is what lets you improve the system without guessing. Teams that skip it end up shipping on vibes and rolling back on complaints.
The running costs nobody quotes
Inference is metered, so your unit economics change with usage. Beyond tokens, budget for monitoring, periodic re-evaluation as models change underneath you, prompt and retrieval maintenance as your content changes, and a support path for the cases the system gets wrong.
- Model/inference spend, which scales with adoption rather than headcount
- Vector store and infrastructure hosting
- Re-running evals when a provider ships a new model version
- Human review capacity for low-confidence cases
- Content and prompt maintenance as the underlying business changes
Costs that show up after launch
Budget for these
- Inference spend, which scales with adoption not headcount
- Re-running evals whenever a provider ships a model
- Human review capacity for low-confidence cases
- Prompt and retrieval maintenance as the business changes
Commonly forgotten
- Vector store and infrastructure hosting
- A support path for the cases it gets wrong
- Re-embedding when you change embedding models
- Someone owning the thing after the build team leaves
A sane way to phase it
Fund a two-week discovery. Then fund a narrow pilot against one measurable workflow, with the eval harness built in. Only then commit to the full build, priced against evidence rather than a slide. If a vendor will not work this way, that is information.