Your AI project is live. Now who keeps it running?

The demo went well. The pilot proved the concept. You measured the results at four weeks, and the numbers held up. Everyone agrees: this was worth it.

Then month four arrives and something shifts. The automation that classified incoming orders at 94 percent accuracy is now at 81 percent. Nobody changed anything. Nobody touched the code. But the world changed, and the system did not keep up.

This is the part of AI adoption that almost nobody talks about.

Why AI automations decay on their own

Traditional software does what it was built to do until someone changes it. An invoice template does not quietly start producing wrong numbers. AI is different. Most AI systems learn patterns from data, and when the underlying data changes, the patterns stop fitting.

This is called model drift. It is a property of any system that depends on patterns in the real world. Customers change ordering habits. Suppliers update document formats. Seasonal shifts alter the distribution of requests. The automation was trained on what the world looked like six months ago, and the world moved on.

Model drift is gradual. That is what makes it dangerous. Nobody notices a 1 percent accuracy drop per month. But after six months, you are at 88 percent instead of 94 percent, and your team starts double-checking everything again. The time savings erode quietly.

The three things that actually break

I see the same three failure modes in SME automations.

Data pipeline changes

Your automation pulls data from somewhere: an ERP system, an email inbox, a shared folder. When something changes upstream, the pipeline breaks. A system update renames a field. A supplier starts sending PDFs instead of CSVs. These are not AI problems. They are plumbing problems, but they take down the AI system just as effectively.

Slow accuracy degradation

This is model drift in action. The system still runs but the output is subtly less accurate. A classification that caught 95 percent of cases now catches 85 percent. It does not crash. It just quietly gets worse until someone notices the results no longer match expectations.

Process changes nobody communicated

Someone in operations adds a new product category. A new regulation requires an extra field in outgoing documents. The process changed, but nobody told the automation. This is the most common failure mode I see, and it is entirely preventable.

The role nobody budgets for: the AI owner

Every AI automation needs an owner. Not a developer. Not an external consultant who checks in once a quarter. A person inside the organisation who watches the output and raises the flag when something looks off.

This is typically 2 to 4 hours per week. Not a full-time job. It is a responsibility attached to an existing role, usually the operations lead or the person who championed the project.

What the AI owner does:

• Checks output quality weekly. Not every transaction, but a representative sample. If the system classifies 200 orders per week, spot-check 15 to 20.
• Logs edge cases. When the system gets something wrong, write it down. After a few weeks, patterns emerge that tell you whether you need a retrain, a rule adjustment, or a process conversation.
• Acts as the bridge between the business and the technical side. When accuracy drops, the AI owner does not need to fix it. They need to notice it and communicate it clearly.

Companies that assign this role see measurably better outcomes. In my experience, the difference is 25 to 30 percent higher sustained accuracy after twelve months compared to companies that treat automations as set-and-forget.

When to retrain, when to adjust, when to rebuild

Not every problem needs the same response.

Retrain when the data distribution has shifted but the fundamental task is the same. Your order classifier still needs to classify orders, but the mix of order types has changed. Feed it recent examples and retrain. This is typically a few hours of work and should happen every three to six months.

Adjust rules when the issue is a specific, identifiable edge case. A new supplier format, a new product category, a changed field name. These are targeted fixes that do not require retraining the entire model. Most take less than a day.

Rebuild when the underlying process has changed so fundamentally that the original design no longer fits. This is rare, maybe once every two to three years, and usually triggered by a major business change rather than a technical failure.

Most maintenance is small. A few hours per quarter. The companies that struggle are the ones who do nothing for a year and then face a big, expensive fix.

What maintenance actually costs

A reasonable expectation for ongoing AI maintenance is 15 to 25 percent of the initial build cost per year. If you spent 8.000 euros on an automation, budget 1.200 to 2.000 euros annually to keep it running well.

That covers periodic retraining, edge case fixes, pipeline adjustments, and the occasional larger update. It does not include the AI owner’s time, which is an internal cost.

This is not a hidden fee. It is the same principle as maintaining any business-critical system. You do not build a website and never update it. You do not install an ERP and skip the maintenance contract. AI is no different.

A simple maintenance rhythm

Monthly: The AI owner spot-checks output quality and logs any issues.

Quarterly: Review logged issues. Decide which need a retrain, a rule fix, or a process conversation. Execute the small fixes.

Annually: Step back and evaluate. Is the automation still solving the right problem? Has the process changed enough that the approach needs rethinking? Compare current performance to the original baseline.

This is not complicated. It is just consistent.

The automations that last

The AI projects I see still delivering value after eighteen months share three traits. They have an owner. They have a maintenance rhythm. And the organisation treats them as living systems, not finished products.

The ones that fail are not technically inferior. They are organisationally orphaned. Nobody watches. Nobody adjusts. The accuracy drifts, the team loses trust, and eventually someone says the project did not work. It did work. It just was not maintained.

Building the automation is the visible part. Maintaining it is where the long-term value lives. At Virada, this is why ongoing support is part of our approach.

Want structured support to keep your automations performing? That is what Stap 3 of our approach covers.