Model Deprecation Policy

The policy must specify a minimum notice period (e.g., 12 months) before an API endpoint or model version is turned off. This prevents vendor lock-in risk by giving your engineering teams adequate time to re-train internal models or qualify a new provider. The timeline should be contractually binding, with financial penalties for non-compliance to ensure the vendor treats the deprecation as a formal change management process rather than a routine update.

A vendor's obligation to provide automated migration scripts or compatibility adapters is critical. The policy should detail the provision of:

• Weight conversion tools for cross-framework compatibility (e.g., PyTorch to ONNX).
• Output normalization layers to ensure the new model's logits match the statistical distribution of the deprecated model.
• Prompt translation middleware if the successor model requires different instruction formatting. Without this, you risk a concept drift event where downstream business logic breaks silently.

The policy must address the fate of fine-tuned adapters and proprietary data. Upon deprecation, the vendor must:

• Irrevocably delete all customer training data lineage and fine-tuning checkpoints.
• Provide a final export of the model's weights and tokenizer in a standardized format (e.g., safetensors) for archival purposes.
• Issue a certificate of destruction to close the data processing agreement loop. This ensures compliance with purpose limitation controls and prevents residual IP leakage.

Before full deprecation, a vendor should offer an extended support window where the model remains available for inference but receives no performance improvements. This is often called a long-term support (LTS) version. During this phase:

• Security patches for adversarial robustness must still be applied.
• The API stability commitment remains in force, guaranteeing no breaking changes to the input/output schema.
• The vendor provides a hallucination rate benchmark comparison to the successor model to justify the migration.

A mature policy includes a rollback procedure clause. If the successor model exhibits safety alignment threshold failures or catastrophic grounding score drops in production, the enterprise must have the right to reactivate the deprecated model temporarily. This requires the vendor to maintain a hot standby inference capacity for a defined post-deprecation period (e.g., 90 days) to act as a circuit breaker during a model risk tiering escalation.

For high-risk classification systems, the policy should mandate a software escrow agreement. If the vendor ceases operations or abruptly discontinues a model, the escrow agent releases the source code, model weights, and deployment scripts. This guarantees business continuity and mitigates vendor concentration risk. The escrow must include the full AI Bill of Materials (AIBOM) to allow your team to independently rebuild the inference environment in an air-gapped environment if necessary.