Maintaining an AI system after go-live: model upgrades, drift and regressions

Maintaining an AI system in production is the work that starts when the project ends, and it is the line most budgets forget. Software maintenance is a known quantity: dependencies, security patches, the odd bug. An AI system adds three sources of change that nobody in your company controls. The model vendor retires versions on its own calendar. The inputs drift as your business changes. And the prompts, which looked like configuration during the build, turn out to be code with all of code’s ways of breaking. Without a named owner and a small, regular budget, accuracy erodes in silence and the first sign is a complaint from a customer or an auditor.

On the systems we run for clients, maintenance is a defined service, scoped before go-live rather than discovered afterwards.

Model upgrades happen on the vendor’s calendar

Every model provider deprecates versions, with notice periods you do not negotiate, and the version your system was tuned on will be withdrawn whether or not you are ready. A new version is a different system. It formats answers differently, follows some instructions more literally and others less, and shifts accuracy on your task in a direction the release notes will not predict. We treat a model switch as a release. The full eval suite runs against the candidate, a human reads the diff, prompts are adjusted where the new model needs it, and the switch happens behind a flag with the old version kept for rollback. Teams that built to switch from the start do this in days. Teams whose prompts are tangled with one model’s quirks take weeks, under a deadline. In due diligence we call this model provider dependency, and a migration the team has rehearsed is what separates a managed dependency from a finding.

Input drift erodes accuracy without raising an error

The model did not change, the inputs did. A supplier moves to a new invoice template. A newly acquired subsidiary writes tickets in another language. A product line is renamed and the retrieval index still answers for the old name. None of this raises an exception; the outputs stay confident and the accuracy slides, a little each month. This is why observability has to include the signals that catch drift: the distribution of confidence scores, the rate of human corrections, the share of inputs outside the formats in the eval set. We review those weekly and sample production traffic monthly into the eval set, so the suite ages with the business it tests.

Prompt edits are code changes

The quickest way to break a working AI system is a well-meant prompt tweak made in a vendor console on a Friday afternoon. On our systems prompts live in the repository, every change goes through review, and the eval suite runs before merge. A prompt change that improves the case someone complained about and degrades three others is caught by the suite, and the review conversation is about the tradeoff rather than about who touched what. Version identifiers in the logs tie every output to the prompt and model that produced it, the first thing you need in an incident.

Costs move with volume and with the price list

The AI bill after go-live tracks two things you do not fully control: your own volume and the vendor’s pricing, which has moved in both directions and will again. We budget per unit of work (per document, per ticket, per conversation) and alert when the unit cost moves, because the usual culprit is an upstream change that grew the context (a longer system prompt, a new tool returning more data, a retrieval step pulling more chunks) rather than the volume itself. The levers in controlling LLM costs apply for the life of the system, and routing a slice of traffic to a smaller model after an upgrade is routine maintenance.

Name the owner, size the budget, write it into the contract

Someone watches the dashboard. Someone approves a model switch. Someone owns the eval set. If those three names are not written down at go-live, the system is unowned, and unowned AI systems degrade until they are switched off. In our experience a system of moderate scope needs a few engineer-days a month in steady state, more in the week around a model migration, and the yearly total stays well below the build cost. The rebuild that follows two years of nobody looking costs more than both.

When a vendor builds the system for you, the contract should say what happens after go-live. The items we would want in it:

• who re-runs the evals before a model switch, and within what delay of a deprecation notice
• where the prompts and the eval set live, and that you own both
• which drift signals are monitored, and who receives the alert
• a unit cost reported monthly
• a handover that lets another team run the system

The build is the visible part of the cost; maintenance is where the value is kept or lost, and its budget belongs in the same approval. If you have an AI system in production whose last eval run nobody can date, a review of how it is maintained is a short piece of work, and it tends to pay for itself at the next model deprecation.