The Safe Deactivation of an AI System
Ask an AI governance team who can switch a live system off. The answer usually takes a while to arrive, and that delay is the finding. Deactivation is a capability built in advance rather than improvised under pressure. Two instruments on the AIGP curriculum say so, and both are specific.
What the AI Act requires
Regulation 2024/1689 puts the mechanism in the human oversight article. Oversight measures for a high-risk system must let the person overseeing it intervene in the operation. They must also let that person interrupt the system, through a stop button or a similar procedure, allowing it to come to a halt in a safe state.
Read the last five words carefully. A halt is not enough. The state the system lands in has to be safe, which is a design question rather than an operational one.
The deployer’s duty to suspend
Article 26 puts a separate obligation on the deployer. Deployers monitor operation against the instructions for use. Suppose they have reason to consider that using the system in line with those instructions may result in it presenting a risk. Two duties follow without undue delay. They inform the provider or distributor and the relevant market surveillance authority. They suspend the use of that system.
Suspension is therefore a legal duty triggered by a reasonable belief, not a decision to be weighed against commercial cost. The Regulation also defines two terms candidates confuse. A recall aims at returning a system to the provider, or taking it out of service, or disabling use where deployers already hold it. A withdrawal aims at preventing a system in the supply chain from reaching the market at all.
What the NIST framework expects
The AI Risk Management Framework reaches the same place from the governance side, and it does so twice.
Govern asks for processes and procedures covering decommissioning and phasing out AI systems safely. The wording adds a condition: in a manner that does not increase risks or reduce the organisation’s trustworthiness. Deactivation planning therefore sits in the function covering policy and accountability. That tells you when the work belongs, which is before deployment.
Manage asks for mechanisms in place and applied, with responsibilities assigned and understood. Their purpose is to supersede, disengage or deactivate systems showing performance or outcomes inconsistent with intended use. Three verbs, one point. Somebody has to own the action and know they own it.
Why deactivation ownership decides the answer
A capability nobody has exercised is a claim rather than a control. NIST asks for mechanisms applied rather than merely available. The AI Act asks for oversight that can interrupt in practice.
A working deactivation arrangement holds four things. Triggers defined in advance. A fallback somebody has tested. Named authority to invoke it. A decommissioning procedure for systems that never come back. Our piece on the four NIST AI RMF functions covers how those two functions relate.
Localisation, the quieter form of deactivation
Deactivation across the board is one response and often the wrong one. A system may be lawful in one market and prohibited in another. It may also be accurate for one population and unreliable for a second.
The framework treats localisation as part of the same policy family as deactivation. An organisation should be able to disable one feature in one jurisdiction without stopping the service everywhere. Building that capability late is expensive, which is why it belongs in the deployment decision. Our piece on choosing between AI deployment options covers the architecture choices that make it easy or impossible.
Deactivation in the AIGP exam
The Body of Knowledge is the IAPP’s published outline of what each certification exam tests. Governing deployment and use is Domain IV. The policy and controls to deactivate or localise a system sit at the end of it.
Three distinctions earn marks. Keep suspension apart from recall and withdrawal, because the Regulation defines all three differently. Keep the deployer’s duties apart from the provider’s, since the duty to suspend and notify belongs to the deployer. Then keep deactivation capability apart from the incident response that follows it. Triggers, fallback and decommissioning are the capability. Notifying affected parties belongs to the response.
Work a timed set of questions on Domain IV before you decide whether the gap is knowledge or reading. The AIGP practice exam at €25 is enough to tell you which.
