On this page
Baseline the objections, deploy in watch-only, enforce, then read out to the risk owners.
The pilot runs producing calls with nothing permitted to execute.
The readout is structured against the original blocks, not a general assurance.
Challenge
The pilot works. It is stopped anyway, held before the line by risk, audit and security objections that the tool's vendor cannot answer because the answers are architectural rather than functional.
- The blocker is not accuracy. The model performs. The deployment cannot be approved.
- The stall is the pattern, not your organisation's failure. McKinsey's 2025 State of AI survey found most organisations still have AI in experimentation or pilot rather than in production. What sits underneath that in manufacturing is a review that cannot verify a call it cannot see.
- Objections are rarely written down as a list. Which is why they are never closed one at a time.
What the review asked, and what answers it
The objection
What closes it
What can it reach?
What can it reach?
A description of intended behaviour
Egress allowlisted beneath the workload
Where does our data go?
Where does our data go?
A contractual assurance
Nowhere. It runs inside the plant boundary.
What if it is wrong?
What if it is wrong?
It will be corrected afterwards
The check runs before the action, not after
Who is accountable?
Who is accountable?
Unstated
A named person, on every consequential call
Solution
The pilot did not stall on performance. It stalled on questions nobody had written down. Each one is enumerated, then closed, before anything is deployed.
- Objections enumerated first. Each risk, audit and security block is written down explicitly before anything is deployed.
- The pilot runs inside your own environment. Wrapped so data does not leave, which removes the objection rather than arguing it.
- Watch-only before it acts. The pilot produces its calls with nothing permitted to execute, so the evidence precedes the permission.
- Sign-off, pre-action checks, logging and back-out switched on together. The controls the review asked for, in place before the pilot goes live.
The Four Things the Review Was Actually Asking For
The objections are rarely about the model. They are about what happens the first time it is wrong on a live system, and nobody had written that question down in a form anyone could answer.
Nobody approves a bad action
Which decisions the pilot may take alone, which need a person first, and who is pulled in when something looks unusual. Set before deployment, per workflow, and enforced beneath the pilot rather than configured inside it.
Every action is checked before it happens
Before the pilot writes to a real system, the action is checked against live plant state and the ones that fail are stopped. This is the primary control. A bad move is caught before it commits, not cleaned up after it has.
Everything is logged in language an auditor accepts
Every action, and every check it passed or failed, in a record that can be handed to an auditor or a customer. When the committee says prove it, the proof already exists rather than being commissioned.
A committed change can be backed out
If a system-side change is written and turns out to be wrong, it can be reversed and flagged. This is a backstop behind the pre-action check, not a claim that anything at all can be undone.
What Cannot Be Undone, Said Plainly
A scrapped part cannot be un-scrapped and a shipped order cannot be un-shipped. Any vendor promising otherwise is describing a system-side reversal and calling it something larger.
- The reversal is of the record, not the world. An updated MES record, a released purchase order or a created work order can be backed out and flagged. The physical consequence of having acted on it cannot.
- Which is why the check comes first. The pre-action check against live state is the control that matters. Back-out is what remains when the check passed and the world had already moved on.
- The distinction belongs in the readout. A risk committee told that everything is reversible will find the exception itself, and the pilot freezes a second time. Saying it up front is cheaper than being caught saying otherwise.
- Nothing here claims a delivered result. The engagement is structured to close objections and measure the number the pilot was always meant to move. It is not evidence that the number has already moved.
Outcome Derived
This is a 60 to 90 day pilot on a single line, cell, category or product family. The figures below are what the pilot measures against a baseline captured in its first two weeks. They are targets and instrumentation, not results already delivered.
- Each objection closed and shown closed. The readout goes to the risk owners, matching every original block to the control that answers it.
- Time from frozen to live. Measured from the pilot's existing stall date.
- The dollar outcome the pilot promised. Reported alongside the objections, so value and control land together.
Highlights
- The pilot keeps its own logic and models. Nothing is rebuilt. The controls are added at the point where it would act on a system of record.
- Each risk, audit and security objection is written down as a list before anything is deployed, which is the only reason they can be closed one at a time.
- Running inside the manufacturer's own environment removes the residency objection rather than arguing it.
- Watch-only precedes enforcement, so the evidence the committee asked for exists before the permission is requested.
- A committed system-side change can be reversed and flagged. Physical work cannot, which is why the pre-action check is the real control.
Frequently asked questions
Do we have to rebuild the AI we already piloted?
No. The pilot keeps its logic and its models. The controls are added underneath it, at the exact point where it would act on a system of record: sign-off rules, pre-action checks, logging and back-out. Nothing is re-implemented and the vendor relationship does not change.
Why is our pilot stuck if the model works?
Because working in a demo and being safe to let act on live operations are two different bars, and holding the second one is the security team's job. They cannot yet prove the pilot will not commit a bad action to a real system, so the answer is no. The block is architectural, not a model problem.
Can a mistake on the line be undone?
No, and it is worth being blunt about it. A scrapped part or a shipped order cannot be reversed. A system-side change such as an MES record, a released purchase order or a created work order can be backed out and flagged. The real protection is the check that stops a bad action before it commits.
What does the readout give the risk owners?
Each original objection matched to the control that answers it, alongside the dollar outcome the pilot was meant to deliver. Value and control land in the same session, which is what stops a second review cycle from opening after the first one closes.
