The AI ROI Decay Problem: Why Returns Drop 40% After Year One

Your AI project launched. The pilot numbers looked great. Six months later, your CFO is asking why the returns are half what you promised. This is the ROI decay problem, and it hits nearly every enterprise AI deployment I have seen in twenty years of running technology at major banks. The cause is not bad models or bad strategy. The cause is that nobody budgets for what happens after go-live.

The Build-to-Run Ratio Nobody Talks About

Here is the number most AI leaders get wrong: for every dollar you spend building an AI solution, you will spend between $2.50 and $4.00 running it over three years. Not maintaining it. Running it. That includes compute, model monitoring, data pipeline upkeep, retraining cycles, and the people who keep it all working.

In traditional software, the build-to-run ratio sits around 1:1.5 over three years. You build an application, you patch it quarterly, you keep the lights on. AI is different because the inputs change constantly. Customer behavior shifts. Regulations update. Data sources drift. Your model was trained on last year's world, and it is making decisions in this year's world.

At one bank I worked with, a fraud detection model cost $1.2M to build and deploy. Impressive pilot results. Caught 23% more fraudulent transactions than the rules-based system it replaced. The year-one ROI calculation showed $4.8M in prevented losses against $1.2M in cost. Clean win. By month 14, the model's precision had dropped 31% because spending patterns shifted post-pandemic. Retraining, recalibration, and a new data pipeline cost another $800K. Nobody had budgeted for it.

That is not a failure of AI. That is a failure of planning. And it happens everywhere.

The Five Run Costs That Kill Your ROI

I have tracked AI project costs across dozens of deployments. Five categories of run cost consistently surprise teams that only budgeted for the build phase.

First: model retraining. Most production models need retraining every 60 to 120 days to maintain accuracy. Each cycle costs between $15K and $200K depending on model complexity, data volume, and whether you need human reviewers in the loop. Budget for six retraining cycles per year, not two.

Second: data pipeline maintenance. Your model is only as good as its inputs. Data sources change formats, go offline, or get deprecated. At one institution, a key vendor changed their API structure with 30 days notice. The downstream AI system needed $340K in rework. Nobody had a line item for that.

Third: monitoring and observability. You need people watching model performance daily. Not just accuracy metrics, but drift detection, bias monitoring, and output quality checks. For a regulated industry, this is not optional. A dedicated ML ops engineer costs $180K to $220K fully loaded. Most teams think they can split this across existing staff. They cannot, not once you have more than two models in production.

Fourth: compute costs at scale. Your pilot ran on a fraction of production volume. When you go from processing 10,000 transactions a day to 2 million, your cloud compute bill does not increase linearly. It spikes. One team I advised saw their monthly AWS bill go from $8K during pilot to $67K at production scale. That is $708K per year they did not forecast.

Fifth: compliance and audit overhead. Every quarter, someone from risk or audit will ask you to explain how the model makes decisions. You need documentation, explainability reports, and sometimes external validation. This is 200 to 400 hours of senior staff time per year, per model. At blended rates, that is $80K to $160K annually that never appears in the original business case.

The Three-Year TCO Framework That Makes CFOs Trust Your Numbers

After getting burned on optimistic ROI projections twice, I built a framework I call the 3Y-TCO model. It forces teams to project costs across three years, not just the build phase. Here is how it works.

Start with your build cost. Everything from data preparation to model training to integration to testing. Call this your Year Zero number. Most teams get this right because it is the budget they are asking for.

Year One run costs: take 60% of your build cost. That covers your first round of retraining, your monitoring setup, your initial compute scale-up, and the inevitable surprises. If your build cost is $1M, budget $600K for Year One run costs. Yes, that means your real Year One cost is $1.6M, not $1M.

Year Two run costs: take 45% of your build cost. By now your monitoring is mature, your retraining cadence is established, and your team knows the system. But you will likely need a model refresh (not just retraining, but architectural changes) as business requirements evolve. If your build cost is $1M, budget $450K.

Year Three run costs: take 35% of your build cost. The system is stable, but you are now dealing with technical debt, potential platform migrations, and the reality that the team who built it may have moved on. Knowledge transfer and documentation gaps show up here. Budget $350K on a $1M build.

Total: a $1M AI build actually costs $2.4M over three years. Your ROI calculation needs to clear that bar, not the $1M bar. When I started presenting AI business cases with these numbers, two things happened. Some projects did not get funded because the honest math did not work. And the projects that did get funded actually delivered on their promises because we had real budgets for real costs.

How to Prevent ROI Decay After Launch

Knowing the costs is half the problem. The other half is actively managing them down. Four practices make the difference between AI projects that hold their ROI and ones that bleed money.

Set retraining triggers, not retraining schedules. Most teams retrain on a calendar. Every 90 days, whether the model needs it or not. Instead, set performance thresholds. When accuracy drops below X or drift exceeds Y, you retrain. One team I worked with cut their retraining costs by 40% by switching from quarterly scheduled retraining to triggered retraining. Some quarters the model was fine. They saved $120K in a year.

Negotiate compute commitments early. If you know your production volume, lock in reserved instances or committed-use pricing before you launch. Waiting until you are at scale means paying on-demand rates, which can be 3x higher. One team saved $290K annually just by signing a one-year compute commitment two months before production launch instead of two months after.

Build explainability into the model from day one, not as an afterthought. Retrofitting explainability costs 3x to 5x more than building it in. I watched a team spend $400K adding SHAP explanations to a model that was already in production because the risk team demanded it. If they had included it in the original build, it would have added $90K.

Staff for run, not just build. The biggest mistake I see: teams are assembled to build and deploy, then disbanded. The model goes to a general support team that does not understand it. Within six months, small issues become big problems because nobody catches drift early. Keep at least one person from the original build team assigned to the model for its first full year in production. The cost of that person is a fraction of the cost of a production failure.

Actionable Takeaway