What maintaining an AI system actually involves after launch

Mostly work that has no equivalent in ordinary software. The system can get worse without anything breaking, because the model underneath it changed, so maintenance here means continuously measuring behaviour rather than watching for errors.

JarvisBitz

Maintenance is the part of an AI project that gets estimated last and understood least. It usually appears in a proposal as a support percentage, which is how ordinary software is priced and which describes almost none of the work these systems actually need.

The difference is one property. A conventional application does not get worse on its own. An AI system can, without anything breaking, without an error being thrown, and without anyone deploying anything, because the model underneath it changed.

The recurring work that has no equivalent

Providers move underneath you. Models get retired on a cadence that is closer to annual than occasional, and the replacement behaves differently in ways your test suite will not catch. We go through how to survive that in moving off a retired model. The point here is that it is not an incident, it is a scheduled cost, and it arrives whether or not the roadmap has room.

Behaviour drifts without a deploy. Even between retirements, a provider updating a model can change how yours responds. Groundedness slips, formatting shifts, a refusal boundary moves. Nothing in your monitoring fires, because from an infrastructure perspective the system is healthy. Somebody notices weeks later, usually a customer.

Your inputs drift too. A new supplier sends invoices in a different layout, a product line launches with vocabulary nobody trained against, a policy changes and the documents describing it do not for a month. The system was correct for the world it was built in and the world moved.

What the retainer actually buys

Named concretely, because support is too vague to price and too vague to hold anyone to.

• The evaluation set runs on a schedule, not only before releases, and somebody reads the result. This is the only mechanism that catches silent degradation.
• Provider change monitoring, so a deprecation or model update is noticed when it is announced rather than when it lands.
• Migrations when they come, including the replay and the parser checks, budgeted as recurring rather than exceptional.
• New failure classes become permanent test cases, which is what stops the same problem recurring annually.
• Cost review, because token usage creeps as prompts grow, and nobody notices a gradual slope. The mechanism is in spend attribution.
• Content and index upkeep for retrieval systems, which quietly go stale as the corpus changes underneath them.

Doing it yourself, which is often right

None of this requires the people who built the system, and we would rather say so. What it requires is three things being in place, which is a fair test of whether a handover was real.

• The evaluation set, owned by you, runnable by someone new. Without it none of the rest is possible, which is why it is the artifact we argue hardest about in what you should own.
• Logging that makes a wrong answer reconstructable, to the schema in what to log.
• One named person whose job includes reading the evaluation result. Not a team, a person. This is the part that lapses first.

Where those exist, a competent engineer picks this up in a week. Where they do not, the maintenance conversation is really a rebuild conversation, and it is better to find that out deliberately than during an incident.

What a healthy month looks like

Worth describing concretely, because maintenance is otherwise an abstraction people either overfund or ignore.

The evaluation set runs, probably weekly, and somebody looks at the number. Most months it has not moved and that takes ten minutes. Occasionally it drops, and the value of the whole arrangement is that you find out in a week from a chart rather than in a quarter from a customer.

A handful of production failures get triaged, and the ones that represent a class rather than a one off get added to the evaluation set. Costs get glanced at against the previous month. Provider announcements get read. None of this is heavy, and the total is usually a day or two a month for a system of moderate size, which is a very different conversation from an open ended support retainer.

Then, once or twice a year, a migration arrives and consumes considerably more than that. Planning for the steady state and being surprised by the lumps is the pattern that leaves teams feeling maintenance was mis-sold, when the real problem was that only half of it was described.

Budgeting it honestly

Two things to fund, and they behave differently. There is a running cost that is roughly steady: inference, infrastructure, and the time to read the evaluation result. And there is a lumpy cost that arrives on someone else's schedule, which is model migration.

Teams that budget only the first are surprised annually. The useful framing when asking for the number is to treat model migration the way you treat a major dependency upgrade: not optional, not predictable in timing, and considerably cheaper if the harness for it already exists.

If you want an honest read on what your system will need, and whether your own team can carry it, a free AI audit covers whether the three prerequisites are actually in place. How we run AI systems in production covers the instrumentation, and our engagement model covers how support is structured when you would rather we carried it.

Related reading

LLM data residency: what to configure and what to verify

Residency is a configuration you set, not a property you inherit, and the defaults differ per vendor and change without notice. Establish four things in writing for each provider, then enforce the rest at your own gateway, because that is the only layer you control.

LLM spend: attribution before optimisation

You cannot cut what you cannot see. Most teams optimise models and prompts before they can attribute a single dollar to a team, feature or customer, which means they are guessing. Meter at the gateway first, then cache, route and cap in that order.

What to log in an LLM system so you can debug it later

A 200 response tells you almost nothing about an AI system, because the failure you care about is a confident wrong answer that returned successfully. Log the inputs, the retrieved context, every tool call and the guardrail outcomes, or you will be debugging from screenshots.