Who can switch off your AI, and how long would it take?

The standard framing of AI governance ownership is a question of mandate. Which function holds it: technology, risk, compliance, security, or the executive. Survey data consistently shows the responsibility distributed across all of them, with no single function holding a majority.

That framing is accurate and almost useless, because nobody can act on it. There is a more concrete version of the same question, and the answers to it are worse.

The operational question

If a model in production begins producing output the organisation cannot defend, who has the authority to switch it off, and how long does it take?

Research by ISACA found that 56 per cent of professionals do not know how long it would take to halt an AI system during a security incident, and 39 per cent do not know whether a documented shutdown process exists at all (ISACA, 2026).

This reframes ownership from a governance chart problem into an operational one with a testable answer. It also exposes the specific failure mode. Where authority is distributed across five functions, the position in a live incident is not shared ownership. Each party reasonably believes another holds the authority, the system continues running while they establish who does, and the delay is the damage.

Why this is a continuity problem

A kill switch is a recovery control, and it should be treated like one.

Every other AI control an organisation builds, from monitoring to output review to escalation thresholds, assumes that the ability to stop the system exists and can be exercised promptly. If it cannot, those controls detect problems they cannot terminate. The control environment has a foundation nobody has tested.

The discipline that already exists for this is continuity testing. An organisation that would never accept an untested failover for a payments system frequently accepts an untested shutdown path for a model making customer-facing decisions, because the model arrived through a different governance route.

The strongest objection

Switching off a production AI system is rarely a binary act, and framing it as a switch misrepresents the problem. Many systems degrade gracefully rather than stopping, some are embedded in vendor products with no customer-accessible control, and halting a model that has become load-bearing may cause more harm than the output being objected to.

There is a second objection about incentives. Making shutdown authority explicit concentrates a decision that carries commercial consequences, and the named holder may be reluctant to exercise it. Naming an owner does not guarantee they will act.

The answer to it

The first objection strengthens the case rather than weakening it. If the response is not binary, then the available options, their consequences and who authorises each need to be worked out in advance, because they certainly will not be worked out during an incident. Where the control sits with a vendor, that is a third-party dependency and should appear in the register as one, since the organisation has outsourced a recovery control without recording it.

The reluctance objection is true of every significant decision and is not specific to AI. It is an argument for placing the authority at an appropriate level and for rehearsing the decision, not for leaving it unassigned. An owner who hesitates is still a considerable improvement on five parties who each assume someone else is responsible.

The test to apply

Do not run a policy review. Pick one AI system currently in production, ask three people in different functions who has the authority to switch it off, and measure how long it takes to obtain a consistent answer.

That elapsed time is your real recovery objective for the system, and it is usually the first honest number an organisation obtains about its AI governance. If the three answers do not agree, the authority is not distributed. It is absent.

References

ISACA (2026) AI governance and security survey. Schaumburg, IL: ISACA.