Somewhere in your inbox is a proposal for an enterprise AI project. It has a scope section, a timeline, a team table, and a number at the bottom that probably looks reasonable. We write proposals like that for a living, so we can tell you what the number usually covers: building the system. What it usually does not cover is owning it. Data preparation, the inference bill after adoption takes off, evaluation, compliance review, monitoring, and months of humans double-checking the machine. In the projects we get called into after the fact, those items added 50-150% to the first-year cost, and almost none of them were in writing.
This is not an argument against buying. It is a map of where the money actually goes, so you can ask sharper questions before you sign, of any vendor, including us.
What enterprise AI solutions actually include
Before the costs, a definition, because "enterprise AI solutions" is one of those phrases that means everything and therefore nothing. In practice a proposal under that heading covers some combination of six things, and the ones that get under-scoped are always the last three:
- The model layer. Foundation models accessed by API, occasionally self-hosted or fine-tuned. The part everyone talks about, and rarely the expensive part.
- Retrieval and data access. Getting your own documents, records and systems into a form the model can use, with permissions intact.
- The application. The chat interface, agent, workflow or embedded feature that people actually touch.
- Integration. Connections into the ERP, CRM, helpdesk and data warehouse you already run, in both directions.
- Governance. Access control, audit trails, data residency, model documentation, and whatever your regulator or security team requires.
- Operations. Evaluation sets, monitoring, drift detection, model migrations, and the humans who review what the system produces.
A quote covering the first three is a build quote. A quote covering all six is an ownership quote, and it is the only kind you can budget against. Everything below is a walk through the items that live in the last three rows, in the order they tend to surprise people.
Data preparation: the 60-80% nobody itemizes
Ask anyone who has shipped a production AI system where the effort went and you get the same answer: the data. Cleaning it, deduplicating it, labeling it, and building the plumbing to access it reliably and legally consumes 60-80% of the real engineering hours on most projects we scope. The model integration, the part the proposal describes in loving detail, is often the smallest line.
Why do vendors under-quote it? Three reasons, and only one of them is dishonesty:
- They cannot see your data before the contract. Discovery happens after kickoff, when the CRM turns out to hold four records per customer and the product catalog lives in a spreadsheet named
final_v7_REAL.xlsx. - Competitive bidding punishes honesty. Pricing the data work properly makes a bid look expensive next to one that quietly ignores it.
- Everyone assumes someone else owns it. You think the estimate includes it; the vendor assumes you will hand over clean exports. Neither party wrote it down.
The vendor who prices data preparation honestly looks 40% more expensive than the one who plans to discover it after kickoff and bill it as change orders. Guess who wins the bid.
The fix is boring: insist on a paid discovery phase, one to three weeks where engineers actually query your systems, before anyone commits to a fixed number. We break down how discovery changes an estimate in our guide to what AI development really costs.
The inference bill that grows with your success
Traditional software has a comforting property: the more people use it, the cheaper each use gets. Usage-priced AI inverts that. Every call to a hosted model API costs money, so your best month, the one where adoption finally takes off, is also your most expensive.
The pattern we see repeatedly: a pilot runs at a few hundred dollars a month and nobody blinks. Then rollout reaches the whole company, someone wires the system into an automated workflow that calls it fifty thousand times a day, and the monthly bill quietly passes what the entire pilot cost. Nothing broke. The system is working exactly as designed. That is the problem.
Mitigations exist, but they are engineering work that belongs in the budget, not an afterthought:
- Response and prompt caching. A surprising share of real-world requests repeat. Caching identical and near-identical calls routinely cuts spend by 20-40% in the systems we run.
- Model routing. Send the easy 80% of requests to a small, cheap model and reserve the frontier model for the hard 20%. This is the single biggest cost lever we deploy.
- Prompt hygiene. Trimming a bloated system prompt and redundant context pays for itself within weeks at volume.
Ask the vendor for a projected monthly inference cost at ten times pilot volume. If they cannot produce one, the number does not exist yet, and when it appears it will be on your invoice.
Evaluation sets and model drift
How do you know the system works? Not from a demo. From an evaluation set: hundreds of representative inputs, each with a graded expected output, run against the system every time anything changes. Building one is real work, and it is work only your side can do: your domain experts have to write and grade the examples, because only they know what a correct answer looks like. Their time is precisely the time nobody budgeted.
You need the eval set because the ground moves under you:
- API deprecations. Model providers retire versions on their schedule, not yours. When the model you built on is sunset, you migrate, and re-test everything.
- Silent behavior shifts. Even a pinned model version sits on shifting infrastructure. Outputs that were terse turn verbose; a format that parsed cleanly for eight months stops parsing on a Tuesday.
- Your own changes. Every prompt tweak and every new tool risks regressing a case that used to work.
Budget a quarterly re-evaluation cycle: run the suite, review failures, adjust, re-run. In our projects that is a few engineer-days per quarter plus domain-expert review time. It is cheap insurance, but only if it exists as a line item, and it almost never does.
Legacy integration glue
The proposal says integrates with your ERP. The reality: the ERP is a 2012 install with no usable REST API, authentication runs through a service account created in 2016 whose password cannot change without breaking three other systems, and the only reliable export is a nightly CSV dropped on an SFTP server.
None of that is exotic. It is normal. The glue, meaning auth and token refresh, rate limits on internal APIs that were never designed for machine-speed callers, brittle exports, format marshalling, retry logic for systems that go down at 2 a.m. for backups, is 20-35% of integration effort in our experience, and it is the most common source of schedule overrun because every piece of it is invisible until an engineer hits it. We treat this layer as a first-class deliverable in our AI/ML integration work and quote it explicitly, because pretending it does not exist has never once made it go away.
Compliance and security: calendar time, not just money
If your data leaves the building, and with hosted model APIs it does, someone in legal or security will have questions. Reasonable ones: where does inference happen and where are logs stored (data residency), is there a data processing agreement with the model provider, does the sub-processor list need updating, does the new surface need a penetration test, and who fills in the 200-row security questionnaire.
The money involved is usually modest. The calendar is not. Each review cycle takes two to six weeks of elapsed time, the cycles chain, and while they run your project team is either idle or billing you anyway. We have watched a four-month build become a seven-month go-live entirely on review latency.
Two moves help. Start the compliance conversation at kickoff, in parallel with development, not after the demo. And choose providers with regional hosting and standard DPAs up front. Retrofitting data residency onto a finished system is one of the more expensive mistakes available.
Observability is rent, not a purchase
Deterministic software fails loudly: exceptions, 500s, pager alerts. AI systems fail quietly. The API returns 200, the latency is fine, and the answer is subtly wrong, and no traditional monitor will ever tell you. You find out from a customer, weeks later.
So production AI carries a standing observability cost: tracing every request, accounting tokens and cost per feature, sampling outputs for quality review, and alerting on drift in refusal rates or output length. Tooling is the small part. The real cost is attention: someone on your side spending a few hours a week actually looking. We wrote up the full stack in our guide to observability for LLM apps; the short version is that it is rent you pay for as long as the system runs, not a one-time purchase.
Vendor lock-in and the portability tax
Six months in, your prompts are tuned to one model's quirks, your tool definitions use one provider's calling format, and your cost model depends on one provider's caching discounts. Nobody decided this. It accreted. Then the provider changes pricing, or deprecates the model you depend on, and you discover that switching means re-tuning every prompt and re-running every eval, weeks of work you thought you had already paid for.
Portability is a feature, and features cost money: a thin abstraction layer over the model API, provider-neutral tool schemas, and a cross-provider eval run twice a year to keep a credible second option. Call it 5-10% of ongoing engineering. You do not have to pay it. Accepting lock-in with open eyes is a legitimate choice, especially early. Accepting it by accident is not. Ask which one your proposal assumes.
The human review loop everyone forgets
Between go-live and trust, there is a period where your staff review what the AI produces before it goes out the door. Support agents reading drafted replies before sending. Analysts checking extracted figures against source documents. That is 20-60 seconds per item, thousands of items a month, on your payroll, and it appears in nobody's budget, because it is not vendor work.
The realistic ramp we set with clients: review everything for the first month or two, sample heavily once the eval numbers hold, and settle into spot-checks. For low-stakes output the review rate can approach zero. For anything customer-facing or financial it never quite does, and it should not. Plan the hours like you would plan training time for a new hire, because functionally that is what this is.
The questions to ask before you sign
Put these to any vendor, including us. Crisp answers are a good sign. Hand-waving means the missing item will come back later wearing a change-order costume.
- Data: What happens when data cleaning turns out bigger than assumed: whose budget absorbs it, and at what rate?
- Inference: What is the projected monthly API cost at ten times pilot volume, and which caching or routing measures are in scope?
- Evaluation: Who builds the eval set, who owns it, and what does a quarterly re-run cost?
- Drift: What is the plan when the model provider deprecates the version we launch on?
- Integration: Which of our systems need custom connectors, and are those connectors itemized?
- Compliance: How many weeks of security and legal review does the timeline assume, and do they run in parallel with development?
- Observability: What monitoring ships with the system, and who watches it after handover?
- Portability: What would switching model providers cost in month eighteen?
- Review loop: How many hours of our staff time does human review need in the first six months?
A simple decision rule: if the proposal in front of you answers fewer than half of these in writing, the price at the bottom is not the price. It is the deposit.