Who can change your AI system when the business changes?

It is tempting to judge an AI system at launch. A harder test tends to come later, when something in the business changes: a new product line, a revised policy, a different supplier, or a model update from the provider.

At that point the questions are practical. Who in the company can tell whether the system still works? Who is allowed to change it? Who knows how to keep working if it has to be switched off? Who could move it to another provider?

If the honest answer to each is “only the people who built it”, whether an external supplier or a single specialist, the business has bought a dependency rather than a capability. That can be a reasonable choice. It should be a deliberate one, and the handover is the moment to make it visible.

When the system goes out of date

Consider a hypothetical manufacturer of heating equipment. Installers send technical service requests by email and through a web form, often with photos. An AI assistant reads each request, suggests a probable cause and proposes whether it can be solved remotely or needs a visit from a field technician. A service coordinator confirms or corrects that proposal before anything is scheduled.

The system works well enough at launch. Some months later the company introduces a new product range, with different faults and a different warranty policy. Under the new policy, some faults that used to be handled remotely now need a visit.

Nothing in the system is broken. It is out of date. Whether the business can respond in days or in months depends on decisions taken, or skipped, during the original project.

Make the handover a test

A handover built around a demonstration shows that the system works today. It says little about whether the business can keep it working.

We propose a different acceptance test. Before the project is signed off, the team that will own the system works through a real change. In the example, that means adding the new product range to the routing rules, rerunning a set of reference cases and deciding whether the answers are good enough. The same test includes a short period of work on the manual procedure and a check that the list of provider dependencies is complete.

The test is observable. Either the owner can specify, judge and authorise the change, or the gap becomes visible while the original team is still there to close it.

The owner does not have to be the person who carries out the change. Under a managed service, the provider may implement it. What the business needs is people who can specify the change, evaluate the result and approve it. If they cannot, the handover is not complete, however well the system performed in the demo.

What the test checks

Check. The business owns a set of reference cases: real or realistic requests, each with the answer an experienced coordinator would give. Anyone authorised can rerun them after a change and see what moved. Without them, a change is judged mainly on impressions.

Change. It is clear which parts the business can adjust itself, such as instructions, routing rules and the criteria for proposing a technician visit, which parts need IT, and who approves each kind of change. Changes are recorded, so a new error can be traced back to its cause.

Continue. There is a documented way to work with the system switched off, and coordinators keep practising the judgment the assistant supports. A team that has stopped diagnosing requests itself is likely to struggle to catch the assistant’s mistakes, or to step in when it fails.

Exit. The company knows what depends on which provider: the model, the data connections, the instructions, the reference cases. The cases and the routing rules, written in plain language, belong to the business, in a form that could be moved if it ever needed to.

Build it during the project, not after

In our view these capabilities are easier to build during the project than to add afterwards, because the knowledge they depend on is easiest to capture while the system is being designed: what a good answer looks like, and who decides.

In the project scope they become concrete deliverables: the reference cases and the criteria behind them, a short map of who can change what, a manual procedure, a list of provider dependencies, and time for the people who will maintain the system to learn how. The handover test then shows whether these deliverables work in practice.

A managed service changes who does the work, not who decides

Not every business wants to run AI systems itself. A managed service may cost less, and the provider may keep it current more easily than an internal team could.

We agree that ownership does not mean doing everything in-house. A company can outsource operation and still own the criteria, the evidence and the exit. In that case the handover test checks evaluation and approval rather than execution.

There is also a question of proportion. For a low-stakes internal tool that rarely changes, a light version is enough: a handful of reference cases and a named owner. The effort should grow with the consequences of a wrong answer and with how quickly the business changes.

Platforms provide tools, not decisions

AI platforms can provide logs, version history and evaluation tools, and they are useful. They do not decide which cases define “still working”, who may change a routing rule, or how coordinators will work on the day the system is off. Those are choices about strategy, process design, governance and skills.

For Amigdala, this is part of what responsible AI means in practice: the people who rely on a system should remain able to understand it, correct it and work without it. Designing that ability belongs in the project as much as the model and the integration.

Before signing off an AI project, ask one question and test the answer: when the business changes, who here can change the system or decide on the change, and how will we know it still works?