AI Decommissioning Checklist: Retiring an AI System Without Breaking the EU AI Act

Switching a system off is the easy part. The obligations that outlive it are what catch people out. When you retire a high-risk AI system, the EU AI Act does not treat the records as disposable — logs, technical documentation and your registration entry all have defined survival periods, and a few duties only start at decommissioning. This checklist walks both roles — provider and deployer — through a clean shutdown that an auditor would sign off two years later.

There is no single "Article 30: decommissioning" in Regulation (EU) 2024/1689. The duties are scattered across record-keeping, documentation retention, registration and post-market monitoring. The job is to pull them into one ordered close-out so nothing that has to be kept gets deleted, and nothing that has to be reported gets missed.

---

First: what "decommissioning" actually means here

Decommissioning is the deliberate, permanent withdrawal of an AI system from operation — you stop using it, stop offering it, or replace it. It is distinct from a substantial modification (Article 3(23)), where you change the system enough that it is effectively re-placed on the market and re-assessed. If you are replacing an old model with a materially different one, you may be decommissioning the old system and placing a new one — two separate workstreams. Be honest about which you are doing; the obligations differ.

A clean decommissioning has four jobs: preserve the evidence that has to survive, update the public-facing records, tell the people who relied on the system, and close the monitoring loop. The order matters — do the retention step before anyone touches a delete button.

---

The retention periods you cannot get wrong

This is the part that bites. Different artefacts have different survival clocks, and they keep running after the system is gone.

Read those two ten-year rows again. Retiring a system in 2028 does not let you bin its Annex IV file or its declaration of conformity — they run until ten years after the system first went to market, which may be well into the 2030s. Build the retention schedule from the placing-on-the-market date, not the switch-off date.

The logging clock (Article 12) is a design duty, not a retention duty — high-risk systems must record events automatically throughout their lifetime. Decommissioning ends new logging, but the logs already captured fall under the Article 19 (provider) and Article 26(6) (deployer) minimums above. Where the logs are personal data, GDPR storage-limitation rules apply on top — keep them only as long as you have a lawful basis, which is exactly why the "6 months unless other law" wording exists.

---

Update the registration and the inventory

If the system was high-risk and registered in the EU database under Article 49, decommissioning is a registration event, not a silent deletion. Update the entry to reflect that the system has been withdrawn — the database is meant to show the live picture, and a system you no longer operate but still show as active is a defect in your own record. The deployer registration obligations for certain public-body and Annex III deployments are updated the same way.

Internally, your AI inventory is the master record. Mark the system as decommissioned with the date, the reason, the replacement (if any), and a pointer to where the retained logs and Annex IV pack now live. An inventory that only ever adds rows and never closes them stops being trustworthy — the close-out entry is what lets a future auditor follow the trail from "this system existed" to "here is everything we kept about it."

---

Notify the people who relied on it

Decommissioning has human consequences that a deletion script will not handle.

• Deployers who integrated your system need enough notice to migrate or replace it — and they have their own Article 26 records and, where applicable, oversight duties tied to it.
• Affected persons who were subject to decisions informed by the system may still have rights to explanation or to contest outcomes; ending the system does not retroactively erase those. Keep the records that let you answer a complaint about a decision the system made while it was live.
• Where the system fed a fundamental rights impact assessment (Article 27) context (a public-body or Annex III 5(b)/5(c) deployment), note the withdrawal against that assessment so the FRIA record reflects reality.

None of this is onerous, but it is the difference between "we turned it off" and "we can prove we turned it off responsibly."

---

Close out post-market monitoring

The provider's post-market monitoring duty under Article 72 runs while the system is on the market. Decommissioning is the point to formally close the monitoring file: confirm there are no open serious-incident reports owed under Article 73, document the final monitoring conclusions, and record that data collection has ended. If an incident is still under investigation, the reporting duty does not vanish because you switched the system off — resolve it, then close.

A useful discipline: write a short decommissioning memo that states the shutdown date, links the retained artefacts and their retention end-dates, confirms registration was updated, and confirms monitoring is closed with no outstanding incidents. That one page is what a market-surveillance authority would ask for first.

---

The decommissioning checklist

1. Classify the event — decommissioning vs substantial modification vs replacement (Article 3(23)). Document which.
2. Freeze the evidence — secure provider logs (Article 19, ≥6 months) and deployer logs (Article 26(6), ≥6 months) before any system teardown.
3. Set the 10-year clocks — Annex IV technical documentation and the declaration of conformity retained until 10 years after placing on the market (Article 18).
4. Update Article 49 registration — mark the system withdrawn in the EU database; update deployer registration where applicable.
5. Close the inventory row — date, reason, replacement, location of retained records.
6. Notify — downstream deployers, affected persons' channels, and the FRIA record (Article 27) where relevant.
7. Close monitoring — finalise Article 72 conclusions; confirm no open Article 73 serious-incident reports.
8. Write the decommissioning memo — one page linking all of the above.

---

Worked example: a recruiter retires a CV-screening tool

Talentbrücke GmbH, a recruitment-software company with about 70 employees and roughly €14M turnover, retires a CV-screening system it first placed on the market in early 2028 and provided to client HR teams — a high-risk employment use under Annex III. Switch-off is scheduled, but the close-out is the real work.

As provider, Talentbrücke freezes the system's logs (Article 19) and confirms the Annex IV documentation and declaration of conformity stay on file until ten years after the tool was first placed on the market — that date, not the 2029 switch-off, governs (Article 18). It updates the Article 49 entry to "withdrawn," writes to the client HR teams (its deployers) with a migration window, and closes the Article 72 monitoring file after confirming no open Article 73 incidents. Each client, as deployer, retains its own operating logs for at least six months (Article 26(6)). The decommissioning memo ties it together. Two years later, when a former candidate queries a 2028 rejection, Talentbrücke still has the records to answer — because it kept the right things, not everything.

---

How Confir helps

Confir tracks each AI system in your inventory through its whole life, including retirement: it records the decommissioning event, sets the retention clocks against the right dates (Article 18's ten years, the Article 19 and 26(6) log minimums), prompts the Article 49 registration update, and flags any open post-market-monitoring or incident items before you close the file. Because the engine is deterministic and rule-based, the same retirement event produces the same close-out checklist every time — and the audit log preserves what you kept and why.

Related guides

• Article 12 record-keeping and logging
• Article 18 technical documentation retention
• Article 49 registration in the EU database
• Article 72 post-market monitoring
• Deployer obligations under Article 26
• AI inventory template