The Hidden Cost of Maintaining an AI System

A model that works on launch day doesn't stay working for free. Real-world data shifts under it, the foundation model it depends on gets deprecated on someone else's schedule, and the parts of the system quietly become more entangled the longer it runs. None of that shows up in a one-time build quote, and most of it isn't optional to skip.

This isn't a hypothetical risk. It's the specific, well-documented reason machine learning systems carry a different kind of technical debt than regular software — one that compounds silently instead of announcing itself.

Why does an AI system need ongoing maintenance that regular software doesn't?

Regular software does roughly what it did on launch day, indefinitely, unless someone changes the code. An AI system doesn't get that guarantee, because its behavior depends on things outside the code itself: the data it sees and, for anything built on a foundation model, a third party's model that keeps changing after you've shipped.

Google's own 2015 research paper "Hidden Technical Debt in Machine Learning Systems," by D. Sculley and a team of Google engineers, put this directly: it's dangerous to think of a working ML system as a one-time win, because real-world ML systems commonly incur "massive ongoing maintenance costs" that traditional software doesn't carry in the same way.

The paper names several specific mechanisms behind that cost, and they're worth understanding individually, because "AI maintenance" as a phrase hides how structural and varied the actual causes are.

What is entanglement, and why does it make maintenance harder?

Entanglement means that in most ML systems, changing one input, feature, or setting can silently change the model's behavior everywhere else, not just in the part you touched.

Sculley's paper names this the CACE principle: Changing Anything Changes Everything. It applies to more than obvious inputs. It covers hyperparameters, sampling methods, convergence thresholds, and data selection choices too. A tweak made to fix one specific case can quietly shift outcomes in cases nobody was looking at.

That's a fundamentally different maintenance shape than a normal codebase. In regular software, a well-isolated change stays isolated. In an ML system, the paper argues, models are essentially "machines for creating entanglement" — which makes isolating the effect of any single improvement or fix genuinely difficult, not just inconvenient.

The practical consequence shows up as a specific kind of maintenance tax. A team can't just "fix one thing" the way they would in a normal codebase and trust the rest of the system is unaffected. Every change has to be re-validated against the whole system's behavior, not just the part that was touched, because the entanglement means there's no reliable way to predict which other outputs shifted as a side effect.

What other specific costs does the research identify?

Beyond entanglement, Sculley's paper names several other distinct sources of ongoing cost, each with its own maintenance burden:

