Reef TRHSix months after the launch that everyone celebrated, the assistant was quietly getting worse. Nothing broke. It still answered in a second, still sounded certain, still looked in the dashboard exactly as it had on the day it went live. But the answers had drifted. A product had been renamed, a policy had changed, and the model kept citing the old ones with all its original confidence. One afternoon a support lead noticed, and asked in a channel: who looks after this now? The thread stayed quiet. Nobody's name was on it.
That silence is one of the most common failures I see in production AI, and it has nothing to do with the model. The build succeeded. The launch succeeded. What nobody scoped was the part that starts the morning after handover: someone whose actual job is to keep the thing right.
Launch is the start of the job, not the end of it
A traditional software feature is mostly finished when it ships. It does what it was written to do and keeps doing it until someone edits the code. An AI system is different in a way that is easy to miss until it bites: its accuracy depends on a world that keeps moving. Products get renamed, prices and policies change, and customers start asking things they were not asking in the quarter you trained on. The code can sit untouched and the system still gets worse, because the ground beneath it shifted.
So the question a buyer should ask is not "is it live?" but "who owns it now that it is?" That is the seat most org charts do not have. A pilot that stalls on the way to production often stalls for exactly this reason: it had an enthusiastic sponsor to get it launched and no operator to keep it alive.
AI rots quietly, and that is the dangerous part
That contrast is the whole danger. You find out about a crash within seconds, and about degradation from a customer weeks later. The system does not throw an error when it starts being wrong a little more often than it was; it produces the wrong answer with exactly the fluency of the right one. Unless someone is watching the number, nothing in the building knows the slide is happening.
Which is why the owner needs something to watch against. An answer key built before launch, the set of cases with known-correct answers and the confidence floor below which the system defers to a person, is not just a go-live gate. It is the instrument the owner reads each week to catch the slide while it is still small, not after it has become the reason people stopped trusting the tool.
What owning it actually means
Owning an AI system is a real, recurring job, and it is worth naming what it involves before you assume it will happen on its own:
- Watch the number. Track accuracy against the answer key on a schedule, not when someone complains, so a slow decline is visible while it is still small.
- Own the escalations. Read what the system handed to a human and why, because that queue is the earliest signal that the world has moved.
- Decide when to retrain. Judge when drift has crossed from noise into a real gap, and own the call to refresh the data or the prompts.
- Keep the guardrails honest. Confirm the system still defers when it should, and that the confidence floor has not been quietly loosened to make a metric look better.
- Answer for it. Be the name in the channel when someone asks who looks after this.
None of that is glamorous, and none of it shows up in a demo. It is also the difference between a system that compounds in value and one that decays into the thing everyone has quietly stopped trusting but nobody has switched off.
The vendor won't do it, and neither will the ticket queue
The two default owners both fail, in predictable ways. The vendor's incentive ends at handover; their job was to ship it, and a renewal conversation is not the same as someone watching your accuracy on a Tuesday. The IT queue treats the system as infrastructure: is it up, is it responding, is the bill paid. All true, all beside the point, because an AI system can be perfectly available and steadily wrong at the same time.
What the job needs is a named operator who owns correctness rather than uptime, someone close enough to the business to know when an answer is wrong, not only when the service is down. The budget for that rarely gets set aside, which is a problem in itself, because the real running cost of AI is mostly the work that keeps it working, not the tokens it spends.
So before you celebrate a launch, find the name. Not the sponsor who championed it, not the vendor who built it, but the person who will answer, six months from now, when someone asks whether it is still right. If that seat is empty, the system does not have an owner. It has an expiry date.
Common questions
Who should own an AI system after it goes live?
A named operator inside the business who owns correctness, not just uptime, and is close enough to the work to recognise a wrong answer. It can be an existing employee given the time and the tooling, or a partner who stays on to run it. What matters is that the seat is not empty.
Why does an AI system get worse if nobody changes the code?
Because its accuracy depends on a world that keeps moving. Products, policies and the questions customers ask all change, and a model trained on last quarter keeps answering as if nothing did. The code is untouched; the ground under it shifted. This is called drift, and it happens silently.
How is maintaining AI different from maintaining normal software?
Normal software fails loudly: it crashes or throws an error you can see. An AI system fails quietly, producing fluent, confident answers that are slowly more wrong. So maintenance is less about uptime and more about watching accuracy against a known baseline and catching the decline while it is still small.