The start of an AI system’s life gets a risk assessment, an approval and a named owner. The end of its life can look like an IT task. A contract lapses, a replacement goes live or a team drops a pilot, and someone switches the old system off.
Switching off is the visible part. Which records must be kept, and for how long? Which other systems still use the old one’s outputs? And what about decisions the system already shaped? They may sit in files and keep influencing outcomes after it is gone.
NIST’s AI Risk Management Framework treats AI decommissioning as a governance outcome in its own right. For high-risk systems, the EU AI Act sets duties for bringing a system into conformity, withdrawing, disabling or recalling it, or suspending its use, and record-keeping periods with their own clocks.
Note: statements attributed to a named source come from that source. Everything else, including passages marked “Interpretation,” is the author’s interpretation. The examples in this article are illustrative and do not describe any real organization or system, except the published research case named as such.
Two ways an AI system stops
An AI system can stop in a planned way or an urgent one. A planned retirement follows a business choice, such as a replacement, a lapsed need or a cost review. An urgent shutdown follows a problem, such as a system causing harm or working outside its approved use.
The NIST AI Risk Management Framework (AI RMF 1.0) addresses both. GOVERN 1.7 reads: “Processes and procedures are in place for decommissioning and phasing out AI systems safely and in a manner that does not increase risks or decrease the organization’s trustworthiness.” MANAGE 2.4 reads: “Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.”
Interpretation: the two outcomes call for different preparation. A planned retirement needs a process that can run over weeks. An urgent shutdown needs a working mechanism and a named person, ready before anything goes wrong. In both, NIST describes something set up in advance, not improvised on the day.
What NIST’s Playbook says a retirement policy should cover
The framework points to an online companion resource, the NIST AI RMF Playbook, which offers suggested actions. Like the framework, it is voluntary. Its entry for GOVERN 1.7 explains the concern: “Irregular or indiscriminate termination or deletion of models or AI systems may be inappropriate and increase organizational risk.” It adds that “AI systems may be subject to regulatory requirements or implicated in future security or legal investigations.”
The Playbook suggests that decommissioning policies typically address:
- user and community concerns, and reputational risks
- business continuity and financial risks
- up and downstream system dependencies
- regulatory requirements, such as data retention
- potential future legal, regulatory, security or forensic investigations
- migration to the replacement system, if appropriate
It also suggests policies on where and for how long decommissioned systems, models and related artifacts are stored, and on ancillary data or artifacts that must be preserved to understand or run the decommissioned system. The Playbook’s examples of those include “predictions, explanations, intermediate input feature representations.”
Interpretation: the list shows why deletion is a risky default. A system deleted with its server cannot help explain a decision it made last year. A team that skips the dependency map may find out what relied on the system only when something else breaks.
Removing a system does not remove its effects
Research on algorithmic harm makes a related point. In a paper accepted to the ACM FAccT 2022 conference, Upol Ehsan, Ranjit Singh, Jacob Metcalf and Mark O. Riedl introduced the notion of the “algorithmic imprint.” They use it to illustrate how “merely removing an algorithm does not necessarily undo or mitigate its consequences.”
The authors studied the 2020 algorithmic grading of GCE A Level exams, with a case study set in Bangladesh. According to the paper, the algorithmic standardization was removed following global protests, and the authors show “how the removal failed to undo the algorithmic imprint” on the sociotechnical infrastructures that shape the lives of students, teachers and parents.
Interpretation: inside an organization, the imprint can look ordinary. Here is an illustrative case. An AI tool assigns priority scores to maintenance requests, and each score is stored with its request. The organization retires the tool and replaces it. The old scores stay in the records. Staff may still sort by them, reports may still count them, and the new system may be tested on data that contains them. None of that stops when the old tool is switched off.
What the EU AI Act says about taking a high-risk system out of use
Several EU AI Act provisions on high-risk AI systems are relevant when a system is taken out of use. They apply to different roles.
For providers, Article 20(1) covers corrective action. Providers that consider, or have reason to consider, that a high-risk AI system they placed on the market or put into service is not in conformity with the Regulation “shall immediately take the necessary corrective actions to bring that system into conformity, to withdraw it, to disable it, or to recall it, as appropriate.” They must also inform “the distributors of the high-risk AI system concerned and, where applicable, the deployers, the authorised representative and importers.” Article 3(16) defines a recall as “any measure aiming to achieve the return to the provider or taking out of service or disabling the use of an AI system made available to deployers.”
For deployers, Article 26(5) covers suspension. Where deployers have reason to consider that using a high-risk AI system in accordance with its instructions may result in it presenting a risk within the meaning of Article 79(1), “they shall, without undue delay, inform the provider or distributor and the relevant market surveillance authority, and shall suspend the use of that system.”
Records follow their own timelines. Under Article 18(1), the provider keeps the technical documentation and other listed documents at the disposal of national competent authorities “for a period ending 10 years after the high-risk AI system has been placed on the market or put into service.” That period is counted from placing on the market or putting into service, not from the day the system is switched off. Under Article 19(1), providers keep the automatically generated logs under their control for a period appropriate to the intended purpose, of at least six months. Article 26(6) sets the same minimum for deployers, for logs under their control. Both log provisions apply unless applicable Union or national law provides otherwise, in particular Union law on the protection of personal data.
The roles differ. Corrective action, including withdrawal, disabling or recall, and the documentation duty in Article 18 sit with the provider. The deployer’s duties include suspending use and informing others under Article 26(5) and keeping the logs under its control under Article 26(6).
Interpretation: none of these duties reach beyond high-risk AI systems. The European Commission states that the high-risk rules start to apply on December 2, 2027, in the Annex III areas, and on August 2, 2028, for systems that fall under Annex I. Deciding whether a given system belongs in that category, and whether an organization acts as its provider or its deployer, calls for legal analysis. For a system outside these high-risk rules, the next point is a governance habit, not a requirement of these provisions. Stopping a system and keeping its records are separate decisions, and the governance cycle includes the end.
Checks before an AI system is retired
The following checks are interpretation, offered as a starting point rather than a complete program.
- Name who decides. Record who can approve a planned retirement and who can switch the system off urgently. MANAGE 2.4 asks for responsibilities that are “assigned and understood.”
- Test the urgent path. MANAGE 2.4 also speaks of mechanisms that are “in place and applied.” Check that the shutdown route works, at least in a test.
- Map what depends on the system. List the systems, reports and teams that use its outputs before setting a switch-off date.
- Decide what to keep before deleting anything. The organization may need logs, documentation, predictions and explanations later. Check which retention rules apply, and record where each item is stored and for how long.
- Review outputs still in use. Find past scores, ratings or classifications that remain in records, and decide whether people should keep relying on them.
- Review the replacement on its own merits. A successor is a different system, even when it does the same job. The reasons are the same as for silent model changes.
- Tell the people affected. Users, and others who relied on the outputs, may need to know what changes and whom to contact.
- Update the record. Mark the system as retired in the AI inventory instead of removing the entry, and note what was kept.
Conclusion
An AI system’s last day is part of its governance. NIST’s AI RMF asks for processes to decommission and phase out AI systems safely, and for mechanisms to deactivate systems whose performance or outcomes are inconsistent with intended use. For high-risk systems, the EU AI Act requires providers to take corrective action on non-conforming systems, including withdrawing, disabling or recalling them as appropriate, requires deployers to suspend use of a system where they have reason to consider that its use may present a risk, and sets retention periods for documentation and logs.
Before the next AI system is switched off, the record should show who decided and what was kept, and someone should check which of its past outputs are still shaping decisions.
This article reflects the author’s personal views, not those of any employer, and interpretation of publicly available materials from NIST and the European Commission’s EU AI Act Service Desk, as available on October 24, 2026. It is not affiliated with or endorsed by either body and does not reproduce their full requirements. It is general information, not legal, compliance or certification advice, and reading it does not create any advisory relationship. Laws, guidance and application dates change. Refer to the official texts, including the EU AI Act as published in EUR-Lex, and get qualified advice before acting on how they apply to your organization.
Sources: NIST, AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf; NIST AI RMF Playbook, Govern, https://airc.nist.gov/airmf-resources/playbook/govern/; Upol Ehsan, Ranjit Singh, Jacob Metcalf and Mark O. Riedl, “The Algorithmic Imprint,” ACM FAccT 2022, https://arxiv.org/abs/2206.03275; European Commission AI Act Service Desk, Articles 3, 18, 19, 20 and 26, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-18, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-19, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-20 and https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26; European Commission, AI Act, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai