What it means
- Every AI model or AI feature has a planned, controlled end of life, not just a launch.
- Retirement covers: switching it off, moving users to a replacement or a manual process, deleting or archiving its data and weights, revoking its access, and keeping the records regulators may still ask for.
- Applies equally to models you built and to vendor models that get deprecated (for example an LLM API version that the provider sunsets).
- ISO 27001 reuse: Partial. Asset inventory, information deletion and secure disposal from ISO 27001 cover the mechanics. AI-specific parts (vendor model deprecation, archiving model cards and validation evidence, user migration) are new.
Why it matters
- RBI FREE-AI expects model governance "from design to decommissioning", so a regulated entity must show the end of the lifecycle too.
- Forgotten "zombie" models keep running on stale data, keep API keys alive, and keep personal data you no longer have a reason to hold (a DPDP Act problem).
- When a decision made by a retired model is disputed later, you still need its documentation and logs.
Checklist
- Add "retirement trigger" and "planned review date" fields to each entry in the AI inventory (SC-AI-003 AI system inventory).
- Define retirement triggers: sustained drift, failed revalidation, vendor deprecation notice, business change, regulatory change.
- Write a short decommissioning runbook: owner sign-off, user and customer communication, fallback or replacement, cut-over date.
- Route retirement through change management (SC-AI-019 Change management and approval gates) so it gets an approval and a ticket.
- Revoke service accounts, API keys, agent tool permissions and vector store access tied to the model (SC-AI-030 Access control for AI systems and agents).
- Delete or archive training data, embeddings, fine-tuning sets and model weights per the retention schedule (SC-AI-012 Data minimisation and retention for AI).
- Archive the model card, validation reports and decision logs for the legal retention period (SC-AI-014 Model documentation (model cards, system cards), SC-AI-032 Logging and record keeping).
- Track vendor deprecation notices and plan migration before the vendor cut-off date.
- Update the inventory status to "retired" with the date and a link to evidence.
Evidence examples
- Approved decommissioning change ticket with sign-off from the model owner and risk.
- Inventory export showing retired models, retirement dates and reasons.
- Deletion certificate or log of data and weights removed (or archive location and retention end date).
- Access review showing the model's keys and service accounts disabled.
- Customer or internal notice announcing the switch to the replacement or manual process.
- Vendor deprecation email and the migration plan that responded to it.
Common pitfalls
- Turning off the user interface but leaving the model endpoint and keys live.
- Deleting everything, including logs needed to answer a complaint or regulator query later.
- No owner for vendor model version changes, so a silent upgrade replaces a validated model.
- Shadow copies of training data left in notebooks, buckets or vendor fine-tuning accounts.
Satisfies
- SupervisoryPRA SS1/23
- VoluntaryNIST AI RMF and GenAI Profile
- SupervisoryOSFI E-23
- VoluntaryRBI FREE-AI
Standards crosswalk
Clause references only. Check the standard itself for the exact wording.
ISO/IEC 42001
- 8.1 operational planning and control
- A.6.2.6 operation and monitoring (including deciding when to retire)
- A.6.2.7 technical documentation kept after retirement
ISO/IEC 27001
- A.5.9 inventory of assets
- A.8.10 information deletion
- A.7.14 secure disposal or re-use of equipment
SOC 2
- CC6.5
- CC8.1
- C1.2
Key takeaways
- Plan the end of a model's life at the start; record the retirement trigger in the inventory.
- Retirement means switching off, revoking access, deleting or archiving data, and keeping evidence.
- Vendor model deprecations count as retirements and need the same discipline.