On 12 June 2026, Anthropic launched two new frontier models. Three days later they were gone.
The US Commerce Department's Bureau of Industry and Security, under the signature of Commerce Secretary Howard Lutnick, ordered the company to suspend access to Claude Fable 5 and Mythos 5 for any foreign national, inside or outside the United States. Anthropic could not reliably screen users by nationality, so it disabled both models entirely. Access was restored on 30 June, after the company strengthened the models' safety guardrails, as reported by Fortune and CNN Business.
For eighteen days, every organisation that had built on those models had no model. Not a degraded model. No model.
If your first reaction is that your organisation is too small to be affected by frontier-model politics, consider a duller version of the same event: your provider retires the model your invoice-matching workflow depends on, gives you ninety days' notice, and the successor model behaves differently enough that your validation results no longer hold. That version happens on a schedule. It is happening now.
What is AI model deprecation?
AI model deprecation is the retirement of a specific model version by its provider, after which the model stops accepting requests. Every workflow, prompt, evaluation and control calibrated to that version must be migrated to a successor that behaves differently. It is a supplier-controlled end-of-life event, not a software upgrade you schedule.
The distinction that matters to a board is control. When you retire an internal system, you choose the date, the fallback and the test window.
When a model provider retires a model, you receive a notice. The date is theirs. The successor is theirs. The behavioural differences are undocumented, because nobody can fully document how one language model differs from another across your specific use cases.
This is why model deprecation belongs in the same risk category as a critical supplier changing its terms, not in the same category as a browser update.
Why have model lifespans collapsed to about six months?
Model lifespans have fallen from roughly eighteen months to about six. For models released from December 2025 onward, the interval between release and announced deprecation now runs approximately 181 to 213 days, according to published provider lifecycle calendars tracking Anthropic, OpenAI, Google and Amazon Bedrock.
The cause is competitive cadence. The rate of major model launches has roughly quadrupled since 2023, and providers do not want to maintain inference capacity for five generations at once.
Every retired model frees GPU capacity for the newest one. That is rational for the provider and expensive for the customer.
The practical consequence is arithmetic. If your model has a six-month life and your validation cycle for a governed use case takes eight weeks, you are re-validating roughly one third of the time you are in production.
Most enterprises have not budgeted for that. They budgeted for a project, not a replacement cycle.
What did the June 2026 Anthropic shutdown actually prove?
It proved that model availability can be removed by a third party who is not your vendor and has no contract with you. The Commerce Department order took two commercially available models offline globally within three days of launch, over a jailbreak concern, and no customer had standing to object or a contractual remedy.
Notice what the failure mode was not. It was not a technical outage, and no service-level agreement covered it.
It was a regulatory action against the supplier, which the supplier complied with by switching the product off for everyone, because partial compliance was not operationally possible.
The Center for Strategic and International Studies and TechPolicy.Press both framed the episode as a precedent rather than an anomaly. Once a government has demonstrated it can require a model to be withdrawn, that lever exists permanently.
For a Hong Kong enterprise, this adds a category of risk your business continuity plan almost certainly does not name: the geopolitical availability of a foreign software service you consume as an API.
Why is this a board-level risk rather than an IT problem?
It is a board-level risk because it concentrates operational dependency in a supplier you cannot audit, on a timetable you do not control, for processes that increasingly touch customers and regulated records. When a model disappears, the exposure is not a broken integration. It is a business process that has no operator.
Deloitte's 2026 State of AI in the Enterprise report found that 34% of surveyed organisations are now using AI to deeply transform, meaning they are reinventing core processes or creating new products rather than running side experiments.
Deep transformation is precisely what makes deprecation dangerous. A pilot that stops is an inconvenience.
A claims triage process, a client onboarding check or a month-end reconciliation that stops is an incident with a regulator attached.
The question a director should be able to ask, and receive an answer to, is simple. Which of our processes stop working if a named model is withdrawn next quarter, and how long would restoration take?
What is a model-dependency inventory?
A model-dependency inventory is a register mapping every production workflow to the specific model version it calls, the provider, the contractual continuity commitment, the business process affected, and the time required to re-validate on a successor. It is the single artefact that converts model deprecation from an unknown into a managed risk.
Most organisations discover, when they attempt this, that they cannot complete it. Teams adopted models independently. Nobody recorded versions.
A workable inventory records six fields for each workflow:
--- The exact model identifier in production, including version, not just the provider name
--- The business process it supports and whether that process is customer-facing or regulated
--- The provider's published deprecation date, or the absence of one
--- What the contract actually promises about availability and notice periods
--- The re-validation effort in person-days, measured rather than estimated
--- The named fallback model and whether it has ever been tested against real traffic
The last field is where most inventories fail honestly. Naming a fallback is easy. Having run it is rare.
How do you build a model continuity framework?
A model continuity framework has four layers: abstraction, so workflows call a routing layer rather than a provider directly; portability, so prompts and evaluations are versioned as assets; a tested fallback for every governed workflow; and a re-validation budget approved in advance rather than requested during an incident.
Start with abstraction. If application code contains a hard-coded provider endpoint, every migration becomes an engineering project. Routing through an intermediate layer turns it into a configuration change. Our guide to what an AI gateway is and why enterprises now need one covers that control point in detail.
Portability is the discipline of treating prompts, retrieval configurations and evaluation sets as versioned assets with owners, not as text pasted into a codebase by whoever built the feature.
The tested fallback is the layer organisations skip. A fallback that has never processed production traffic is a hypothesis, not a control.
The re-validation budget is a governance decision, not a technical one. If a six-month model life is now the planning assumption, then two re-validation cycles per year per governed workflow is the baseline cost of running AI in production. Approving that annually is cheaper than approving it under pressure.
What do Hong Kong regulators expect on model retirement?
Hong Kong regulators already treat model lifecycle as a supervised activity. The HKMA's Supervisory Policy Manual module SB-1 on Model Risk Management, revised in January 2024, covers model development, validation, ongoing monitoring and retirement as a continuous cycle rather than a one-off approval.
The HKMA also issued a circular in late May and early June 2026 reminding authorised institutions to review the adequacy of their cyber risk management, incident response, recovery testing and third-party resilience arrangements against evolving AI-enabled risks.
Third-party resilience is the phrase that matters here. A model provider is a third party, and its retirement schedule is a resilience question.
In March 2026, the HKMA, the Securities and Futures Commission, the Insurance Authority and the Mandatory Provident Fund Schemes Authority jointly launched the GenA.I. Sandbox++ initiative across financial sectors, signalling that supervisory attention to generative AI is coordinated rather than siloed.
Outside financial services, the Personal Data (Privacy) Ordinance still applies to whatever personal data your workflows send to a model, and a change of model is a change of data processor arrangement worth recording. Our overview of AI and PDPO compliance checks for Hong Kong enterprises sets out what that record should contain.
What goes wrong when organisations ignore model continuity?
Five failure patterns recur, and all of them are visible before the deprecation notice arrives:
--- Silent version drift. Teams call a provider alias rather than a pinned version, the alias moves to a new model, and output quality changes with no deployment and no ticket.
--- Undocumented prompt coupling. Prompts tuned over months against one model's behaviour degrade on a successor, and nobody kept the tuning rationale.
--- Evaluation debt. The original accuracy benchmark was run once at launch and never automated, so there is nothing to re-run against the replacement.
--- Single-provider concentration. Every governed workflow sits with one vendor, so a single regulatory or commercial event affects the whole portfolio at once.
--- Budget surprise. Migration cost was never in the operating plan, so the re-validation competes with new initiatives and loses.
Each of these is cheap to fix in advance and expensive to fix in the ninety days between notice and shutdown.
What should you do in the next 30 days?
Three actions produce most of the protection. Build the model-dependency inventory even if it is incomplete, pin every production call to an explicit model version rather than a moving alias, and run one governed workflow end to end on a fallback model to find out what actually breaks.
The inventory is the priority because you cannot manage what you have not listed. An incomplete register that names your five most critical workflows is worth more than a complete one delivered next year.
Version pinning is a one-line change per integration and eliminates the entire category of silent drift.
The fallback test is the one that changes minds. Teams consistently discover that the successor model needs different prompt structure, produces different formatting and fails different edge cases. Finding that out in a controlled test is a Tuesday. Finding it out during a shutdown is a board paper.
None of this requires a large programme. It requires someone to own the question and a decision to fund the answer. If you want a structured starting point, an assessment of where your organisation actually stands is usually faster than an internal audit, and the framework in our guide to build versus buy for enterprise AI is a useful companion when the fallback question turns into a sourcing question.
The strategic takeaway
Model deprecation is not a technology problem that engineering will absorb quietly. It is a supplier concentration risk with a six-month clock, a regulatory dimension your business continuity plan has not met, and an operating cost that nobody put in the budget.
The organisations that will handle the next Fable 5 moment well are not the ones with the best model. They are the ones who can answer, in a single page, which processes depend on which models and what happens if those models stop.
That page takes a fortnight to produce and it is the cheapest insurance in your AI portfolio.
Technology cycles have a way of teaching the same lesson repeatedly, and the lesson is always about dependency. We understand AI. We understand you. With UD by your side, AI never feels cold.
Reviewed by the UD enterprise AI team.
Take the next step
A model-dependency inventory starts with an honest picture of where your organisation stands today. We'll walk you through every step, from AI readiness assessment to fallback design, migration planning and ongoing governance, backed by 28 years of serving Hong Kong enterprises.
