AI Model Retirement Guide: Retire Models, Weights, Endpoints and Keys Safely

AI models are retired far more often than ordinary software, yet most organisations have no process for it, so retired models leave behind live endpoints, valid API keys, copies of weights and fine-tuning data nobody owns. Retirement happens two ways: a provider announces a deprecation and a shutdown date, or your own team replaces a model it built or fine-tuned. Both need the same discipline: find every dependency, migrate and validate, revoke the credentials and endpoints, dispose of or preserve the artefacts deliberately, and close the inventory record with evidence. This guide covers the model itself. Retiring an agent that uses a model is covered by the AI Agent Decommissioning Checklist, and lifecycle governance in general by the AI Model Risk Management Guide. It is written for ML platform, security and AI governance teams.

Provider lifecycle terms below are taken from each provider's public documentation as checked in November 2026; providers are listed alphabetically and the order is not a ranking.

Key takeaways

• Provider shutdowns are fixed deadlines. Hosted model APIs publish notice periods from 45 days to 6 months, and after the date requests fail, so retirement must be planned from the day a model is adopted.
• Fine-tunes inherit the base model's fate. A custom model built on a provider base typically stops working when the base is shut down, and the training data and evaluation sets are what you need to rebuild it.
• Credentials outlive models. API keys, service principals and endpoint URLs created for a model stay valid after the model is gone unless someone revokes them, which makes them prime targets for LLMjacking.
• Disposal and preservation are both decisions. NIST AI RMF GOVERN 1.7 asks for policies on where retired models and artefacts are stored and for how long, alongside safe disposal of what is not kept.
• Close the record, do not delete it. The inventory entry, validation results and retirement evidence are what auditors and incident responders will ask for after the model is gone.

Two kinds of retirement

How hosted model providers retire models

Each provider uses its own terms and notice periods, and partner platforms can set their own dates for the same model. Track the dates from the platform you actually call.

• Amazon Bedrock: models move through Active, Legacy and End-of-Life (EOL). In Legacy, new customers cannot adopt the model, existing customers may lose access after 15 days of inactivity, and new Provisioned Throughput and fine-tuning jobs cannot be created. The Legacy period is 6 months for most models or 45 days, and the model card shows an "EOL no sooner than" date. After EOL, requests fail unless a private arrangement with the provider exists. Lifecycle state is returned in the modelLifecycle field of GetFoundationModel and ListFoundationModels. Bedrock dates can differ from the model provider's own dates.
• Anthropic: models are Active, Legacy, Deprecated or Retired. Customers with active deployments receive at least 60 days' notice before retirement of publicly released models, by email and in the documentation, and requests to retired models fail. The Usage page export in the Claude Console breaks usage down by API key and model, which helps find remaining callers. Anthropic states a commitment to long-term preservation of model weights.
• Google (Gemini models on Google Cloud): generally available models are listed with release and retirement dates. When a shorter-availability model is scheduled for retirement Google posts a fixed date giving at least 45 days to migrate, and states that retirement dates may be extended but will not be moved earlier. Retired models are listed with a recommended upgrade.
• Microsoft (Azure OpenAI in Foundry): deprecated models keep serving existing customers while new customers are blocked; retired models return 410 Gone. Standard GA models are deprecated at 12 months and retired at 18 months, with a shorter 12-month lifecycle for some partner models, and retirement notice of at least 60 days for GA models and 30 days for preview models. The versionUpgradeOption deployment property takes OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired or NoAutoUpgrade; provisioned deployments are never auto-upgraded. Notices go by email and Azure Service Health, and the Models API exposes lifecycleStatus, noting that the API calls a retired model Deprecated.
• OpenAI: deprecated models work until their shutdown date, after which they no longer accept requests through the standard API. Minimum notice is at least 6 months for generally available models and at least 3 months for specialised variants and image generation models, with preview models possibly retired on much shorter notice, unless safety or compliance requires faster action. The List and Retrieve model endpoints expose a shutdown_date field. Fine-tuned versions follow the same shutdown schedule as their base models.

Platform-specific hardening is in the Amazon Bedrock Security Guide, Anthropic API Keys Security Guide, Google Vertex AI Security Guide, Azure OpenAI and Azure AI Foundry Security Guide and OpenAI API Keys Security Guide.

Policy point: auto-upgrade avoids an outage but changes model behaviour without your validation. For regulated or high-risk use cases pin versions and migrate deliberately; for low-risk internal uses auto-upgrade can be acceptable if you monitor quality.

Inventory and dependency discovery

You cannot retire what you cannot find. Before any retirement, build the dependency list for the model from several sources, because no single one is complete.

Record a retirement date field in the inventory at adoption time, populated from the provider's published date or your own review cycle, and alert owners at 90, 30 and 7 days.

Migration and validation

A replacement model is a new model for risk purposes, even from the same family. Treat migration as a change with validation, not a string replacement.

1. Select the replacement: use the provider's recommended successor as a starting point, and confirm it meets the same data residency, retention and contractual terms.
2. Rerun evaluations: run the original evaluation set, safety and jailbreak tests, and business acceptance tests against the replacement. Prompt templates often need tuning.
3. Rebuild fine-tunes: retrain adapters or custom models on the new base from the retained training data, then validate. If the training data was not kept, plan for a longer migration.
4. Shadow or canary: run the new model in parallel or on a small traffic share and compare outputs and refusal rates before switching.
5. Cut over by configuration: route through a gateway alias or configuration value so rollback is a single change while the old model is still available.
6. Record approval: the model risk owner signs off the replacement and the inventory records both models with dates.

