An automation is not a piece of furniture: it is an organism plugged into systems that move without warning you. A vendor changes a response format. A model is updated and becomes more cautious, therefore less decisive. A salesperson changes a discount rule and nobody thinks to mention it. Three months later the process still works, but less well, and nobody knows since when.

The five questions, one by one

  • Who steps in when an interface changes? A named person, an announced response time, and a way to reach them.
  • Who monitors, and what? Useful monitoring does not just check that the service responds: it checks that the result is still good.
  • Who fixes errors, and within what time? A blocking incident and a slow drift do not get the same treatment.
  • What happens if the model changes behaviour? You need a pinned version, a reference set of examples, and a comparison before switching.
  • What does all this cost per year? A figure announced before signing, not a quote discovered at the first incident.

Monitor the result, not just the service

Classic monitoring answers the question "is it running". That is not enough: an automation can run perfectly and produce steadily worse results. So we also monitor the substance: the share of proposals corrected by a human, the share of cases marked uncertain, the average cost per run, and end to end delays.

When one of those indicators drifts, there is a signal before the incident. That is the whole difference between fixing an automation and discovering it broken through an unhappy customer.

An automation almost never falls over at once. It degrades, and silence passes for stability.

Model changes

This is the risk specific to AI projects, and it is poorly understood. An updated model is not the same product: the style changes, the caution changes, the output format can change. Three precautions are enough: never let a process point at a floating version, keep a set of examples with the expected answers, and replay that set before any switch. If the provider does not have those reference examples, they cannot know what an update changed for you.

Taking back control

This is the point that protects the company in the long run. It rests on four conditions: the code and the instructions are yours, the accounts of the services used are yours, documentation exists and is readable by someone else, and a handover is written into the contract. A provider who accepts those four conditions is not afraid of being replaced, which is generally a good sign about the rest.

We cover this in the article on ownership, and our piloting offer on the AI Orchestrator page states precisely who does what once the project is delivered.

Our position

We do not sell a delivery followed by silence. Monitoring, correction and adaptation are part of the service, with an announced cost, because that is the only honest way to present an automation: it is not a purchase, it is an operation.