AI Pilot Costs vs Production Platform Costs: What CFOs Should Budget For

The pattern is familiar enough to be predictable. A proof of concept is approved, runs for eight weeks, comes in close to budget, and works. The demo goes well. Someone senior asks what it costs to roll this out properly, and the number that comes back is several times the pilot — sometimes an order of magnitude more.

At that point one of two things happens. Either the project quietly stalls, joining the collection of successful pilots that never became systems, or it proceeds with a budget nobody planned for and an executive sponsor who now looks like they were misled.

The uncomfortable part is that nobody was misled. The pilot was honest. It simply measured a different thing than production, and the gap between them is structural rather than a matter of estimation error. Understanding what the pilot deliberately left out is what makes the second number predictable in advance instead of a surprise.

What a pilot excludes on purpose

A pilot is designed to answer one question quickly: does this work at all? Everything that does not serve that question is stripped out. That is good discipline — and it means a pilot’s cost structure has almost nothing in common with production’s.

Consider what is typically absent:

The real data. Pilots run on a curated extract — clean, current, and chosen by someone who knew which documents would work. Production runs on the actual corpus: inconsistent formats, superseded versions with no status field, scanned documents from before the DMS migration, and the shared drive nobody has owned since 2021. The pilot proved the approach works on good data. It said nothing about what the data costs to make good.

Integration. The pilot connected to one system, or to an export from it, often through credentials a helpful engineer provisioned personally. Production connects to the systems of record through supported, monitored, least-privilege interfaces that survive the source system’s upgrade cycle. This is usually the single largest cost line, and the pilot’s version of it does not count.

Identity. In a pilot, users are a list. In production, they are a directory, with groups, roles, joiners and leavers, and the requirement that the system’s view of permissions matches the source system’s — continuously, not on the day it launched.

Availability. A pilot that is down for a morning is an inconvenience. A production system embedded in a workflow that is down for a morning is an incident, and the difference between those two states is an on-call rota, monitoring, a support model, and a redundancy story.

Evidence. In a regulated environment, production carries a documentation burden the pilot never touched: system documentation, risk assessment, audit trails that reconstruct decisions months later, and demonstrable human oversight. This is not overhead to be optimised away — under the EU AI Act’s deployer obligations it is a condition of operating, and it has a real cost that appears entirely on the production side of the ledger.

None of these exclusions were mistakes. They are why the pilot was fast. The mistake is reading the pilot’s cost as production’s cost, divided by scale.

The categories that dominate production

Budget conversations about AI platforms tend to focus on the two most visible lines — GPUs and licences — because they are concrete, quotable, and easy to compare. In most on-premises deployments they are a minority of the total.

The larger categories are less quotable:

• Integration engineering, at production standard, for every system of record the workflow touches.
• Data pipeline work — ingestion, normalisation, deduplication, metadata derivation, and the synchronisation that keeps all of it current.
• Governance and evidence — audit logging, decision traceability, model documentation, oversight design.
• Evaluation — a regression suite that tells you whether a model or prompt change made things worse, which is the only thing standing between you and silent degradation.
• Observability and operations — the same monitoring and on-call maturity any production system requires.
• Change management — the work of altering how people actually do their jobs, which is frequently underestimated to zero and is frequently what determines whether the system gets used.

Notice how few of these depend on which model you chose, and how many are the ordinary costs of putting any system into production. That is the real lesson of the pilot-to-production gap: the AI part was never the expensive part. The full TCO picture for on-premises AI makes the same point from the infrastructure side.

Where the platform decision actually matters

If most production cost is integration, governance, evaluation, and operations, then the question worth asking about a platform is not “what does it charge?” but “which of these categories does it remove, and which does it hand back to me?”

A framework hands them all back. That is what a framework is — you assemble the platform yourself, which is entirely reasonable if that assembly is a capability you want to own and staff permanently. What it is not is cheaper, and licence-free is not the same as cost-free. The hidden costs of building on frameworks sit almost entirely in the categories above.

A platform that supplies governance, audit trails, access control, connectors, and evaluation as infrastructure removes work rather than adding a line item — and the comparison that matters is against the fully loaded cost of building and maintaining those components, not against zero.

The pricing model matters too, in a way pilots systematically obscure. At pilot volume, per-token pricing looks trivially cheap — that is precisely why the pilot chose it. The cost only becomes visible at production volume, and it scales with exactly the adoption the project is meant to produce. A workload that succeeds gets more expensive, which is an unusual and uncomfortable property for a CFO to underwrite. The flat versus token-based pricing comparison is worth running at projected production volume before the pilot’s economics anchor anyone’s expectations.

Budgeting so the gap does not surprise you

Three practices remove most of the pain.

Never approve a pilot without a production envelope. Not a precise figure — an order of magnitude, agreed before the pilot starts, with explicit criteria for what a successful pilot must demonstrate to release it. This reframes the pilot from “prove it works” to “prove it is worth the number we already agreed,” which is a far more useful question and stops the pilot from optimising for a demo.

Make integration assessment part of the pilot. The pilot should not just show that the model can answer questions — it should establish what connecting to the real systems will require. That is where production cost concentrates and where the pilot is most likely to have taken a shortcut. A pilot that skips this has proved the cheap half and left the expensive half unmeasured.

Budget the operating year, not the build. An AI system is not a project that completes. Models are updated, documents change, source systems upgrade, regulations move, and evaluation suites need maintaining or they rot. A build budget with no operating budget produces a system that works on launch day and degrades quietly from then on — which is a familiar pattern in why agent proofs of concept fail to reach production.

The honest framing

The gap between pilot and production is not evidence that the pilot lied or that production is gold-plating. It is evidence that the two exercises answer different questions with different requirements.

A pilot buys information: is this feasible, is it valuable, is it safe. That information is worth having and worth paying for, and a cheap pilot is a feature. Production buys a system that operates reliably inside an enterprise’s real constraints — its data, its identity model, its regulators, its uptime expectations — and that system costs what production systems cost.

Organisations that budget for both from the outset move through this transition without drama. Organisations that treat the pilot number as the production number arrive at the board conversation with a request that looks like a tenfold overrun rather than the second, larger, entirely foreseeable half of a plan.