The Shift Report · Issue 8 · 13 July 2026
How to keep control when AI quietly changes the way your operation runs
Once software starts shaping operational decisions, “the supplier updated it” stops being a full explanation. Keep every AI-supported tool under the same control you’d apply to any other change: know what it’s for, what data it’s allowed to use, who checks its answers, and what should make someone stop trusting it.
It’s Monday morning and the planning tool is giving a different answer from the one it gave on Friday.
Nobody changed the settings. Nobody approved a new process. The supplier pushed an update over the weekend.
The planner notices because the recommendation looks wrong. Not obviously ridiculous. Just wrong enough for someone who knows the operation to question it. And the more useful question is what would have happened if it had looked plausible.
We’re good at managing change when somebody moves a filling line, swaps a forklift or alters a warehouse layout. There’s a risk assessment, some training, a revised procedure. Software rarely gets the same treatment. It gets updated, integrated, improved. The screen looks much the same, so we assume the process underneath it is much the same too.
AI makes that assumption dangerous. A conventional system follows rules someone wrote. An AI-supported system interprets information, ranks options and can produce different answers as the model, the instructions, the data or the connections around it change. The behaviour moves even when nothing you can see has moved.
That doesn’t mean every software update needs a committee. It means that once software starts shaping operational decisions, “the supplier updated it” stops being a full explanation. You still have to be able to say what the tool is for, what it’s allowed to use, who checks its answers, and what should make someone stop trusting it.
Issue #7 was about finding a job worth handing to AI. This one is about the bit that comes next: keeping control of the job once AI is inside it.
Three things worth knowing
1. Getting one AI pilot to work isn’t the same as controlling it across five sites.
Deloitte’s AI in Manufacturing 2026 study (30 June) surveyed more than 140 manufacturers. 84% said AI was already producing measurable value. Only about one in five use cases had been scaled consistently across sites or the wider business.
My take: that gap is the whole story. A pilot has a motivated team, a clear problem and plenty of attention. Scale brings different equipment, weaker data, local workarounds and supervisors who never saw the original test. The technology is the easy part to copy. What surrounds it, the data it needs and the checks that catch its mistakes, is the hard part. Before you roll an AI workflow from one site to the next, treat it like a process transfer: what has to stay the same for it to work, what information it relies on, who verifies the result, and which local exception could make its answer unsafe. A tool working well at Site A proves it worked at Site A. It doesn’t yet prove you have a standard.
2. Your supplier’s strategy can become your operational problem.
Synopsys is walking away from two tools that help run the world’s chip fabs, its Equipment Engineering System (EES) and Fault Detection and Classification (FDC), which sources describe as the nervous system of a fabrication plant: they watch equipment in real time and flag faults before they turn into costly defects. It has told more than 10 chip makers, Samsung and SK Hynix among them, the products are end of life. Maintenance continues, new versions stop. The engineers are being moved to higher-margin AI design, and some of those customers were already building their own tools in-house.
My take: the semiconductor detail is specialised, the lesson isn’t. Every operation runs on unglamorous systems that quietly stop small problems becoming expensive ones: inspection databases, alarm tools, maintenance records, training systems. A supplier can drop one of them because a different product offers better growth. That’s a fair commercial call for them. You still have to run the site on Monday. When an AI or software tool becomes part of a critical workflow, put it on the resilience map: who owns the data, can you export it, how will you be told about big changes, what support is guaranteed, and what happens if the product is withdrawn or the supplier is bought. The least exciting software in the building is often doing some of the most important work.
3. The system can change even when the physical process looks identical.
Mistral has launched Robostral Navigate, its first robotics model, aimed at factories, warehouses and logistics. It moves a robot through a space from a single plain-language instruction using one ordinary camera, no lidar or depth sensors, and runs on wheeled, legged or flying machines from different makers. For now it handles navigation, not picking things up.
My take: this matters even if you never buy a robot. More and more operational behaviour is moving into software, and a future update could change how a machine reads an obstruction, picks a route or reacts to something it hasn’t seen before, while the warehouse and the machine look exactly the same. Management of change can’t stop at the metal. When software can drive a physical action, changes to the model, the sensors, the instructions and the connections belong inside your operational-control process. You need to know what changed, what was tested, and whether the procedures, training and stop conditions still hold. “It’s the same robot” tells you very little if the brain inside it is different.
One thing to try this fortnight
Pick one AI-supported tool already in use somewhere in your business. It might be an official system. It might just be a planner or engineer using Copilot or ChatGPT to prepare work.
Write a one-page AI change note for it. Seven questions:
- What job is the tool helping with?
- What information is it allowed to use?
- What must a person verify before acting on it?
- Who owns the workflow?
- How will users be told if the tool changes?
- What should make them stop using it?
- What’s the fallback if it’s unavailable or unreliable?
You don’t need an AI governance department to answer those. You need what good operations has always needed: a clear task, a named owner, defined checks and a usable recovery plan. If you can’t answer them for a tool that’s already shaping decisions, that’s the finding.
Before I sign off
We spent years teaching operations teams not to make uncontrolled changes to equipment, materials and processes. It’s worth holding that same line when the change arrives through a browser.
The more AI sits inside a workflow, the more it matters to keep the approved task, the judgement points and the human checks visible, so the technology can’t quietly rewrite the job without anyone deciding it should.
SOPwise turns a Standard Operating Procedure into a training package: task-based steps, critical mistakes, and scenario questions. £35 per SOP, no subscription. Built for UK manufacturing and chemical distribution.