Chapter 15. Retirement: S10 and Gate G5
The stage most often skipped, and the one that determines whether you can answer questions about a system after it stops running.
15.1 Why retirement is governed at all
A decommissioned AI system leaves behind obligations: data that must be retained or deleted on a schedule, access that must be revoked, evidence that must remain available for audit or dispute, and knowledge that will otherwise be lost.
Organizations routinely handle the first two and neglect the second two. The consequence surfaces when a question arrives about a decision the system made eighteen months ago and nobody can reconstruct what version was running, what it was grounded on, or who authorized it.
15.2 What S10 must produce
Table 41.
| Obligation | Evidence | Owner |
|---|---|---|
| Data retention or deletion | Confirmation from the data platform, per the retention schedule | Data Owner |
| Access revocation | IAM deprovisioning confirmation, including machine identities | System Owner with Security |
| Evidence preservation | Archived record set sufficient to answer post-retirement questions | System Owner |
| Knowledge preservation | What was learned that should inform future systems | System Owner |
| Dependency check | Confirmation that nothing downstream still consumes its outputs | Architect |
The dependency check is frequently the one that stops a retirement. Systems acquire consumers nobody recorded, and switching off a service that quietly feeds a report is a familiar incident. [Practice recommendation] Use Control Plane integration telemetry to identify actual consumers instead of relying on the documented dependency map, which is usually incomplete.
15.3 What “evidence preservation” means concretely
The retained set should let someone reconstruct, without access to the running system: what the system was, what it was authorized to do, who authorized it, what data grounded it, what its risk classification was and how it changed, what changes it underwent, and what assurance evidence supported its authorization.
In practice this is the record set: final ADR chain, Risk Classification history, Deployment Authorization records, Change records, Agent Card if applicable, Data Lineage record, AI Assurance Summaries, and any exceptions. Retention runs for the life of the system plus a defined period; three years is the framework’s default and your regulatory context may require longer.
15.4 Gate G5 — Retirement
Table 42.
| Element | Content |
|---|---|
| Purpose | Confirm orderly decommissioning |
| Entry criteria | Decommissioning plan covering retention, access, and knowledge |
| Required evidence | Retention or deletion confirmation; access revocation confirmation; archived audit trail |
| Decision authority | System Owner plus Data Owner; Tier 3–4 adds AI Governance Lead confirmation that no open obligations remain |
| Outcomes | Approve / Approve with conditions / Escalate |
| Automation | Moderate. Deletion and revocation confirmation automate well; knowledge preservation does not |
Note that Reject is not an available outcome. A retirement can be delayed by conditions, but a system whose owner has decided to decommission it is not kept running by a governance gate. What the gate controls is whether decommissioning was completed properly.
15.5 Orphaned and abandoned systems
The harder retirement problem is systems nobody retires: a pilot whose sponsor moved on, a service still running because switching it off feels risky, a vendor feature nobody enabled deliberately.
[Practice recommendation] Run an annual estate sweep against three signals: no Business Outcome Assurance evidence in twelve months, no owner responding to governance correspondence, and no measurable usage. Any system triggering two of three enters a defined disposition process with a deadline, ending in either re-authorization with a current owner or retirement. Absent a forcing mechanism, orphaned systems accumulate indefinitely, and each one is an unowned risk carrying a real tier.