What an Enterprise AI Project Actually Costs

Asking what an AI project costs is a bit like asking what a building costs, the honest answer starts with questions. But the refusal to give any figure at all is one of the reasons buyers find this market difficult, so this article sets out the shape of the spend, the ratios we see repeatedly, and the items that surprise people.

We have deliberately written this in proportions and effort rather than in a currency. Rates vary enormously by geography and by whether you are buying a team, a firm or a brand; the distribution of effort is much more stable than the price.

The five buckets

1. Discovery and feasibility, 5–10%

Data audit, feasibility testing against a real sample, target architecture, and a cost and benefit model. Two to four weeks. This is the cheapest phase and the one with the highest return, because it is the only point at which the answer "don't build this" is still inexpensive.

Skipping it does not save 5–10%. It moves the same discovery work into the build phase, where it costs several times as much and arrives with a deadline attached.

2. Data engineering, 25–40%

Consistently the largest single bucket and consistently the most underestimated. This covers access and permissions, pipeline construction, cleaning, deduplication, entity resolution across systems that disagree, historical backfill, and, where labels do not already exist, annotation.

If someone quotes you an AI project where data engineering is under 20% of the effort, either your data estate is unusually good or the estimate is optimistic. It is rarely the former.

Annotation deserves particular attention because it is often invisible in early estimates. A computer vision project needing thirty thousand reviewed images, or a document extraction project needing several thousand verified field-level labels, carries a real cost, frequently one that must be paid in your domain experts' time rather than in cash.

3. Model development, 15–25%

The part everyone pictures when they think about an AI project, and rarely the largest. Feature engineering, model selection, training, tuning, and building the evaluation harness the model will be judged against for the rest of its life.

This bucket has genuinely shrunk over the past few years. Strong pretrained models and mature libraries mean less is built from scratch, which is precisely why the proportion spent on data and integration has risen.

4. Integration and deployment, 20–30%

Getting the output to the place a decision is made, inside the window in which it is still useful. APIs, message queues, writes into ERP, MES, case management or core systems, authentication, network and data residency constraints, CI/CD, and the release process of whichever team owns the destination.

This is the bucket most likely to overrun, and the overrun is almost always organisational rather than technical: the destination system is owned elsewhere, has a quarterly release train, and was not consulted early.

5. Operations, year one, 15–25% of build, annually

Monitoring, drift detection, scheduled retraining, incident response, and the extensions that follow first contact with real users. Budget this as an ongoing line, not as a contingency.

A model is not an asset that appreciates quietly in the corner. Input distributions move, upstream schemas change, vendors deprecate APIs and the world the model was trained on stops resembling the world it operates in.

What moves the number most

• Whether labelled data exists. The single largest swing factor. A project with usable historical labels can cost a fraction of an equivalent one that needs an annotation programme.
• How many systems it must integrate with. Each additional destination adds cost non-linearly, because each carries its own owner, release cadence and failure modes.
• Deployment environment. Cloud is cheapest. VPC-isolated adds moderately. On-premise adds substantially. Air-gapped adds a great deal. Every update becomes a logistics exercise.
• Regulatory posture. Model documentation, validation evidence and explainability artefacts are real engineering work. In regulated sectors this can add 15–25% to the build.
• Latency requirements. A batch job overnight and a decision in under fifty milliseconds are different systems with different costs, even where the model is identical.

Three costs people forget

1. Your own team's time. Domain experts to define correctness and adjudicate labels, IT for access and integration, and someone empowered to make decisions. This is a real cost even when it never appears on an invoice, and under-resourcing it is a common cause of schedule slip.
2. Inference at production volume. Pilot inference costs are trivial and tell you nothing. Model that cost at realistic volume before you commit to an architecture. It occasionally changes the architecture.
3. Change management. A system that alters how people work needs training, a transition period and often a parallel-run phase. Technically successful deployments fail here more often than anywhere else.

How to make an estimate meaningful

The most useful thing a buyer can do is refuse to accept a single number for the whole programme. Ask instead for:

• A fixed price for discovery, with defined deliverables
• A build estimate that breaks out the five buckets above separately
• An explicit statement of what is assumed about your data
• The year-one operating cost, quoted as a line of its own
• What happens to the estimate if the data assumptions turn out to be wrong

A supplier who can answer those has thought about your project. One who responds with a single figure and a confident timeline has thought about the sale.