Implementation Guide
How to Write an AI Model Deprecation and Sunset Policy
A practical guide to lifecycle stages, notice periods, dependency mapping, and access revocation so you can retire model versions without breaking dependent agents or leaving orphaned integrations active.
An AI model deprecation policy defines the lifecycle stages, notice periods, dependency mapping, and access revocation steps required to retire a model version without breaking dependent agents or leaving orphaned integrations active. It must extend beyond provider-published deprecation dates to cover internal identity and access controls, since model providers manage API availability, not agent tool-call permissions or credential revocation.
Model Deprecation Is an Access Control Event, Not Just a Version Change
Major model providers, including OpenAI, Microsoft Azure OpenAI, AWS Bedrock, and Google Vertex AI, publish formal lifecycle documentation defining stages such as active, deprecated, and retired, with a published shutdown or retirement date attached to each model version. This documentation governs API-level availability. It does not address what happens inside the enterprise once that date arrives.
None of the reviewed provider documentation covers revocation of agent identities, API keys, or tool-call scopes tied to a specific model version. That work is left entirely to the customer's internal identity and access management systems. A deprecation policy written only around provider notices will track when a model becomes unavailable, but not whether agents, tools, or workflows still holding credentials for that model have been identified and disconnected.
Treating deprecation as a governance and runtime enforcement problem, rather than a product-versioning exercise, is what closes that gap.
Core Components of a Model Deprecation Policy
An enforceable policy should cover four interrelated areas. Together they turn a provider notice into an internal control process.
Lifecycle Stages
Active, deprecated, and retired states mapped to each model version in production.
Dependency Mapping
A live inventory of agents, tools, and workflows referencing each model.
Access Revocation
Model-scoped credentials and tool-call permissions retired independently of application identity.
Audit Logging
Model-version usage and revocation actions retained for compliance review.
Defining Lifecycle Stages and Notice Periods
A usable policy should mirror the lifecycle terminology providers already use (active, deprecated, retired) and attach internal ownership and deadlines to each stage. Because retirement dates are published per model version rather than per model family, enterprises running multiple concurrent versions must track deprecation schedules at the version level.
In multi-vendor environments, notice periods differ across providers, so internal policy should set its own minimum notice window aligned to the shortest window offered by any provider in active use, rather than treating each vendor's timeline as sufficient on its own.
Provider notices typically point to a specific successor model, but compatibility testing between the deprecated and replacement model is the customer's responsibility, not something the provider guarantees. The policy should require that compatibility validation before migration is treated as complete.
Practical rule: Set an enterprise minimum notice window based on the shortest provider notice in your stack, then require version-level ownership, dependency checks, and compatibility validation before any stage transition.
Model Retirement Workflow
Retirement should be operationalized as a sequence of identity, credential, logging, and routing controls, not only as a calendar reminder of a provider end date.
-
Treat model identity as a first-class object
Permissions and tool-call scopes should be assignable and revocable at the model-version level, separate from application identity.
-
Use independently scoped credentials
API keys, service accounts, or tokens tied to a specific model endpoint should be revocable or rotatable without affecting other model versions.
-
Log model version on every call
Recording the model-version identifier on each inference and tool-call event allows orphaned integrations to be detected through log analysis rather than manual audit.
-
Stage traffic routing
Canary or percentage-based routing between deprecated and replacement models surfaces failures before full cutover.
-
Maintain a rollback path
A fallback procedure should exist in case a migrated agent or workflow fails against the replacement model.
What Good Looks Like in Practice
When these controls are in place, deprecation becomes a controlled access event: dependencies are known, credentials can be narrowed or revoked by model version, usage is visible in logs, migration risk is reduced through staged routing, and failed cutovers can be reversed. Provider lifecycle dates remain necessary inputs. They are not a complete enterprise policy on their own.
Enforce Model Retirement at the Runtime Layer
A written policy defines the process. Enforcing it requires runtime visibility into agent identity, tool-call permissions, and model-version usage across your AI environment.
Explore Runtime Governance