Who Can Say No, and Survive It?
~11 min read · By Jeroen Janssen · July 2026
A racer commits to a corner before the corner arrives. Somewhere on the approach there is a last instant at which braking still changes the outcome. Past it, the line is set, the physics has taken over, and the only remaining question is how the exit reads. Governance has the same geometry, and mostly ignores it. We ask who is authorised to say no. We rarely ask whether the no can still reach the machine before the machine has finished acting.
In MIT Sloan Management Review, Joseph Wallace, who runs AI and data governance at Adobe, asks the question that has become the sharpest in enterprise AI. Every Fortune 500 leader will tell you they govern their AI. Now ask them who is authorised to shut a model down when it starts causing harm, and the room goes quiet. His closing line is the whole argument compressed: who can say “no” and have the authority to mean it?
He is right, and the diagnosis is precise. But the question is the opening move, not the finish. It tests authority. It does not test whether that authority can reach the system in time, whether the organisation can survive its exercise, or whether there is anywhere else to go once it has been used. There are three walls behind the stop button, and Wallace stops at the first.
The Governor, Not the Alarm
Start where Wallace is strongest, because he earns it. A governance industry has grown up around AI that sells visibility and calls it control. Model registries catalogue what exists. Classification schemes label the data. Dashboards watch behaviour, risk councils review deployments, compliance officers write policy and present slides. The infrastructure has proliferated. What is missing, he says, is the governor: the person who can walk into a meeting and say we are shutting this down, and not be overruled by the end of the afternoon.
His fire-alarm image is the right one. A wired house with a fresh battery in every detector still burns down if nobody picks up the hose. Registries and lineage tools are alarms. They tell you the building is alight. They do not put anything out. And the reason the hose stays on the wall is structural, not moral: the person empowered to challenge a deployment usually reports, directly or indirectly, into the organisation rewarded for shipping it. Adobe’s answer was to give governance an independent reporting line into trust and security, so the person who can say no does not answer to the person who profits from yes. That design choice is real, and most organisations have not made it.
All of this holds. It is necessary. It is also incomplete in a way that matters more as systems get faster and more embedded.
Authority Is a String Until It Reaches the Machine
Wallace writes that the hard part is never the technology. For deployment approval, that is true. The obstacle really is organisational nerve. For runtime and agentic AI the claim inverts: there, the technology is part of the authority structure. A decision right with no enforcement point is not a weaker version of authority; it is a different thing wearing its clothes.
A mandate that says the chief risk officer may halt a deployment is, until something enforces it, a sentence. It becomes an act only at the moment it reaches a point in the running system that can actually change what the system does, and only if it arrives before the action it is trying to stop has become irreversible. Authority that arrives after execution is not authority over the system. It is authority over the incident report.
This is the racing line again. In a high-speed automated process, a human who is merely “in the loop” can be cosmetically reassuring while the loop runs faster than any human can act. The stop button exists; the braking point has already passed. The governance question is therefore not only who may intervene, but where the intervention enters the technical path, and whether the latency of deciding is shorter than the window of irreversibility.
It gets harder in agentic systems, which is where much of this is heading. There the harm frequently lives not in the model but in the path. Reading a file is permitted. Sending an email is permitted. The composition of the two is the data breach. Nothing in that sequence is a misbehaving model to be shut down; each step is a permitted action, and the system is behaving exactly as designed. “Stop the model” is the wrong instrument: too late, too broad, sometimes simply absurd. The unit that needs interrupting is an action, a tool permission, a workflow, a transaction. And “stop” is only one of the moves. A real control surface can allow, observe, demand more evidence, require human approval, constrain the available tools, deny a single action, revoke a credential, quarantine a session, degrade to a safer mode, roll back, or suspend. A kill switch is the emergency brake. It is not the steering.
A No You Cannot Afford Is Not a No
Suppose the authority is real and the intervention lands in time. There is still a second wall. The governor can say no; can the organisation survive the no?
Formal stop authority becomes hollow the moment exercising it would disable an essential process, strand data in a proprietary format, break a contract, or leave no way to keep operating. The mandate then exists on paper and is unusable in practice, because stopping the service would cause more immediate harm than letting it run. This is the uncomfortable mechanics of dependency, and it produces a paradox worth stating plainly: the more valuable and deeply embedded an AI capability becomes, the harder it gets to exercise the authority to stop or replace it. Every integration raises the switching cost. Workflows become model-specific, applications adopt proprietary interfaces, data accumulates in one vendor’s shape, staff skills concentrate on one platform, procurement commits to multi-year terms. Eventually the organisation holds impeccable stop authority and no usable exit.
So the governance sequence has to run further than authority. Can essential operations continue after intervention: is there a fallback, a manual mode, a degraded path that has actually been tested? And can the dependency itself be substituted: another model, another provider, portable data, open interfaces, a credible exit right? Sovereignty, in the sense that matters here, is not the right to refuse. It is the capacity to refuse without being incapacitated.
Sovereignty Is Not a Data Centre’s Postcode
This is where a narrow oversight question opens onto a much larger one, and where two 2026 sources sharpen Wallace considerably. The EU AI Office’s frontier-AI expert findings argue that Europe must strengthen its ability to access, select, control and benefit from frontier models, and name the binding constraints: compute, the energy to run it, growth capital, legal certainty, talent. Stanford HAI’s AI Sovereignty Paradox distributes the same concern across five layers (infrastructure, data, models, applications, talent) and defines sovereignty as the capacity to act deliberately and choose independently, not as ownership or national origin.
That distinction is the useful part. A system can be hosted locally and still depend on foreign accelerators, overseas fabrication, a foreign control plane, an externally built foundation model, vendor-controlled updates. A foreign technology can, conversely, offer genuine operational control through enforceable jurisdiction, customer-managed administration, portable data and credible exit. Vendor nationality is one input, not the conclusion. A European label can conceal deep lock-in; a non-European provider can, in cases, offer more real optionality. The honest definition is retained freedom of action under conditions of interdependence: not autarky, which Stanford treats as practically unattainable, but calibrated dependence and preserved choice.
Framed as buy, build or lease, the strategy that follows is selective sovereignty: build the control points that are critical to legitimacy, continuity or differentiation; lease scale where jurisdiction and operational control matter; buy what is substitutable and not differentiating; and preserve exit and fallback across all three. Which lets us name three failure modes precisely. Governance theatre: a person is named but cannot enforce a decision. Sovereignty theatre: a system is labelled sovereign while its critical dependencies remain externally controlled. And the one almost nobody tests, optionality theatre: the contract mentions portability and multi-cloud, but the migration and the fallback have never once been run.
Declared, Implemented, Proven
Put the walls together and authority itself becomes an object of evidence rather than a line in a policy. A document stating that the CRO can halt a deployment proves nothing on its own. It does not prove the CRO knows this, that the engineers know it, that production supports it, that the credentials are provisioned, that the escalation route works at 2 a.m., that a safe state is defined, that the mechanism was ever tested, or that commercial leadership cannot quietly route around it.
So the test is not a single control but a chain, and each link should be assessed in three states. Declared: a policy, architecture or contract says it exists. Implemented: the organisational and technical mechanism is actually present. Proven: it has been exercised under realistic conditions. The chain has six links:
- Authority. Who may constrain, override or stop? Evidence: delegated mandate, decision rights, escalation route.
- Enforceability. Can the decision change system behaviour in time? Evidence: a runtime policy point, credentials, a safe-state mechanism.
- Continuity. Can essential operations continue after intervention? Evidence: fallback, manual procedure, degraded mode, a recovery test.
- Substitutability. Can the component or provider be replaced? Evidence: open interfaces, data portability, an alternative model or vendor.
- Capability. Can the organisation actually operate and govern the alternative? Evidence: skills, compute, documentation, funding.
- Assurance. Has the whole mechanism been demonstrated? Evidence: exercises, logs, test results, incidents and their remediation.
That three-state distinction is the thing that stops the new sovereignty language from decaying into the next generation of governance paperwork. Most programmes today can produce a wall of declared. Very few can produce proven. The gap between the two is the actual state of their governance.
The Corrected Question
Wallace’s question is the right place to start because anyone can understand it: who can say no and mean it. The correction is not to replace it but to carry it three walls further. A meaningful no needs authority, reach, and somewhere to land. Or, as four tests a board can actually put to a system:
- Who can intervene?
- Can their decision reach the system before the action becomes irreversible?
- Can the organisation continue, on acceptable terms, after they act?
- Can it prove that all three are true?
Call it governance agency, or effective freedom of action: the property that an institution retains enough authority, capability and optionality to change course when continuing is no longer defensible. Governance is not the presence of a governor. Sovereignty is not the location of a data centre. Both reduce to the same underlying question, asked deliberately, before the decisions become irreversible rather than after. In the terms this framework has used from the start (who may decide, who must prove, who can block), the sovereignty sources add the one that was missing: what preserves the freedom to choose another path?
And that inventory does not compile itself. It is an audit, run deliverable by deliverable and workflow by workflow: which outputs in this organisation become consequential actions, who is authorised to interrupt each one, where that authority actually enters the machine, what happens to the business if it is used, and whether any of it has ever been tested. Wallace names the missing governor. The harder, less glamorous work is proving the governor can reach the machine in time, and that the organisation is built to survive the moment it does.
Sources
- J. Wallace, “The Real Question to Ask About AI Governance,” MIT Sloan Management Review, 30 June 2026. The article’s claims about “literally every Fortune 500 company” and about most leaders being unable to name a stop authority are rhetorical generalisations offered without survey data; they are used here as characterisation of a pattern, not as measured findings.
- Stanford HAI, “The AI Sovereignty Paradox: Should Countries Buy, Build, or Lease to Maintain Strategic Control of Their AI?” 2026. hai.stanford.edu. A selective review drawing substantially on public vendor claims; its authors disclose financial support from Nvidia, Google, Microsoft and AWS. The framing is used here as analysis, not as independent product verification; vendor-specific claims should be validated during procurement.
- Stanford HAI, “Policy and Governance,” The 2026 AI Index Report, 2026. hai.stanford.edu. Frames AI sovereignty as expanded agency over domestic AI capability against an unevenly distributed infrastructure base, and treats the objective as shaping and negotiating dependencies rather than eliminating them, the register used here for “calibrated interdependence.” Its release-count and public-compute figures are proxies for capability, not direct measures of frontier quality.
- European Commission, AI Office, “AI Office publishes frontier AI expert findings on EU competitiveness, sovereignty and security,” 2026. digital-strategy.ec.europa.eu. The publication summarises input from more than 100 experts and states explicitly that it is neither exhaustive nor the official position of the European Commission.
- Regulation (EU) 2024/1689 (AI Act), Articles 14 and 26. For high-risk systems, Article 14 requires human oversight arrangements under which assigned persons can disregard, override or reverse output, intervene, or interrupt the system through a stop button or equivalent safe-state procedure; Article 26 requires deployers to assign oversight to competent, trained and authorised persons. These duties apply to high-risk systems in staged application, not to every model in an enterprise, and the Act prescribes no universal role called an “AI governor.” eur-lex.europa.eu
