Last updated: September 2, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
AI implementation cost after a successful POC usually lands at three to five times the pilot price, because inference at real volume, data work, evaluation, and the people who run it are never inside the demo number. The pilot priced a rehearsal. Production prices the run. Below is every line item that shows up in the gap between the two, and how to size each one before you sign anything.
A finance partner called me on a Thursday about a cloud bill. Not the whole bill. One line on it. Her team had run an AI pilot the prior quarter for something like ninety thousand dollars, everyone was pleased with it, and the thing went live in March. By June that single line was landing at forty-one thousand a month and still climbing, and nobody in the room could tell her why it moved. That was her actual question. Not why is this expensive. Why is it expensive in a way we cannot predict. Nobody knew.
I have watched a version of that call happen for years. The answer barely changes. The pilot was never a small version of the production system. It was a different system that happened to produce the same demo.
That distinction is the whole article. A pilot runs on a bounded dataset somebody cleaned by hand, on capped traffic, with no compliance review, no retry logic, no monitoring, and an engineer babysitting it who is technically assigned to another team. Strip every one of those conditions away and you have production. All of them, not some. Each thing you take away is a line item, and not one of them appeared on the quote. If you are still deciding whether to buy at all, start with how I make the AI build vs buy call, then come back here. This piece assumes the pilot worked and the question in front of you is what the next twelve months actually cost.
What AI Implementation Cost Actually Covers
AI implementation cost is the full twelve-month outlay to run an AI capability in production, including inference, data engineering, integration, evaluation, human review, monitoring, compliance work, and the loaded cost of the people who keep it alive. The vendor license is one line in that stack. Usually not the biggest. On most of the programs I have sized it comes third or fourth, behind the compute, behind the data work, and sometimes behind the salary of the one person who ended up owning the whole thing.
Finance teams get burned here for a structural reason, not a competence reason. A pilot budget is a project budget. Start, end, number. A production AI system is an operating budget with a usage curve attached, and usage curves do not respect quarters. Nobody is lying. The two things are priced in different units, and the handoff between them is where the arithmetic breaks. That is the whole failure.
The industry data has caught up to this. Gartner now expects at least half of generative AI projects to exceed their budgeted cost by 2028, blaming poor architectural choices and thin operational experience. Gartner’s own phrasing is blunter than mine. Orders of magnitude. That is how Gartner describes the gap between running a pilot and standing up the production version of it.
The Line Items the Pilot Number Left Out
Here is the whole stack in one place. Left column is what the pilot paid for. Right column is what the same row costs once real traffic hits it.
| Line item | What the pilot priced | What production actually costs |
|---|---|---|
| Inference | A few thousand calls against a capped test budget | Every call, every user, every retry, every month. Gartner puts inference at 70% or more of a model’s lifetime cost. |
| Data engineering | One clean extract a person assembled by hand | Pipelines, backfills, schema drift, and the field three teams defined differently in 2019 |
| Integration | An API key and a sandbox | Auth, data residency, queueing, retries, idempotency, and absorbing the vendor’s next breaking change |
| Evaluation | The engineers in the room liked it | A labeled test set, a regression suite that runs on every change, and one person who owns the score |
| Human review | Not priced | The queue of outputs somebody checks before they are allowed to count for anything |
| Model version churn | Not priced | Re-running your whole evaluation every time the vendor ships a new model and deprecates the old one |
| Observability | Not priced | Tracing, logging, and per-feature cost attribution, without which you cannot answer the finance question at all |
| Compliance and audit | Security signed off on the sandbox | Technical documentation, retained logs, human oversight, and evidence an examiner will accept |
| The operator | Borrowed from another team for six weeks | A real seat, fully loaded at $290,000 to $480,000 in year one for a mid-to-senior US hire |
Count the rows that say “not priced.” Three of nine. Never on anyone’s sheet. A fourth was priced as a loan from a team that wants their engineer back. That is not a price. It is a debt that comes due the week the pilot ships and somebody has to keep the thing running.
Inference Is the Line That Grows While You Sleep
Most budget conversations treat model spend like a software license. Fixed. Predictable. Annoying but knowable. Model spend is none of that.
Inference is metered by use, and use is a function of adoption, which is the one number everybody on the project is actively trying to make go up. You are simultaneously incentivizing the thing that raises the bill and forecasting the bill as if it were flat. That is the trap my finance partner walked into. She is not careless. She is one of the sharpest people I have worked with, and the forecast still missed by a factor of four, because the model she was handed had no variable in it for the thing everyone was working to increase.
The per-token price genuinely is falling. That is real, and it is why so many teams assume this line takes care of itself. It does not, and Gartner has a name for why. Reporting in August 2026, the firm predicted that inference costs per agentic workflow will rise more than fivefold through 2028, and Sr. Director Analyst Will Sommer called it the Inference Paradox. Better unit economics, escalating total cost. The mechanism is the part worth writing down. Routing a task to an agentic reasoning model raises provider inference cost by at least five times compared with a basic chatbot call, and more as the task gets harder.
So the cheap tokens are real and your bill still triples. Both, at once. Cheaper tokens are what make the more expensive workflow affordable enough to build, and then you build it, and then you are buying a great many more tokens of a more expensive kind. Show me the data on your pilot’s average tokens per request and I can usually tell you inside one call whether the production number is going to embarrass somebody.
Two moves, both cheap. Instrument token spend per feature before launch, not after the invoice arrives, because retrofitting attribution onto a live system is miserable work nobody wants to fund. And set a routing policy on day one so the expensive reasoning path is reserved for requests that genuinely need it. Most requests do not.
The Data Work Is the Project
Every AI pilot I have seen runs on a dataset that one person prepared and nobody wrote down how.
That person is usually a strong engineer or analyst who spent two weeks pulling records, reconciling duplicates, dropping the rows that were obviously broken, and making a hundred small judgment calls about what counted. The pilot was measured on that dataset. Production runs on the real one. Same data, before any of that happened, arriving continuously, from half a dozen systems that disagree with each other about what a customer even is.
Gartner’s April 2026 survey of 782 infrastructure and operations managers put a number on how much this hurts. Only 28% of AI use cases fully succeeded and met ROI expectations, 20% failed outright, and 57% of leaders had lived through at least one failure. Among those who hit trouble, 38% named poor data quality or limited data availability as a direct cause. The same proportion named skill gaps. Neither is a model problem. Neither is cheap after launch.
The most expensive version of this I have lived through was in mortgage tech. A field mapping exercise that was written into the plan as a subtask of the integration ended up touching every group in the building that reads a loan file, and it outran the integration itself by months. That whole story is written up separately in what an Encompass integration really costs a lender. The lesson transfers cleanly to AI. The connector is never the hard part. Getting your own organization to agree on what its data means, in writing, is the hard part. That is a program, not a sprint.
Budget it as a named line with its own owner. If nobody on the plan is accountable for data quality by name, that cost has not been removed. It has been deferred into next year at a worse exchange rate.
The People Line Nobody Puts in the Pilot Budget
Pilots run on borrowed people. Not a criticism. That is how pilots are supposed to work. You pull a good engineer off something else for six weeks, they build the thing, everyone claps.
Then it goes to production and that engineer has a day job again. The system now needs somebody to own evaluation, watch drift, absorb model deprecations, answer compliance questions, and take the page at two in the morning when the vendor’s endpoint starts timing out. Nobody budgeted that seat. During the pilot it was free.
The real number is worse than the salary. Considerably worse. Our breakdown of what it costs to hire an AI engineer lands at $290,000 to $480,000 fully loaded in year one for a mid-to-senior US hire. Base pay is forty to fifty-five percent of that. The rest is payroll tax, benefits, compute, token spend, recruiting, and ramp. If the work is bounded and you would rather not carry a permanent seat, the hourly bands by profile are a cleaner instrument. Either way, put a person on the sheet. A production AI system with no named owner does not save you the headcount. It spends the money somewhere less visible, usually as unplanned work dumped on a team that was already behind.
The bias here is mine to disclose and I will. KORE1 places engineering and AI talent, so we do better when your budget includes a person. The number I would actually put in front of a CFO here is not speed of hire. It is the 92% twelve-month retention rate KORE1 holds on direct hire placements, against a 17-day average fill. Retention is the one that maps to this line item. An AI system quietly doubles in cost the first time the only person who understood the evaluation harness walks out.
Compliance Is a Cost Center Now, Not a Review Step
For anyone in a regulated shop this line has moved. Recently, too.
The EU AI Act’s obligations for high-risk systems come into application on December 2, 2027 for systems in areas such as employment, credit, education, and critical infrastructure, with product-embedded high-risk systems following in August 2028. The requirements read like an engineering backlog rather than a legal memo. Risk assessment and mitigation. Documented data quality. Activity logging sufficient for traceability. Detailed technical documentation. Human oversight measures. Robustness and accuracy standards.
Read that list again as line items and not as policy. Logging for traceability is storage plus retention plus somebody building the export. Human oversight is a queue and the person who works it. Data quality documentation is the data project from two sections ago, with an auditor attached. None of it is optional if you fall in scope. None of it existed in the pilot.
Twenty-five years of shipping inside regulated industries taught me to price this early rather than argue about whether it applies. If your AI touches a decision about a person’s job, money, or housing, assume you are in scope and budget the evidence. Discovering you are in scope during an audit costs several multiples of building for it up front. I have never once seen that go the other way.
The Portfolio Math Nobody Puts on the Sheet
Here is the line item that is genuinely invisible, and the one I would most want a CTO to sit with.
You are not funding one AI system. You are funding the portfolio it came from. Every attempt. Including the ones that died.
My own count, across the last couple of years of watching these get greenlit. Ten pilots go in. Two come out the other side running in production. Eight stall somewhere between the demo and the deployment, then get defunded without ceremony. Those eight were not free. Not close. Each consumed engineering weeks, vendor evaluation time, a data pull, some amount of executive attention, and a chunk of the organization’s appetite for the next attempt. That spend is real, it already happened, and it belongs in the cost basis of the two that lived.
Run the arithmetic honestly and the picture changes. If a pilot cycle costs you $90,000 in loaded effort and one in five makes it, the true acquisition cost of a production capability is closer to $450,000 before you have paid for a single month of running it. Then you add the nine rows from the table above. Most AI business cases I get handed compare the survivor’s run cost against the survivor’s pilot cost, which is a comparison between two numbers that both understate the program.
None of this is an argument against pilots. I would rather kill eight cheaply than fund one badly for two years. It is an argument for pricing the failures deliberately instead of pretending they were overhead. Teams that budget a pilot portfolio, with a fixed number of shots and a real kill threshold on each, spend less in total and ship more. Teams that fund pilots one at a time out of whatever budget is nearby spend more and cannot tell you what they spent.
How I Size This Before Anyone Signs
Four numbers. I ask in this order. I do not move until all four are in writing.
One. Requests per month at full adoption, not at pilot traffic. Ask the business sponsor how many transactions they want touched, then multiply by the average calls per transaction the pilot actually made. That multiplier is usually higher than anyone remembers, especially for anything agentic, because a single user action can fan out into a dozen model calls under the hood.
Two. The data readiness delta. What did the pilot dataset have that the production feed does not? Get your own engineer to answer this, not the vendor’s solutions consultant. Whatever number your engineer gives you is the floor, not the target.
Three. The named owner and the percentage of their year. If the honest answer is fifteen percent of someone who already has a full role, write down what that person stops doing. There is always something. Never nothing.
Four. Kill threshold and date. One business metric, one number, one deadline. This is the cheapest line on the sheet and the one that saves the most money, because it converts an indefinite commitment into a bounded one. The full version is the fourth gate in my four-gate pre-signature checklist, worth running end to end before a contract goes out.
Add contingency on top. Not ten percent. Nowhere near it. On a first production AI system in a company that has not run one before, I plan for the total to land somewhere between three and five times the pilot number, and it has been closer to five more often than three. If that sounds pessimistic, look at the Gartner budget number again. Half of these programs will overrun by 2028, and the ones that do not are mostly the ones that priced the boring rows.
If you want a second set of eyes on the model itself, our build vs buy technology advisory practice runs this exact sizing exercise with clients, and if the answer comes back build, KORE1’s AI and machine learning staffing team can put the person in the seat. I am happy to argue about any of the nine rows if you think I have weighted one wrong. Connect with me on LinkedIn, or talk to a KORE1 recruiter if the gap you found turns out to be a people gap.
Questions Finance Teams Ask Me About AI Budgets
What multiple should we actually plan for?
Three to five times the pilot number for a first production AI system, and closer to five if the workflow is agentic or the data is messy. That is the planning range I use, and it assumes the pilot itself was honestly scoped.
The multiple compresses on your second and third system, sometimes a lot, because the expensive parts are shared. Pipelines, evaluation harness, observability, and the person who knows how all of it fits together get built once. The first one is the tax. Pay it once. If your organization is planning several AI capabilities over two years, the smart move is to price the first as platform work and stop pretending it is a project.
Our vendor quoted us a flat annual license. Are we covered?
One row of nine is covered. A flat license fixes the vendor’s own line and nothing underneath it. Data engineering, integration, evaluation, human review, observability, compliance evidence, and the operator are all still yours regardless of how the vendor prices their side.
Flat pricing is genuinely useful for the thing it does, which is making one line predictable. It is not a total cost of ownership number and no honest salesperson will claim it is. Where I do get suspicious is a flat license with a usage cap buried in an appendix, because that is a variable cost wearing a fixed cost’s clothing, and you find out which one it really is in month nine.
Where does the money go first when a pilot scales?
Watch inference first, then data, usually inside the first two quarters. Inference moves because adoption moves. Data work surfaces because production data refuses to behave like the curated sample the pilot was measured on.
Compliance and model churn arrive later and hit harder, which is what makes them dangerous. They tend to land in month nine or twelve, well after the celebration, when the budget has already been reforecast on the assumption that things had settled. They had not settled. Just quiet.
We already went live and the bill is moving. What now?
Get attribution before you get cuts. You cannot optimize a number you cannot break down, so the first job is per-feature cost tracing, not a spend freeze. Most teams find one or two features carrying the bulk of the bill, and it is almost never the feature anyone would have guessed in the room before the tracing went in.
Then look at routing. In almost every runaway bill I have been asked to look at, a meaningful share of traffic was going to an expensive reasoning path for requests a smaller, cheaper model would have handled correctly. Fixing that is unglamorous and usually recovers more than renegotiating the contract would. Do it before you call the vendor, because it also improves your position when you do.
Is it cheaper to just build it ourselves?
Almost never, and far less often than engineers want it to be. Build vs buy should turn on whether the capability is your actual competitive edge, not on price, because the price comparison flatters building by leaving out the same rows this article is about.
What building genuinely changes is who absorbs the churn. Buy, and the vendor’s roadmap becomes your maintenance schedule. Build, and you own the maintenance forever, including the parts you did not anticipate. Both are real costs. Neither shows up on a spreadsheet that compares a license fee against a couple of salaries, which is the shape of roughly every build-versus-buy business case I have been handed in the last three years.
How do I explain this to a CFO who already approved the pilot number?
The pilot was a market test, not a first installment. It answered whether the capability works. It was never priced to answer what running the thing costs, and treating it as a down payment on production is the actual mistake, not the overrun.
Bring the nine rows and mark which ones the pilot covered. In my experience finance people are not upset by a bigger number. They are upset by a number that moves after they defended it. Give them the full stack once, with honest contingency, and the conversation goes better than you expect. Our piece on getting an engineering budget through CFO approval covers how to frame that ask.
