Ask a finance leader what an AI project costs and they will usually name a token bill or a licence fee. Ask an engineer six months into production what the same project actually costs and you will get a much longer answer, most of which was never in the business case. The gap between those two numbers is where AI programmes go over budget, and it is where I want to spend this article.
The rule of thumb I have arrived at, after enough of these projects to have a pattern, is that for every dollar of visible model cost, there are typically three to five dollars of surround. Sometimes more. That surround is not exotic. It is the ordinary, unglamorous work of running an AI system in a real business, and almost none of it makes it into first-draft business cases.
The visible layer: model, infrastructure, licences
Let me start with what usually is in the case, because it is worth being clear about what is being captured. The visible costs typically include model API usage (token spend for hosted models or GPU inference cost for self-hosted ones), platform licences (Claude Enterprise, Copilot seats, whichever specialised tools you have adopted), core infrastructure (vector databases, orchestration tooling, the hosting environment), and the platform team salaries.
These are the numbers that show up on vendor invoices and in the CFO’s cloud dashboard. They are real, and they are usually well-estimated. In 2026, per-token pricing has continued to decline (Claude Sonnet 4.6 at $3 per million input tokens and $15 per million output tokens as of May 2026, with prompt caching and batch APIs offering additional discounts of 50 to 90 percent on eligible usage), which has made the visible layer even easier to plan.
If the visible layer were all there was, AI ROI would be simple. It is not.
The hidden layer: data preparation
Every AI system runs on data, and getting data ready for AI use is expensive in ways most business cases do not anticipate. This includes source system integration, schema harmonisation, quality validation, PII detection and redaction, ongoing pipeline maintenance, and the data engineering headcount to keep all of it running.
Gartner has been saying for years that data readiness is the single biggest predictor of AI project success, and their 2025 forecast that 60 percent of AI projects unsupported by AI-ready data would be abandoned through 2026 has largely borne out. The reason is not that companies fail to spend on data. It is that they underestimate how much data work a specific AI use case actually requires, and they end up either delaying the project or spending three times the planned data budget to unblock it.
Realistic budgeting: for RAG-style deployments, expect data preparation and pipeline work to run 40 to 80 percent of the model cost in year one, and 20 to 40 percent in steady state. For agentic use cases with tool integrations, the numbers are typically higher.
The hidden layer: evaluation and quality infrastructure
You cannot ship an AI system without knowing whether it is working. That means eval infrastructure: test sets, benchmark suites, regression testing, red-team exercises, drift monitoring, and the human review workflows that supply the ground truth. All of this is code, all of it takes engineering time to build, and all of it needs ongoing maintenance as the underlying models change.
The organisations skipping eval infrastructure are the same ones showing up in the MIT NANDA statistics as the 95 percent whose projects deliver no measurable P&L impact. You cannot measure what you have not instrumented, and eval is the instrumentation.
Realistic budgeting: I plan for eval and quality infrastructure at 15 to 30 percent of the model cost in year one, tapering to 10 to 20 percent in steady state. For high-stakes deployments (regulatory, safety-critical, customer-facing at scale) the ceiling is higher.
The hidden layer: human oversight and review
Every AI system in production needs human review at some level. The question is how much. Full human-in-the-loop review (every output is checked before it goes out) is expensive but sometimes necessary. Sample-based audit is cheaper but requires a workflow. Escalation review (humans review only outputs the system flagged as low-confidence) is efficient but requires the confidence scoring to actually work.
The cost here is not just the reviewer time. It is the workflow tooling to route work to reviewers, the training to keep reviewers calibrated, the feedback loops to feed corrections back into evaluation, and the management overhead of keeping the whole thing running.
Figure 1 shows the full stack in the shape I usually draw it. The visible layer is the tip; the hidden layers below often exceed the visible cost by three to five times combined.
The hidden layer: change management and adoption
The change management block in Figure 1 is deliberately drawn wider than the others, because in most enterprise deployments this is the single largest hidden cost in the programme, and the one most business cases treat as negligible. Change management includes training programmes, adoption campaigns, workflow redesign, manager enablement, communications, playbook development, community-of-practice support, and the internal consulting work to help teams integrate the tool into how they actually work.
Deloitte’s 2026 State of AI report found that the AI skills gap is now the biggest reported barrier to integration, and education (not workflow redesign, not tooling, but education) was the number one talent adjustment companies were making. That is a signal that organisations are spending on change management, but they are often not budgeting for it as an AI programme cost. It sits in the L&D budget, or the operations budget, or nowhere at all.
Realistic budgeting: for enterprise-scale AI programmes, change management typically runs 30 to 60 percent of the total programme cost in year one and 10 to 25 percent in steady state. That number surprises people. It should not.
The hidden layer: monitoring, incident response, and reliability
Once an AI system is in production, someone needs to be on call for it. That means monitoring dashboards, alerting rules, incident response runbooks, on-call rotations, post-incident reviews, and the ongoing work to improve reliability.
For any AI system that touches customers, this is not optional. A hallucination that reaches a customer at 2 AM needs someone who can respond. A latency spike that breaks the checkout flow needs a rollback plan. A drift event that pushes the model out of its acceptable performance range needs a recovery process.
Realistic budgeting: for production systems, monitoring and reliability typically run 10 to 20 percent of the model cost in steady state, and considerably more in year one when the runbooks and instrumentation are being built for the first time.
The hidden layer: security, compliance, and legal review
Every AI deployment triggers a security review, a data protection review, and often a legal review. Depending on your industry, it may also trigger a regulatory review under the EU AI Act, state-level rules like the Colorado AI Act, or sector-specific regimes. Each of those reviews takes time from expensive people (security engineers, privacy counsel, compliance officers) and often results in remediation work that adds cost.
This is one of the areas where the cost has been rising rather than falling, because the regulatory landscape has been accelerating. Budgeting AI compliance work at 2024 levels for a 2026 deployment is a common way to end up under-resourced.
The hidden layer: model refresh and version churn
Foundation models are refreshing at roughly six-month cadence at the frontier. Every refresh triggers work: re-running evals, updating prompts, revalidating outputs, sometimes retraining or reconfiguring downstream systems. The tokenizer change in Claude Opus 4.7 and later models, which produces roughly 30 percent more tokens for the same text, is a good example: existing cost projections had to be revised even though the per-token price was unchanged.
If your business case assumes the model you deployed in Q1 is the model you will still be running in Q4, it is probably wrong. Version churn is a real ongoing cost, and treating it as free is one of the fastest ways to run out of budget in year two.
The hidden layer: redundancy and multi-model provisioning
Concentration risk on a single model provider is a real business exposure. Most mature AI deployments now run multi-model, with fallback paths that let them route to a secondary provider if the primary is down or if pricing changes. Building and maintaining that redundancy is an ongoing cost, both in engineering time and in the incremental provider commitments needed to keep secondary channels warm.
Putting the stack together
Figure 2 shows how the stack shakes out across three common deployment shapes. The overall pattern holds across them: the visible layer is roughly 20 to 30 percent of the total, and the hidden layers dominate. The specific mix of hidden costs varies (change management dominates in high-touch deployments, eval and monitoring dominate in high-stakes deployments, data prep dominates in RAG deployments), but the total surround is consistently much larger than the visible tip.
Look at Figure 2 again and notice how consistently the hidden layers dominate across very different deployment shapes. The reason I go through all of this in detail is not to make AI projects look expensive. It is to make the business case survive contact with reality. Cases that get funded on the basis of visible-layer costs and then run into hidden-layer bills in month six are what produce the “AI project failed” headlines. The technology works. The budget was wrong.
BCR-05 takes the next step and builds these components into a proper multi-year total cost of ownership model. The point of doing that work upfront is that once you have honestly budgeted for the full stack, the ROI conversation becomes much more grounded. You may find the return is smaller than you thought. You may find it is still very good. Either way, you are working with numbers you can defend.