• Hidden feedback loops — when a model's own predictions influence the future data it gets trained on, creating a loop that can quietly destabilize behavior over time without anyone changing anything on purpose.
• Undeclared consumers — when a model's output gets used somewhere the original team never planned for, meaning a change made for one purpose can break something no one remembered depended on it.
• Unstable data dependencies — treating a data source as stable when it isn't creates the same kind of maintenance burden as tightly coupled code, except it's often invisible until the data changes and something downstream breaks.
• Configuration debt — the accumulated hyperparameters, feature flags, and tuning choices needed to reproduce a working model, which become their own maintenance liability once nobody remembers exactly why each one was set the way it was.
• Changes in the external world — real-world data distributions shift over time (this is what's usually meant by "model drift" or "concept drift"), and a model trained on last year's patterns doesn't automatically adapt to this year's.

None of these are edge cases. They're named, specific, structural properties of how ML systems behave once they're running against real data, not build-time mistakes that better engineering avoids entirely.

Why does "changes in the external world" deserve its own attention?

Because it's the one type of cost that has nothing to do with how well the system was built, and everything to do with the fact that the world it was built for doesn't hold still.

A model is trained on a snapshot of how things worked at a specific point in time — what customers searched for, what fraud looked like, what a typical transaction pattern was. Sculley's paper is direct about the consequence: real-world systems have to adapt to shifting data distributions, and a model that isn't monitored for that shift will keep producing confident answers that quietly stop matching reality.

This is what's usually meant by model drift or concept drift, and it's structurally different from a bug. A bug is something that was wrong from the start and gets fixed once. Drift is something that was correct at launch and becomes wrong later, on its own, with no code change required to cause it. Catching it requires ongoing monitoring specifically built for that purpose — comparing live outcomes against what the model predicted, not just checking that the system is technically still running.

That's the part of "AI maintenance" most likely to get skipped in a build quote, precisely because nothing about it looks broken on the day the system ships.

Why do companies end up building entire platforms just to manage this?

Because the maintenance burden is large and continuous enough that ad hoc handling doesn't scale.

Uber's own engineering team built and published details of Michelangelo, an internal machine learning platform specifically to automate the ongoing lifecycle of models in production — retraining, revalidating, and redeploying models on fresh data on a continuous basis, rather than treating each model as a one-time deliverable.

That's a direct, real-world confirmation of the same point Sculley's paper makes on paper: keeping a model accurate isn't a single task completed at launch. It's a recurring operational commitment serious enough that a company the size of Uber invested in dedicated internal infrastructure just to manage it, rather than handling it manually per model.

A smaller team without Uber's engineering resources still faces the same underlying cost. It just shows up as manual, recurring work instead of automated infrastructure — which usually means it's easier to underestimate, not less real.

Does this apply to newer LLM-based features too, or just classic machine learning?

Both, though the mechanism is different for each.

Classic ML models drift because the real-world data feeding them shifts over time, exactly as Sculley's paper describes. LLM-based features carry a related but distinct cost: the foundation model itself is owned and controlled by someone else, on their own release and retirement schedule.

OpenAI's own published API documentation lays out a concrete deprecation policy: the company provides a minimum of six months' notice before retiring a generally available model, and at least three months for more specialized model variants, with impacted developers notified directly by email and documentation. That notice period is generous by industry standards, but it's still a forced, recurring migration cost that has nothing to do with whether your product's logic changed at all.

A feature built against a specific model version doesn't stay static. It either gets migrated on the provider's timeline, or it stops working when that model is retired. That's a maintenance cost with a real deadline attached, not a hypothetical future expense.

The notice period matters, but it doesn't remove the work. Six months is enough time to plan a migration if someone is actually watching for the announcement. It's not enough time if nobody owns that responsibility, and the deprecation notice arrives as a surprise the week the model actually gets turned off. Either way, the underlying cost — re-testing the feature's behavior against a new model version, since even a same-provider upgrade can shift outputs in ways a prompt didn't change — has to be paid by someone, on a timeline set by the provider, not by the product roadmap.

How should this actually change how an AI feature gets scoped?

The practical fix isn't avoiding AI. It's naming the ongoing cost honestly before the build starts, instead of discovering it as a surprise after launch.

That means answering a few concrete questions at scoping time, not after something breaks:

1. Which parts of this system depend on data that will realistically drift, and how will that drift actually get noticed?
2. Which parts depend on a third-party model with its own deprecation schedule, and who is responsible for tracking that schedule?
3. What does the entanglement look like here — if one input or setting changes, what else in the system is likely to shift as a result?

A build quote that only covers getting the system working on day one is answering a different, easier question than "what does this cost to keep working." Both are legitimate questions. Only one of them is usually asked upfront.

That's the same reason Ingenetic's AI Readiness Audit treats ongoing maintenance as part of the real scope of a build, not an afterthought discovered later — see How It Works for how that audit is structured.

Frequently asked questions

Why is AI expensive to maintain?

Because an AI system's behavior depends on real-world data and external model providers that both keep changing after launch. A traditional app does roughly what it did on day one unless someone edits the code. An AI system can quietly get worse from data drift, or stop working outright when a foundation model provider deprecates the version you built on — neither of which is a bug you can just fix once and forget.

What does AI maintenance actually include?

At minimum: monitoring for data and model drift, periodic retraining or re-evaluation, tracking and migrating away from deprecated model versions, and managing the tangled dependencies between features, data pipelines, and configuration that a working ML system accumulates over time.

Is this only a problem for machine learning models, or does it apply to LLM-based features too?

Both. Classic ML models drift because real-world data shifts under them. LLM-based features carry a different but related cost: the foundation model itself changes over time, gets deprecated on the provider's schedule, and can shift behavior even without a prompt change. Different mechanism, same category of ongoing cost.

Can this maintenance cost be estimated upfront?

Roughly, if someone actually asks the question before the build starts. It requires naming which parts of the system depend on data that will drift, which parts depend on a third-party model with its own deprecation timeline, and how those will be monitored. Most build quotes skip this because it's easier to scope a launch date than an ongoing commitment.

Does this mean AI systems aren't worth building?

No. It means the true cost of an AI system includes what happens after launch, not just what it costs to ship it. A system built with that cost accounted for from the start is a different, more durable thing than one where maintenance gets discovered as a surprise six months in.