Why does an AI system need ongoing support after it is delivered?

An AI system needs ongoing support after delivery because the world around it keeps moving. The vendor retires the model, data changes format, the company changes its process and volume grows. Without someone watching, an automation that worked on delivery day gets steadily worse, usually without warning.

Have you ever had a support bot that answered well in its first month and, months later, started getting wrong things it used to get right? Nobody touched it. That was exactly the problem.

In his Life of Theseus, Plutarch tells how the Athenians kept, for centuries, the ship in which the hero returned from Crete after defeating the Minotaur. To preserve it, they removed the old planks and put new timber in their place. Philosophers began to argue whether, once every piece had been replaced, it was still the same ship. Later, Thomas Hobbes made the question harder: what if someone built a second ship out of the removed planks?

The philosophical question can stay with the philosophers. The practical detail is different: the ship only stayed afloat because someone kept replacing the planks. Software systems in real use work the same way. Either someone looks after them piece by piece, or they rot at the dock.

In the 1970s, researcher Meir Lehman studied how large programs evolve and formulated what became known as Lehman's laws. The first, called continuing change, says that a system solving a real-world problem must be continually adapted, or it becomes progressively less satisfactory. The second says that complexity increases over time unless explicit work is done to keep it under control.

With AI, this speeds up. In 2015, Google researchers published Hidden Technical Debt in Machine Learning Systems at the NeurIPS conference. The paper warns that it is dangerous to think of machine learning's quick wins as coming for free, and states that it is common for real-world systems to incur massive ongoing maintenance costs. Among the risks it lists are data dependencies, configuration issues and changes in the external world.

There is also a very concrete reason. OpenAI's deprecations page says the company regularly retires older models and that software relying on them may need updates to keep working. The minimum notice for generally available models is six months, but preview models may be retired with much shorter notice, such as two weeks. Anyone who built customer service on top of a model and does not follow these notices finds out about the change when the service stops.

Support is not sitting on call waiting for the phone to ring. It is scoped work that should be written into the contract. In DOUVRAS projects, it comes in three formats, depending on the size of the operation:

• Basic support. Fix what broke, answer the team's questions and keep the system running.
• Support with adjustments and monitoring. On top of that, follow logs and alerts, adjust answers, rules and integrations, and act before a failure reaches the customer.
• Continuous evolution. Add periodic reports and planned improvements, such as connecting a new system or automating the next part of the process.

In any format, the technical foundation comes from the project. In our automation and integrations work, the scope already includes logs, alerts and a contingency procedure. In AI agents and assistants, it includes logs, costs and shutdown criteria. That is what makes support possible: you can see what is happening instead of guessing.

A monthly fee with no visible output becomes a fixed cost nobody can justify. To avoid that, ask for three things:

• A record of what was done. Each month ends with a list of what was fixed, adjusted or improved, and why.
• Numbers from the system itself. Volume processed, failures, alerts and response time, taken from the logs, not from impressions.
• An exit criterion. What happens if the company decides to stop: where the code, data, credentials and documentation live.

The last point is the one most often forgotten. Good support leaves the company less dependent on whoever built the system, not more. In our piece on diagnosis before automation, we wrote about the baseline created at the start of a project. Ongoing support is what keeps that baseline up to date month after month.

If the system is working, why pay for support? Because working today does not guarantee working six months from now. Models get retired, integrations change and the company's process evolves. Support exists so these changes are handled before they become incidents.

Can I just hire a fix when something breaks? Yes. That is what our technical rescue and support service is for, with triage, an agreed fix and evidence of completion. The difference is that ongoing support tries to keep failures from getting that far.

Does support lock the company into the vendor? It should not. Ask for documentation, access to the code and a written exit criterion from the start.

DOUVRAS Labs works on automation and integrations, custom software, AI agents, websites and technical rescue. Every project starts with a diagnostic conversation that defines the bottleneck, the dependencies, the evidence of completion and what stays out. The support format is decided together, after that scoping, based on how much the operation depends on the system.

And in your company, who is replacing the planks on the ship?

Douglas Henrique, DOUVRAS Labs.

Plutarch. Life of Theseus. Ship of Theseus, Wikipedia. wikipedia.org

Lehman, Meir M. Laws of software evolution (1974 onward). Lehman's laws of software evolution, Wikipedia. wikipedia.org

Sculley, D. et al. Hidden Technical Debt in Machine Learning Systems. NeurIPS, 2015. neurips.cc

OpenAI. Deprecations. openai.com

DOUVRAS Labs. Automation and integrations. douvras.com

DOUVRAS Labs. AI agents and assistants. douvras.com

DOUVRAS Labs. Technical rescue and support. douvras.com