The model is the cheap part
Clients expect the model to dominate the cost. It rarely does. Model usage for a typical business workload is pennies per unit of work; the build is where the money goes, and within the build it is not the AI call.
The expensive parts are what makes the AI usable: knowing whether it is right, letting a human correct it, and handling the times it is not available.
Where the build cost sits
| Component | Share | Why |
|---|---|---|
| Specification and evaluation set | 15–25% | Agreeing what correct means, with real cases |
| Core build | 35–45% | The pipeline, retrieval, prompting, integration |
| Review and correction interface | 15–25% | Frequently cut, and it determines adoption |
| Failure handling and monitoring | 15–20% | Degradation, cost caps, quality drift alerts |
The review interface is not optional
A review interface that takes ten seconds an item makes a 20% review rate workable. One that takes two minutes means people start approving without looking, and then you have automated the appearance of checking.
It is the first thing clients ask to cut and the last thing we agree to.
Running costs
- Model usage — typically pennies per task; measure per completed task, not per token
- Retrieval infrastructure — embedding, storage, re-embedding when documents change
- Human review, which is usually the largest running cost in the first quarter
- Evaluation — rerunning the test set on every change, which needs to be automatic
- Maintenance at 20–30% of build annually, higher than conventional software because quality drifts
What you can cut
Scope: one document type instead of four, one user role instead of three, one language instead of five. The admin interface deferred. Historical backfill skipped.
What we will not cut: the evaluation set, the review interface and the failure handling. Without those you cannot tell whether it works, fix it when it is wrong, or keep it running.