AI Model Retirement Runbooks Should Be In Every Procurement Pack

Model Intelligence & News

11 September 2026 | By Ashley Marshall

The model you choose today is not a permanent dependency. UK buyers now need a runbook for what happens when a supplier retires, redirects or replaces it.

Model choice is now a lifecycle risk

AI procurement used to treat the selected model as a technical detail buried inside the supplier stack. That assumption is no longer strong enough. The models behind copilots, support assistants, document systems and agentic workflows change quickly. Some become legacy, some are deprecated, some are redirected by a platform provider, and some are retired completely. When that happens, the business risk is not abstract. A workflow that worked yesterday can produce different results, require new prompts, cost more to run, lose a supported feature, or stop answering API calls altogether.

OpenAI now publishes formal model deprecation notice periods, including at least six months for generally available models and at least three months for specialised variants unless safety or compliance concerns require a faster retirement. Anthropic says publicly released models receive at least 60 days notice before retirement, while warning that requests to retired models will fail. Microsoft Databricks describes a lifecycle from update to deprecation to retirement, and says any workload using a retired model stops working. Those are useful commitments, but they still leave a practical question for the buyer: who inside your business notices the change, tests the replacement and signs off the migration before customers or staff feel it?

That is why a model retirement runbook belongs in the procurement pack. It turns a supplier promise into an operational test. Before a contract is signed, ask the vendor to show how model changes are announced, how affected customers are identified, how replacement models are recommended, and what evidence proves the new model behaves acceptably on your work. The counterargument is that vendors already handle this through managed platforms. Sometimes they do. But managed does not mean invisible risk. It means the supplier has a process, and procurement should inspect it.

A retirement runbook is more than a notice email

A notice email is not a runbook. It tells you something is changing. It does not tell you whether your customer service assistant, finance report generator, CRM enrichment flow, sales proposal tool or internal knowledge bot will still meet its acceptance criteria after the change. A proper runbook starts with an inventory: the model ID, provider, region, endpoint, feature dependencies, prompts, tools, retrieval sources, evaluation pack, business owner and technical owner. Without that inventory, a retirement notice lands in somebody's inbox and the organisation guesses where the dependency is hiding.

The runbook should then define the migration path. That means the recommended replacement model, expected behavioural differences, cost changes, latency changes, feature gaps, testing timetable and rollback route. Microsoft Databricks is explicit that deprecated models are not recommended for new workloads and that existing customers should migrate to a recommended replacement model or sunset affected workloads. That wording matters because it gives procurement a useful phrase: replacement is not enough. The business needs a choice between migration, sunset, redesign or supplier escalation.

In practice, the runbook should be short enough to use under pressure. One page per model family is often enough for an SME. List the affected workflows, the people who must be notified, the test set that must pass, the date by which production changes must be complete, and the decision maker who can approve a temporary exception. Larger organisations can add change advisory boards, security review and supplier management gates, but the basic control is the same. If the current model disappears, the business should not be discovering its dependency map for the first time.

UK guidance points to lifecycle evidence, not one-off approval

The UK policy direction supports this shift. GOV.UK's AI Risk Management Toolkit, published by the Department for Science, Innovation and Technology on 8 September 2026, says the toolkit is relevant throughout an AI system's lifecycle, from use case identification to retirement. It also says ongoing risk management is needed during the lifecycle of an AI system, and that teams can use an existing risk register if it tracks enough information for risks, mitigations and owners to be observed. That is exactly the governance gap model retirement creates.

Many UK businesses already have procurement templates for data protection, cyber security, financial resilience and service continuity. AI model lifecycle questions should sit alongside those controls. Ask whether the supplier keeps a model inventory, whether it can show which customer workloads use a deprecated model, whether it has an evaluation method for recommended replacements, and whether customers can export logs or usage data to audit their own exposure. Ask how quickly the supplier informs customers when a partner model retires sooner than expected. Ask whether high-risk or regulated use cases receive a stronger migration process than low-risk internal drafting tools.

What this means in practice is simple. Do not approve an AI tool for repeated operational work until somebody has seen its change process. For a low-risk marketing assistant, that might be a short supplier note and an internal owner. For a customer-impacting claims, finance, recruitment or complaints workflow, it should include evidence packs, regression tests, documented acceptance criteria and a clear decision route. The model can change. The accountability cannot drift with it.

