The number nobody plans for
When an organisation approves an AI project, the budget conversation is about the build cost. The maintenance budget, if it appears at all, is a percentage of the build cost (typically ten to fifteen percent), applied as an annual recurring line.
This number is not based on evidence. It is based on software maintenance conventions that do not account for the specific properties of AI systems: they drift, they require retraining, their dependencies change, and their failure modes are often silent.
This research documents the actual maintenance cost curve of nine AI systems I maintained over four years, from initial production deployment through year four.
The cost components
I tracked four cost components for each system:
Infrastructure and compute. Cloud infrastructure costs (compute, storage, inference), monitoring tooling, and data pipeline infrastructure that was dedicated to the AI system. This is the most predictable cost and the easiest to budget for.
Retraining and model updates. Engineering time for detecting drift, preparing retraining datasets, running retraining, evaluating the retrained model, and deploying the update. For systems using hosted models, this also includes the cost of fine-tuning runs and API costs during evaluation.
Dependency and integration maintenance. Time spent on library updates, API version changes, data schema migrations, and the occasional full re-integration required when an upstream system changed significantly.
Incident response. Time spent on diagnosing and resolving production incidents, including the time required to write post-incident reviews, implement corrections and validate that the correction worked.
The cost curve
All costs are indexed to the original build cost of each system (build cost = 1.00).
Year one: Average total maintenance cost: 0.22 of build cost (range: 0.14 to 0.31). The primary cost driver in year one is infrastructure and integration stability: fixing integration issues that were not fully tested before launch, building out monitoring that was deferred during the build, and managing the first model update cycle.
Year two: Average total maintenance cost: 0.31 of build cost (range: 0.23 to 0.44). The primary cost driver in year two is retraining: the model has been in production for twelve to eighteen months, drift is measurable, and the first major retraining cycle is required. Dependency maintenance also increases as more upstream dependencies reach end-of-life.
Year three: Average total maintenance cost: 0.38 of build cost (range: 0.29 to 0.52). By year three, the primary cost driver is the accumulation of technical debt in the integration layer. Systems that were built against a specific upstream data schema often require significant re-engineering when the upstream schema changes. The organisations that invested in modular integration design have lower costs in year three than those that did not.
Year four: Average total maintenance cost: 0.38 of build cost (range: 0.30 to 0.55). Cost growth stabilises in year four, but does not decline. The retraining and dependency maintenance cadence is established. Incident response costs are lower in year four than in year two (teams have more experience with the system’s failure modes). Infrastructure costs are higher (cumulative growth in the data pipeline).
Four-year total: The nine systems cost an average of 2.3 times their original build cost over four years, not counting the build cost itself. A system that cost 300,000 euros to build required approximately 690,000 euros in maintenance over four years.
The cost drivers that surprised me
Three findings surprised me in this data.
Incident costs in year two are consistently higher than in year one. I expected year one to be the most incident-intensive, because that is when teams are learning the system’s failure modes. The data shows the opposite: year two is more expensive for incident response than year one. The reason is that year-two incidents tend to involve failures that were not anticipated in the original design: drift-related failures, dependency failures, and the consequences of deferred monitoring investments. Year-one incidents tend to be integration issues that were partly anticipated.
Systems built with hosted models are not cheaper to maintain in year three. In years one and two, hosted-model systems have lower maintenance costs than custom-model systems: no retraining infrastructure, no model serving costs. In year three, hosted-model systems face a different cost: the hosted model is updated by the provider, the update changes the model’s behaviour, and the integration layer needs to be re-evaluated and sometimes re-engineered. For two of the nine systems, provider-driven model updates in year three were the single largest maintenance cost event of the four-year period.
Monitoring investment in year one has a measurable effect on year-two incident costs. The three systems in this dataset that had the most comprehensive monitoring infrastructure at the end of year one had the lowest year-two incident response costs. The relationship is not causal in a controlled sense, but it is consistent enough to inform investment decisions.
The implication for budgeting
A four-year total cost of ownership for an AI system is approximately 3.3 times the build cost: 1.0 for the build, and 2.3 for four years of maintenance. This is the number that should anchor the business case for an AI investment.
For a 200,000 euro build, the four-year TCO is approximately 660,000 euros. For a 500,000 euro build, it is approximately 1.65 million euros.
These numbers are not reasons not to build AI systems. They are reasons to be deliberate about which systems you build, and to build the maintenance infrastructure alongside the system, not after the first failure.