Two hundred dollars of API credit is enough to build something that looks finished. It handles the demo case, it answers in the right tone, and by the end of the meeting everyone agrees it should go live. Then the quote to make it go live arrives with an extra three digits on it.
That is the moment most AI budgets get decided badly. The natural reading is that somebody is padding. The accurate one is that nobody has yet priced the second product, because nobody noticed there were two.
The gap between those numbers has a shape, and it is not a list of cost categories. It is a bill for every exemption the pilot was quietly granted: one user, one happy path, no auth, no audit trail, nobody on call. Production revokes them one at a time, and each revocation has a price. Work through them and the quote stops being a mystery and starts being a forecast you can produce yourself, before anyone says a number out loud.
Why the two numbers are so far apart
A pilot demonstrates that something is possible. Production commits to it working while nobody is watching. Different products, different requirements, and the price gap is almost entirely the requirements.
The pilot gets exemptions. One user, who happens to be the person who built it. One happy path, chosen because it works. No authentication, because it runs on a laptop. No audit trail, because nothing it does is binding yet. No failure mode, because a human sits there catching mistakes. No on-call rotation, because if it breaks on Saturday it waits until Monday.
Production gets none of them. Each exemption turns back into work, and that work is what the quote is made of.
| Pilot | Production | |
|---|---|---|
| Users | One, usually the builder | A department, including people who were not consulted |
| Inputs | The cases that demo well | Whatever arrives, including the malformed ones |
| Authentication | None | SSO, roles, per-record permissions |
| Data handling | A copied spreadsheet | Live systems, retention rules, PII boundaries |
| Errors | A person notices | Detection, alerting, fallback, escalation |
| Accuracy | Good enough to impress | A number somebody agreed to in advance |
| When it breaks | It waits | Somebody gets paged |
| Audit | None | Who did what, when, and on whose authority |
| Change | Rebuild it | Versioning, review, rollback |
Read the table as a bill of materials, not a comparison. Every row on the right is a line item that did not exist on the left. Most organizations approve the left-hand column believing they have priced the right-hand one.
What actually gets added between the demo and the launch
Almost none of the added work is AI work. The single largest line is plumbing, and one practitioner estimate puts it at 60 to 70 percent of the effort on projects that ship. Here is what the right-hand column costs in practice.
- Integration. The demo read from a file. Production reads from the CRM, the ticketing system, the data warehouse, and the identity provider, each with its own auth, rate limits, and failure behaviour. That is the 60 to 70 percent figure, per McKelvey (2026), and it is the line most quotes get wrong first.
- Permissions and identity. A tool that can see everything is fine when one person uses it. The moment it serves a team, somebody has to answer which roles can read which records, and the answer has to be enforced rather than assumed.
- Data preparation. Pilots run on a clean extract. Production runs on the real thing, with duplicates, missing fields, and three historical formats nobody documented.
- An evaluation set. The demo was judged by watching it. Production needs a fixed set of cases with known correct answers, so that "it got better" is something a person can check rather than feel.
- Observability. Logging, tracing, cost attribution per call, alerting when output quality drifts. Without it, the first sign of a problem is a complaint.
- A fallback path. What happens when confidence is low, the model is unavailable, or the answer is refused. Each of those needs a defined behaviour, and usually a human queue behind it.
- Human review. Most production AI keeps a person in the loop somewhere. That person's time is a recurring cost, and it rarely appears in the original business case.
- Security and compliance review. Data residency, retention, vendor assessment, plus whatever the industry adds on top.
Add them up and the quote stops looking mysterious. The model call is a rounding error. Everything around the model call is the project. Pricing one ordinary workflow at both ends is the quickest way to see how lopsided that gets.
A worked example, priced at both ends
Take an unglamorous one: inbound support email gets routed to the right team, with a drafted reply attached.
The pilot version takes a weekend. One prompt, one exported mailbox, a person reading every suggestion before it goes anywhere. The API bill lands in the low tens of dollars. It works well enough that somebody films it.
The production version is the same idea with the exemptions revoked . It connects to the live mail system and the ticketing platform. It respects who is allowed to see which customer records. It redacts payment details before anything leaves the building. It gets measured against a fixed set of previously-resolved tickets. It escalates to a human queue when it is unsure, and it pages an engineer when routing accuracy drops below the agreed number.
The figures below are illustrative estimate ranges for a mid-market build, not a quote and not a past engagement. They show the shape of the arithmetic rather than predicting a specific invoice.
| Line item | One-time build | Recurring, monthly |
|---|---|---|
| Prompt and routing logic | $3,000 - $6,000 | - |
| Mail and ticketing integration | $18,000 - $35,000 | - |
| Identity, roles, record permissions | $8,000 - $15,000 | - |
| Data cleanup and PII redaction | $10,000 - $20,000 | - |
| Evaluation set and harness | $8,000 - $14,000 | - |
| Monitoring, alerting, cost attribution | $6,000 - $12,000 | - |
| Fallback and human-queue handling | $5,000 - $10,000 | - |
| Security and compliance review | $4,000 - $12,000 | - |
| Model and infrastructure spend | - | $500 - $3,000 |
| Human review time | - | $2,000 - $8,000 |
| Maintenance, re-evaluation, drift work | - | $3,000 - $9,000 |
| Total | $62,000 - $124,000 | $5,500 - $20,000 |
The prompt, the part that made the demo impressive, is under five percent of the build. That ratio is the whole argument. The pilot priced the interesting part. The quote prices the boring parts, and the boring parts are the system.
Notice the second column, too. It is the one that outlives everyone's attention.
One-time costs and the bill that arrives every month
The most expensive budgeting mistake here is approving a build number and forgetting the run number. It is invisible at approval time and unavoidable afterwards, which is a bad combination.
Recurring costs on a production AI system are model and infrastructure spend, monitoring, human review time, periodic re-evaluation as the underlying models change, drift investigation, and support. None of them end. A system that costs $80,000 to build and $10,000 a month to run costs $200,000 in its first year, and the second number is the one that gets challenged in month four by somebody who only ever saw the first.
This is not a niche failure. An IDC survey sponsored by DataRobot (2025) reported that 71 percent of respondents had little to no control over where their AI implementation costs were coming from. The IBM Institute for Business Value (2024) put the expected rise in average computing cost at 89 percent between 2023 and 2025, with 70 percent of surveyed executives naming generative AI as a critical driver and every one of them reporting at least one initiative cancelled or postponed over cost.
Read that last clause again. Not some of them. All of them.
Losing control of the run cost is the normal outcome, not the unlucky one. The organizations that avoid it forecast it before the build starts, which means knowing what the market charges for each piece .
What the market actually charges for AI implementation cost
Published bands work as a sanity check, provided the scope behind each band is stated. The ranges below recur across 2026 vendor and advisory sources. Read them as market observations, not as a quote for any particular piece of work.
- A single, well-scoped use case: roughly $15,000 to $30,000, per McKelvey (2026).
- A multi-stakeholder rollout: roughly $30,000 to $75,000, per McKelvey (2026).
- A mid-market company's first production AI system, all in: roughly $90,000 to $300,000, per ClearForge (2026).
- An enterprise programme: $500,000 to $2 million and above, per ClearForge (2026).
- Ongoing managed AI operations: $5,000 to $25,000 per month, per ClearForge (2026).
Budget-share splits are similarly consistent. Pertama Partners (2026) puts consulting at 25 to 35 percent of spend, technology at 20 to 30 percent, data at 15 to 20 percent, infrastructure at 10 to 15 percent, and training at 8 to 12 percent. (Their published breakdown also carries a contingency line, which is why the five figures above do not sum to 100.) The pattern matches the worked example. The model is a minority shareholder in its own project.
Why published estimates disagree by three orders of magnitude
Anyone who has searched this question has seen figures from $5,000 to $5 million on the same results page. The spread is real, and no source is lying.
"Implementation" simply has no agreed boundary. One article prices a single automation. Another prices an organizational programme including change management and training. A third prices the model work and leaves integration to the reader. A fourth quotes a build with no run cost at all. All four are internally honest and mutually useless.
A quote or a published range becomes comparable once three things are stated. What is in scope, specifically, by system and use case. What is excluded, especially integration, data work, and evaluation. Whether the number is build-only or includes the first year of running it. Any figure missing those three qualifiers is a number rather than an estimate, including the one you are about to produce for yourself.
How to estimate your production number from your pilot number
There is no reliable multiplier. There is a checklist of exemptions, and each one that applies to the production version adds a cost line the pilot never carried.
Work through these in order and price the ones that apply:
- Who uses it. One person, a team, a department, or customers. Every step up that ladder adds identity, permissions, training, and support.
- Whose data it touches. Test data, internal data, customer data, or regulated data. Each level adds handling requirements and a review that has to be scheduled around somebody else's calendar.
- What systems it reads from and writes to. Count them honestly, including the one everybody forgets, which is nearly always the identity provider. Integration is the largest line, so an accurate count here does more for the estimate than anything else on this list.
- What "good enough" means numerically. If nobody has named a threshold, an evaluation set has to be built before the threshold can be met, and building it takes real time.
- What happens when it is wrong. An embarrassing answer, a bad routing decision, a wrong number in a report, or a financial or regulatory consequence. The cost of the safety work scales with the answer.
- Who gets paged. If the answer is nobody, it is not in production. If the answer is somebody, that rotation is a recurring cost.
- What regulation touches it. Sector rules, data residency, retention, auditability.
The output of this exercise is a range, not a price. That is the correct output. A single confident number produced before the integration count is known is what causes the argument later. The range also gives you something to measure a quote against, which is where most of its value sits.
Red flags in a quote, in both directions
Cost of AI implementation conversations almost always focus on the quote that seems too high. The quote that seems too low is the one that costs more.
Suspiciously low. Anything under roughly $5,000 for a workflow that touches live systems is, in practice, an API wrapper with no operational plan, a view echoed across practitioner write-ups in 2026. Check for the absences: no named integrations, no evaluation plan, no monitoring, no mention of who owns it after handover, and a timeline that assumes every system it touches behaves.
Suspiciously high. A six-figure number is defensible when it is itemised and indefensible when it is not. Ask which systems are being integrated and how many endpoints each one needs. Ask what the evaluation set is and who builds it. Ask what the monthly run cost is expected to be and what drives it. A vendor who has scoped the work answers all three in the meeting. A vendor who has guessed offers a range and changes the subject.
One question separates them faster than any other: what specifically is excluded from this number. A well-scoped quote has a clear exclusion list. A padded one does not, because padding works by keeping the boundary vague.
What you can cut, and what will bill you later for cutting it
Cost pressure is legitimate. Some cuts save money. Others move the cost into a worse quarter.
Usually safe to cut:
- Scope. Ship one use case rather than four. The most effective lever available, and almost always available.
- Custom model work. Hosted models cover the overwhelming majority of business cases at a fraction of the effort.
- Bespoke interface. The workflow can live inside a tool people already have.
- Phase-two features. They are called phase two for a reason.
Expensive to cut:
- The evaluation set. Cutting it does not save the cost. It defers it into incident response and into arguments nobody can resolve with evidence.
- Monitoring. Without it, the first signal of a problem is a customer, and by then the problem has a history.
- The human review path. Removing it converts a manageable error rate into an unmanaged liability.
- Data cleanup. The mess does not go away. It gets processed at scale and turns into output nobody trusts.
A useful test before agreeing to any cut: does this reduce what the system does, or does it reduce our ability to tell whether the system is working. The first kind is a scope decision. The second kind is a loan.
What to settle before the pilot gets shown to anyone
The cheapest place to discover the production number is before the pilot is demonstrated to somebody with budget authority. After that demo, the conversation is about defending a figure rather than setting one.
Four things are worth agreeing in advance, and all four take less than a week.
- Who the real users are, by name or by role, and what they currently do instead.
- What good enough means as a number, agreed with the person who will be accountable for it.
- Which systems and which data are in scope, counted rather than assumed.
- Who owns it in month six, including who is paged and who pays the run cost.
A pilot built with those four answers written down produces an estimate instead of a surprise. It usually produces a smaller, better-scoped first system too, because the exercise exposes which use case is tractable.
If the pilot is already built and the quote has already landed, the same exercise runs backwards. Map what the production version has to do, count the systems, name the threshold, and work out which parts of the number are scope and which are uncertainty.
That is what the AI Readiness Snapshot is for. It is a free 30-minute call that maps where AI will have the most immediate impact on cost and reliability in your environment, and what the realistic path to production looks like from where you are now.
