AI Model Retirement Criteria in Banking: When to Decommission, How to Govern It

Model Retirement Is the Governance Phase Everyone Skips

Deployment gets a validation sign-off. Monitoring gets a dashboard. Retirement gets a Jira ticket and a note in a spreadsheet, if it gets documented at all. That asymmetry is the problem: a model that was quietly decommissioned but never formally retired keeps sitting in the active inventory, consuming governance attention it no longer deserves, while its access credentials, inference logs, and API endpoints sit unmanaged in production infrastructure nobody is watching anymore.

That second failure is the one that actually hurts in an audit — not the stale inventory entry, but the live credential or open endpoint nobody remembered to close.

Four Triggers That Should Force a Formal Retirement Review

Performance. Sustained PSI breach past 0.25 that the validation function cannot remediate, AUC-ROC falling below the threshold set at original validation, or persistent false-positive/false-negative rates outside tolerance despite remediation attempts. One bad quarter doesn't trigger retirement; a sustained, unremediable breach does.

Regulatory. An examination finding identifying a compliance gap the model's design cannot fix through configuration or retraining, a new rule the model cannot satisfy, or a provider deprecating the underlying API without a governance-equivalent successor. This category requires legal and compliance sign-off, not just the model owner's judgment.

Supersession. The most common planned trigger: a validated replacement is already live. Retirement of the incumbent should wait until the replacement has run in parallel long enough to prove stable production performance — retire the old model too early and you've removed your fallback before you know the new one actually works at scale.

Business. The function the model served has been discontinued, restructured, or the model's output no longer feeds any consequential decision. This needs the business owner's written statement of why the model no longer serves its registered purpose — not a model quietly left in the inventory while nobody uses it.

The Retirement Sequence: Approve Before You Decommission

The sequence matters because the common failure runs it backwards. Infrastructure teams decommission a model operationally the moment a replacement looks ready, long before the retirement approval has actually been granted — which means governance was bypassed on the way out, not just on the way in. An examiner who finds a model removed from production before its retirement approval record exists treats that as evidence the governance process doesn't actually control the lifecycle, regardless of how sound the underlying retirement decision was.

India BFSI Context: What Retires and What Doesn't

DPDP Act deletion obligation. When a model retires, the personal data it processed — training data, inference-log feature values, customer-linked outputs — loses its purpose unless a separate legal basis (regulatory retention, legal hold) keeps it alive. That deletion obligation fires at the moment of retirement; it isn't something to defer to a future data-cleanup project.

Cross-border data at retirement. If the retired model ran on a third-party or cloud-hosted service, confirm contractually that any customer data sent to that provider has actually been deleted from the provider's systems, not just disconnected from the bank's pipeline. For payment-related data specifically, RBI's data localization requirement means offshore retention after the relationship ends is not a gray area — it's a gap to close before the retirement is marked complete.

Credit decision records outlive the model. Retiring a credit model does not retire the obligation to keep records of the individual decisions it made. **** The retirement data-classification step must specifically route these records to the correct retention system rather than the model archive, where they are easy to lose track of.

LLM provider deletion confirmation. For LLM API integrations (OpenAI, Anthropic, Gemini, or others), retirement should include a formal request for, and documented receipt of, data deletion confirmation from the provider. A retirement that closes out the bank's internal record without that confirmation leaves customer data sitting in a vendor's systems with nobody accountable for it anymore.

Action Checklist Before You Mark a Model Retired

1. Confirm the trigger category in writing — performance, regulatory, supersession, or business — with the owning function's sign-off.
2. Map every downstream dependency and get a transition plan from each before touching production.
3. Classify every data artifact against DPDP deletion obligations and your retention schedule, with legal/compliance sign-off, before decommissioning.
4. Get risk committee approval recorded before infrastructure removes anything — never the other way around.
5. Request and retain written deletion confirmation from any third-party or LLM provider involved.