Ask one question. Nobody in the room will answer it.
The question is: if a model in production starts doing something it should not, who has the authority to turn it off? Not who would raise it. Not who would convene a working group. Who can stop it, today, over the objection of the person whose delivery date it belongs to.
Joseph Wallace, who leads data and AI governance at Adobe, put a version of this at the centre of a piece for MIT Sloan Management Review on 30 June 2026. His argument is that most organisations have built the visible apparatus of AI governance, the frameworks and committees and inventories, without building the one thing that makes governance real, which is a person with the authority to say no and the standing to make it stick. He is direct about the failure mode, calling the alternative governance theatre. It is worth noting the piece is an argument from practice rather than a survey, and it carries no statistics.
The Australian regulatory read points the same way from a different angle. APRA's letter to industry on artificial intelligence, dated 30 April 2026, drew on a targeted review of large banks, insurers and superannuation trustees and found that governance had not matured at the pace of adoption. The letter is explicit about wanting ownership and accountability across the whole AI lifecycle, from design through deployment and monitoring to decommissioning, and about human involvement in high risk decisions. Ownership across a lifecycle is not a committee. It is a named person at each stage.
The shift leaders keep missing
For most of the last three years, the AI leadership conversation has been about permission. What are people allowed to use, on what data, for what tasks. That produced policies, approved tool lists and training.
Permission is upstream. It governs what starts. It says nothing about what happens once a system is running and behaving in a way nobody planned for, which is the only moment governance is actually tested.
Stopping is a different kind of authority to approving. Approval is diffuse and low cost. Everyone is comfortable adding a name to a launch approval, because approving is agreeing with the direction of travel. Stopping runs against the direction of travel. It costs someone their date, their number, occasionally their bonus. Which is exactly why an authority that exists on a slide will not be exercised by someone who has to spend their own credibility to use it.
Wallace's structural answer is worth taking seriously: put named owners against every AI system, and give the escalation path a home that does not report to the team shipping the product. The independence is the point. A governance function that reports into delivery will always lose the argument at the moment it matters, because at that moment the argument is with its own management line.
The operating move: a one page stop authority
For each AI system that touches customers, employees, money or a regulatory obligation, write one page. Five parts. It should take under an hour per system, and the difficulty of writing it tells you most of what you need to know.
1. The named person, and a named deputy. A role title is not enough if the role is vacant or the person is on leave. Two names, one primary. If you cannot name them, you have found the gap.
2. The trigger list, written before launch. Three to six specific conditions that mean stop, decided while everyone is calm and nobody is defending anything. Examples: the system produces an output about an identified individual that is materially wrong and was acted on; error rates on a monitored measure exceed a stated threshold for a stated period; a data category appears in the system that was never approved; a regulator or a court asks a question the team cannot answer from the logs. Written triggers convert a judgement call under pressure into a check against a list.
3. The standing that makes it real. State who the stop authority reports to for this purpose, and state that exercising the authority is the job rather than an escalation of last resort. The sentence that matters is the one that says nobody's delivery commitment overrides it. If a leader will not sign that sentence, the authority does not exist and everyone will know.
4. The rollback, rehearsed. What actually happens when the switch is flipped. Does the process fall back to a manual path, and is that path staffed. How long does the fallback hold. Who tells customers. Most stop authorities fail here, not at the decision, because the honest answer is that there is no functioning alternative and everyone knows it, so the decision is never taken.
5. The decision record. What was seen, what was decided, by whom, at what time, and what happened next. This is the artefact that turns a stop from an act of individual courage into a defensible organisational decision.
Then do the thing almost nobody does. Run a drill. Pick a system, invent a trigger, and have the named person actually exercise the authority in a scheduled exercise. You will learn within an hour whether the rollback works, whether the deputy knows they are the deputy, and whether anyone senior treats the exercise as an inconvenience. That reaction is your real finding.
Three ways stop authority fails
When this breaks, it usually breaks in one of three recognisable ways. Each has a different fix, and misdiagnosing which one you have wastes months.
Authority without information. The person with the power to stop cannot see the system well enough to know when to use it. They hold a governance title and receive a monthly summary, while the signals that would justify a stop live in operational dashboards nobody routes to them. The fix is not more authority. It is putting the trigger conditions on a monitored feed that reaches the named person automatically, so the decision does not depend on someone else deciding it is worth escalating.
Information without authority. The people who see the problem first are usually the closest to the system, and they are usually the most junior. They raise it, it is noted, and the deployment continues because raising it was all they could do. This is the most common pattern and the most corrosive, because it teaches capable people that reporting accomplishes nothing. The fix is a documented route from observation to a decision maker with a response time attached.
Authority and information, no fallback. Everyone knows, everyone agrees, and nobody stops it because there is nothing to stop it to. The manual process was retired six months ago, the staff who ran it have moved on, and the honest cost of a stop is that the work does not get done at all. This one is a resourcing decision made long before the incident, and it is usually made without anyone realising they were making it. If retiring a fallback is on a project plan, that is a governance decision, not an efficiency one.
What should the board be told?
If your board oversees AI, the reporting is usually a count: systems deployed, use cases approved, incidents logged. Those are activity measures. They tell a director nothing about whether control exists.
Three lines are worth more than the whole dashboard. How many of our consequential AI systems have a named stop authority with a deputy. When was each last tested with a drill, and what did the drill find. Has anyone exercised the authority this year, and what happened to them afterwards.
The third line is the one that reveals the culture. An organisation where nobody has ever stopped anything is not necessarily well run. It may simply be one where stopping is not survivable.
Where the leader cannot delegate
Three parts of this are yours and stay yours.
The standing. You can delegate the monitoring, the thresholds and the technical rollback. You cannot delegate the political weight behind the authority. That comes from a leader saying, in public, that stopping is supported and that being right about a stop will not be held against anyone. Nobody below you can grant that.
The trigger list. Engineers will propose technical thresholds because those are measurable. The triggers that matter most are usually about harm to a person or a breach of trust, and they require a judgement about what your organisation will not do. That is a values decision expressed as an operating rule.
The consequence of a false alarm. Someone will eventually stop a system unnecessarily. How you respond the first time sets the price of every future stop. If a good faith stop that turned out to be wrong is treated as a mistake, you have just taught the organisation to wait for certainty, and certainty arrives after the harm.
Note the distinction from two adjacent leadership problems. Setting decision rights is about which decisions AI may participate in and at what level of autonomy. Working out who carries it when AI gets something wrong is about accountability after a failure. The stop authority sits between them: it is the pre authorised power to intervene while the failure is still happening.
A worked example
[BUSINESSUNIT] runs an AI assistant that drafts responses to customer complaints. A human reviews before sending, and review has been reliable for months.
Volume rises. Review becomes a scan. A drafted response cites a policy clause that does not exist, and it goes out. [TEAMLEAD] sees it two days later in a follow up complaint.
Without a stop authority, the next four days are a debate. Product says it is a review failure not a model failure. Operations says the review standard was never resourced for this volume. Risk asks for data nobody has. The system keeps running.
With one, the trigger reads: a response is sent that asserts a policy position not present in the source material. [NAMEDOWNER] matches the event to the trigger, switches drafting to the manual template within the hour, records the decision, and the investigation happens with the system paused rather than while it continues to send. The cost is four days of slower responses. The alternative cost is every wrong response sent during the debate, and a regulator later asking why it kept running after you knew.
Note what did the work. Not a smarter model, not a better framework. A sentence written in advance, and a person who knew it was theirs.
Do this Monday
Take your three most consequential AI systems. For each, ask the two questions in a meeting where the answers are said out loud: who can stop this, and do they know that is their job. If the room goes quiet, you have not found a gap in your governance documentation. You have found that the documentation was the governance.
Write the page. Run the drill. Then decide whether the answer you got is one you would be comfortable giving to your board.
Bottom line
Permission governs what starts. Stop authority governs what happens when a running system misbehaves, and it only exists if a named person holds it with the standing, the triggers, the fallback and the record to use it. The document takes under an hour per system. The drill tells you within another hour whether it is real. If nobody can answer who can stop the model, the documentation was the governance.
TheAICommand. Intelligence, At Your Command.
