The Costs Missing From Most AI Business Cases
The hidden costs of AI projects are rarely hidden on purpose — they are the costs that do not arrive as a single invoice, so they are easy to leave out of a business case built around licence fees and development hours. Six categories account for most of what gets missed: ongoing MLOps and retraining, change management, model drift monitoring, internal opportunity cost, the cost of a second model tuning cycle, and governance or compliance review. Missing even one is usually enough to make an otherwise solid business case look naive to a finance reviewer who has seen an AI programme run over budget before.
Six Costs Worth Checking Before the Case Goes to Finance
MLOps and retraining. A deployed model is not a finished cost — it needs monitoring, periodic retraining, and the infrastructure to support both, for as long as it runs in production. This is operational spend, not a one-time build cost, and it belongs in the ongoing OPEX line, not folded into the capital budget. It gets missed for a structural reason: a capital budget is approved once, at the start, while an OPEX commitment needs a standing funding line that renews every year the system stays live — and nobody on the programme team owns the job of requesting that renewal until the first retraining cycle is already overdue. The components worth pricing explicitly are a monitoring dashboard that tracks prediction quality over time, a defined retraining pipeline rather than an ad hoc one, and the engineering hours to run it on a schedule. A programme that skips this line doesn't avoid the cost — it just discovers it as an unplanned emergency the first time the model's accuracy visibly degrades in production.
Change management. Training, internal communications, and a support network for the people whose work actually changes. Cut from the budget first when costs come in high, and the single workstream most responsible for whether the programme generates any value at all. It gets cut first for a specific reason: it is the only one of the six categories with no natural technical owner and no line item that looks essential on a build plan, so when the budget needs trimming, it reads as optional in a way that a server cost or a licence fee does not. In practice it covers at least three components — role-specific training (a frontline user's needs are different from a manager's), a communications cadence that keeps the rollout visible rather than a single launch announcement, and a small internal champions network that answers day-to-day questions faster than a support ticket can. Underfund this line and the technical deployment can succeed while the business outcome fails anyway, because the people the system was built for never actually adopted it.
Model drift monitoring. Models degrade as the data they see in production drifts from what they were trained on. Watching for that, and retraining on a defined cadence, is a recurring cost that starts at go-live and does not stop when the programme closes. Drift shows up in ordinary, unglamorous ways — a seasonal pattern the training data never saw, a change in an upstream system that quietly alters the shape of the input data, a shift in customer behaviour that makes last year's patterns less predictive. None of that is a bug; it is simply what happens to any model left running against a world that keeps changing. The cost has two parts: the monitoring infrastructure that flags when performance has drifted past an acceptable threshold, and the retraining-and-revalidation cycle that follows — pulling fresh data, retraining, and testing the new version before it replaces the one in production. Treating this as a one-time cost rather than a recurring cadence is one of the more common ways a business case understates its true run-rate.
Internal opportunity cost. The engineers, analysts, and business stakeholders the programme pulls from other work do not appear on an invoice, but their time is a real cost — and the one most likely to surface mid-programme as a resourcing conflict if it was not acknowledged upfront. A data engineer spending three days a week on the AI programme is three days a week not spent on whatever else that role was funded to do, and that gap does not close itself just because it was never written down. Estimating it honestly means naming the specific roles the programme actually pulls from — not just the dedicated project team but the subject-matter experts pulled in for data validation, the business analysts asked to review outputs, the engineers borrowed for a sprint — and pricing their time at a fully-loaded rate for the hours actually diverted. Skipping this line doesn't make the cost disappear; it just means the business unit that lost the capacity finds out the hard way, partway through the programme, instead of agreeing to it at the start.
A second tuning cycle. AI model development is iterative in a way standard software estimation is not. A single-point development estimate that assumes the first model clears its performance threshold is optimistic by default; a credible Conservative scenario prices in the cost of one additional cycle. The reason this differs from a normal software estimate is structural: a software feature either meets its acceptance criteria or it doesn't, and the scope is knowable in advance, but a model's real performance can only be found out by actually building and testing it against real data — data quality issues, feature engineering that needs another pass, or a result that simply falls short of the bar required for business use at user acceptance testing. None of those are signs the programme went wrong; they are a normal part of how AI delivery actually works often enough that planning for them is prudent, not pessimistic. The planning implication is specific: price one additional training-and-tuning cycle explicitly into the Conservative scenario, as its own named line, rather than folding it into a vague contingency percentage that nobody can point to when asked what it covers.
Governance and compliance review. Legal review, a cybersecurity assessment, and whatever internal audit or approval process the organisation requires before an AI system touches production data — a cost category that is real in almost every enterprise deployment and rarely gets its own line item. What makes this one expensive to miss isn't the review itself, which is usually a fixed, bounded cost — it's the timing. These reviews tend to get engaged only once a model is "basically done," at which point a legal finding about the training data, a security concern about a new data pathway into production, or a privacy question triggered by personal data in the inputs can send the team back to rework a model that was already considered finished. Pulling governance and compliance stakeholders in early, while the model is still being designed rather than after it's built, is what turns this from a late, expensive surprise into a bounded, planned cost.
For the full breakdown of how these costs fit into a structured, finance-ready cost model — including the specific budget percentages and estimation ranges each category typically needs — see Why Most AI Business Cases Collapse Under Finance Scrutiny.
Why This List Is Worth Running Before, Not After, the Finance Review
None of these six categories is exotic or hard to estimate once named. What makes them "hidden" is simply that nobody on the programme team owns the job of checking for them, because none of them shows up on a vendor invoice or a standard IT cost template. Three of the six — MLOps, drift monitoring, and governance review — are missed because they live in the operational phase, after the programme team that built the business case has moved on to the next thing. The other three — change management, opportunity cost, and a second tuning cycle — are missed because none of them looks essential on a first pass at a budget, right up until the point where their absence becomes the reason the programme underdelivers. Running this list as a checklist against a draft business case — before it reaches finance, not after a reviewer finds the gap — is a five-minute exercise that avoids a much longer conversation about why the number changed mid-programme.
The AI Investment ROI Model includes a complete cost model covering ongoing operational cost, change management, and an AI non-linearity adjustment for a second tuning cycle in the Conservative scenario, with a separate CAPEX vs OPEX breakdown so none of these categories get folded into a single, understated total.
→ Available at www.viksya.com