On this page
Baseline the objections, deploy in watch-only, enforce, then read out to the risk owners.
The proof of concept runs producing calls with nothing permitted to execute.
The readout is structured against the original blocks, not a general assurance.
Challenge
The proof of concept 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 proof of concept 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 proof of concept 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 proof of concept 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 proof of concept 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 proof of concept 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 proof of concept 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 proof of concept rather than configured inside it.
Every action is checked before it happens
Before the proof of concept 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 proof of concept 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 proof of concept was always meant to move. It is not evidence that the number has already moved.
Outcome Derived
This is a 60 to 90 day proof of concept on a single line, cell, category or product family. The figures below are what the proof of concept 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 proof of concept's existing stall date.
- The dollar outcome the proof of concept promised. Reported alongside the objections, so value and control land together.
Highlights
- The proof of concept 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.