The hidden cost is migration work, not the model switch

The visible model switch may look small. A supplier changes one model ID, points you at a recommended replacement and updates the release notes. The hidden cost sits around it. Prompts may need rewriting. Structured outputs may need schema checks. Retrieval settings may need retuning. Human reviewers may need fresh guidance because the new model is more assertive, more cautious or less consistent in a specific domain. Evaluation scores may improve overall while a narrow task gets worse. If the workflow touches customers, the organisation may also need updated scripts, complaint handling notes and a record of why the change was accepted.

This is where finance leaders should pay attention. A supplier can offer attractive per-token pricing and still create migration cost if model changes are frequent, poorly signposted or badly tested. The procurement question is not only how much the model costs today. It is how much business effort is needed every time the underlying capability changes. For SMEs, even a two-day migration can be expensive if it pulls in the owner, the operations lead, an external developer and a front-line manager. For regulated firms, the evidence burden can be much higher.

A practical runbook should include commercial terms. Who pays for migration support when a supplier retires a model? Is continued access available for a defined period? Are dedicated capacity or extended support options available for critical workloads? OpenAI notes that, in some cases, developers may be able to provision dedicated capacity for continued access after a shutdown date. That will not apply to every buyer, but it proves the wider point: continuity options should be known before the deadline appears, not negotiated in a rush.

What to ask before signing the contract

The best time to inspect model retirement controls is before production rollout, not when a deprecation notice has already arrived. Start with five buyer questions. Which models power each material feature? What notice periods apply to each model class? How will we be told if a model becomes legacy, deprecated or retired? What replacement testing does the supplier perform before recommending migration? What evidence can we use to decide whether our own workflows are still acceptable?

Then turn those answers into a procurement artefact. Add a model lifecycle schedule to the supplier pack. Require a named supplier owner for lifecycle notifications. Require a customer-side owner for migration decisions. Ask for a sample retirement notice, a sample replacement recommendation and a sample test report. For higher-risk workflows, ask whether the supplier supports version pinning, staged rollout, sandbox testing, audit exports and rollback. If the supplier cannot answer, that does not automatically disqualify them, but it should affect where you let the tool operate first.

The common misconception is that this level of discipline slows adoption. In reality, it helps sensible adoption move faster. A business that knows how models change can approve more use cases with less fear because the controls are visible. A business that avoids the question often becomes more cautious later, after one unexpected change damages confidence. Treat model retirement like any other service continuity issue. It needs an owner, a timetable, evidence and a decision record. The firms that build this now will have fewer surprises as the AI market keeps moving.

Frequently Asked Questions

What is an AI model retirement runbook?

It is a practical document that explains what happens when an AI model used by a business becomes legacy, deprecated or retired. It should cover affected workflows, notice periods, replacement testing, owners, deadlines, rollback routes and evidence needed for approval.

Why does model retirement matter for UK SMEs?

Many SMEs are starting to depend on AI tools for repeated operational work. If the underlying model changes without testing, the tool may behave differently, lose features, cost more or stop working. A runbook reduces surprise and gives the business a clear response plan.

Should procurement ask for exact model IDs?

Yes, for any material workflow. You do not need model IDs for every casual drafting tool, but you should know the model family, provider and lifecycle policy behind customer-facing, finance, HR, legal, data-sensitive or business-critical systems.

Is a supplier notice period enough protection?

No. Notice gives you time, but it does not prove the replacement model works for your workflow. You still need dependency mapping, acceptance tests, owner sign-off and a migration plan.

What should be tested when moving to a replacement model?

Test the tasks that matter to the business: accuracy, refusal behaviour, structured outputs, tone, latency, cost, retrieval quality, tool use, escalation handling and edge cases. Use real examples where possible and keep the results as change evidence.

Who should own model retirement inside the business?

The business owner of the workflow should own the decision, supported by IT, data protection, procurement and the supplier. A technical team can run tests, but the accountable owner should decide whether the workflow remains acceptable.

Can managed AI platforms handle this for us?

They can help, and some will do a lot of the technical migration work. But you still need to know how the platform detects affected workloads, communicates changes, tests replacements and supports rollback or exception handling.

When should a runbook be required?

Require it before production use for any AI workflow that is repeated, customer-impacting, data-sensitive, regulated, costly to interrupt or hard to manually replace. For low-risk experiments, a lighter note may be enough.