Rollback: rollback only exists until the provider's shutdown date or your own teardown. Keep the old route and credentials disabled but recoverable until the replacement has run cleanly for an agreed period, then proceed to revocation.

Revoking endpoints, keys and identities

Every model in production has non-human identities around it. These must be removed when the model goes, following the same discipline as the NHI Offboarding and Decommissioning Guide.

• Provider API keys: revoke keys created for the model or project rather than leaving them for a future use. Unused keys with billing access are what attackers seek in LLMjacking. See the LLMjacking Guide.
• Cloud identities: remove IAM roles, service accounts, managed identities and policies used to invoke the model, run fine-tuning jobs or read training buckets.
• Self-hosted endpoints: delete serving endpoints, load balancer routes and DNS records; a stale DNS name pointing at released infrastructure can be taken over.
• Gateway routes and quotas: remove the route and model alias so new code cannot call it, and alert on any request for the retired model ID.
• Secrets manager entries: delete or archive the secrets after revocation at source, so the vault does not hold credentials that look valid. The Secrets Rotation Runbook Template includes verification steps.
• Verify: confirm revoked keys fail, provider usage for the model drops to zero and no new errors appear in calling services.

Weights, fine-tuning data and other artefacts

Decide artefact by artefact whether to preserve or dispose of it, and record the decision. NIST AI RMF GOVERN 1.7 calls for storage policies that say where retired systems, models and artefacts are kept and for how long, and preservation of ancillary data needed to understand the retired system, such as predictions and explanations.

For storage you control, follow NIST SP 800-88 Rev 2, Guidelines for Media Sanitization (final, September 2025), using cryptographic erase where keys are managed per bucket or volume. Retention periods come from your Data Retention and Disposal Policy Template; see also the Data Retention and Secure Deletion Guide. Where training data subject to data protection law is kept to allow a rebuild, record the lawful basis and the planned deletion date.

Retirement runbook

1. Trigger and owner: log the provider notice or the internal decision, name the model owner and set a target date at least two weeks before any provider date.
2. Discover: build the dependency list from the sources above.
3. Decide: replace, rebuild or retire the use case; record the artefact preserve or dispose decisions.
4. Migrate and validate: follow the migration steps and get sign-off.
5. Disable: block the old model ID at the gateway and disable keys and endpoints, keeping them recoverable during the rollback window.
6. Revoke and tear down: after the window, revoke credentials, delete endpoints and DNS, delete provider-side custom models and files.
7. Dispose and preserve: sanitise storage, archive the preserved set with integrity hashes and access restricted to named roles.
8. Close the record: mark the inventory entry Retired with dates, evidence links and the successor model.

Small teams using one hosted provider can run this as a single ticket with a checklist. Large organisations should automate discovery from gateway logs and provider APIs, feed lifecycle dates into the inventory, and report upcoming retirements to the AI governance forum monthly.

Detection and measurement

• Monitor: provider lifecycle fields (modelLifecycle, lifecycleStatus, shutdown_date), provider notices and Azure Service Health advisories; gateway requests for retired model IDs; activity on keys tagged to retired models.
• Metric 1: percentage of production models with a recorded retirement or review date.
• Metric 2: models migrated before the provider date, versus emergency migrations in the final 7 days.
• Metric 3: count of active credentials and endpoints linked to retired models (target zero within 30 days of retirement).
• Metric 4: percentage of retirements closed with complete evidence (validation, revocation, disposal record).
• Metric 5: number of untracked weight or dataset copies found in storage scans.

Framework mapping

NIST AI RMF GOVERN 1.7 is the AI-specific anchor: processes for decommissioning and phasing out AI systems safely without increasing risk.

Common failure patterns

• Shutdown day surprise: the provider notice went to a former employee's mailbox, so the first sign is failing requests in production.
• Silent auto-upgrade: a deployment moves to the successor model automatically and output quality or refusal behaviour changes with no validation.
• Lost training data: a fine-tune must be rebuilt on a new base but the curated dataset was deleted, turning a migration into a project.
• Orphaned keys and endpoints: the model is gone but its API keys, service principals and DNS names remain valid.
• Forgotten copies: weights deleted from the registry survive in notebooks, GPU snapshots and developer laptops.
• Deleted evidence: the team removes the model card and logs along with the model, leaving no way to explain past decisions.

Practitioner checklist

• Record a retirement or review date for every model at adoption.
• Route provider lifecycle notices to a shared, monitored mailbox and pull lifecycle fields from provider APIs.
• Set a version pinning or auto-upgrade policy per risk tier.
• Retain fine-tuning and evaluation data needed to rebuild, with a lawful basis and deletion date.
• Rerun evaluations and safety tests on every replacement before cutover.
• Revoke keys, identities, endpoints and DNS for the retired model and verify zero usage.
• Delete provider-side custom models and uploaded files after migration.
• Sanitise storage holding weights and data per NIST SP 800-88 Rev 2.
• Preserve model card, validation and decision logs for the records period.
• Close the inventory entry with evidence and successor model.

Standards and references

• NIST: AI RMF Playbook, GOVERN 1.7
• NIST: SP 800-88 Rev 2 Guidelines for Media Sanitization
• AWS: Amazon Bedrock Model Lifecycle
• Anthropic: Model Deprecations
• Google Cloud: Model Versions and Lifecycle
• Microsoft Learn: Azure OpenAI Model Deprecations and Retirements
• OpenAI: Deprecations

Related NHI Mgmt Group resources: AI Model Risk Management Guide, AI Agent Decommissioning Checklist, NHI Offboarding and Decommissioning Guide, Fine-Tuning and LoRA Security Guide.