Your AI Deactivation Plan

Every AI governance programme knows how to start a system. Far fewer can stop one. An AI deactivation plan answers a plain question: who pulls this system, on what signal, and what happens to the work it was doing. The AIGP Body of Knowledge, the blueprint the IAPP publishes to set out what the exam covers, puts that control in Domain IV with the rest of deployment and use.

Two triggers for AI deactivation

The blueprint gives two reasons to deactivate an AI system: regulatory requirements and performance issues. A plan that anticipates only one will fail on the other, usually at speed.

The regulatory trigger

The EU AI Act writes deactivation into law rather than leaving it to good practice. Article 20 requires a provider of a high-risk AI system, where it considers that system is not in conformity, to take the necessary corrective actions immediately. The article then lists them: bring the system into conformity, withdraw it, disable it, or recall it. Disabling sits on the same shelf as fixing, not below it.

Deployers have their own version. Article 26(5) says that where a deployer has reason to consider that using the system as instructed may result in a risk within the meaning of Article 79(1), it must inform the provider or distributor and the market surveillance authority without undue delay, and suspend the use of that system. Suspension sits in the same sentence as the notification.

The performance trigger

The second trigger arrives quietly. A model drifts as the world it was trained on moves. A pipeline changes shape upstream and nobody tells the governance team. A supplier ships an update that scores better on their benchmark and worse on your use case. None of that announces itself as an incident, which is why the plan must name the measurement that counts as a stop signal before anyone is under pressure.

What a deactivation plan must contain

A usable plan is short and specific. It fails when written as a principle instead of an instruction. Six things belong in it:

• Authority: the named role that can order the stop, and the deputy for when that person is unreachable
• Threshold: the metric, the value and the observation window that trigger the decision, so the call does not rest on nerve
• Scope: whether the stop covers the whole system, one function, one market or one customer segment
• Fallback: what carries the work while the system is down, whether the previous model version, a manual process or an honest refusal to serve
• Communication: who tells affected users, the provider and, where the AI Act applies, the market surveillance authority
• Record: what gets written down, and where it is kept

The record deserves more attention than it gets. Article 26(6) requires deployers of high-risk systems to keep the automatically generated logs under their control for a period appropriate to the intended purpose, and for at least six months. Those logs are the evidence of what the system did before you stopped it. A deactivation that destroys the reason for the deactivation is a poor result.

Localisation, the option people forget

Deactivation is binary and expensive. Localisation is the graded alternative, and the blueprint pairs the two deliberately. You can restrict by geography when one regulator objects, by function when a single feature produces the harm, by user group when the failure is concentrated, or by data set when the problem arrived with the training data.

A rollback to the previous model version is localisation in practice. So is switching off automated action and leaving the system in an advisory mode where a person still decides. Both keep the service alive while removing the part doing the damage. A scenario with a narrow failure and a dependent business is testing whether you reach for the graded response.

When the model belongs to somebody else

You cannot deactivate a model you do not run. Where the system is a third-party service reached through an interface, your only control is to stop calling it, and that control must exist in the contract before you need it.

Ask what the agreement says about your right to suspend, about notice of model changes, and about your data on exit. If the honest answer is that you would keep using the system while lawyers talked, you do not have a deactivation plan. You have an intention. That is why this work belongs at the vendor stage, long before the incident.

Why the exam tests AI deactivation

Domain IV rewards candidates who can tell a deployment decision from a design decision, and AI deactivation is the clearest case of the former. It is an operational control with a named owner, a threshold and a paper trail.

Questions here tend to offer one option that repairs the model, one that documents the problem, one that escalates it and one that stops the system. Read the trigger in the stem and you will know which is being marked. A regulatory trigger points at suspension and notification. A performance trigger points at the threshold you set in advance.

Two neighbouring pieces finish the picture: governing AI downstream harms covers uses nobody planned, and what AI model testing proves covers the evidence gathered before release. Work through the AIGP material at 22academy.com/study, then write a deactivation plan for a system you already run.