What if your AI model goes dark? Business continuity for AI dependencies
Treat the AI model as a critical third-party dependency that can become unavailable or less capable without notice, for reasons outside your contract. Map which workflows stop if it goes dark, name a fallback model or manual process for each, test the switch, and cover availability in your outsourcing and third-party risk framework.
Key takeaways
- Model risk is not only accuracy risk. A model can also be unavailable.
- In June 2026, Anthropic suspended access to its two most capable models for nineteen days to comply with US export controls.
- Capability can shrink without disappearing, for example when a provider reduces a context window.
- Export controls and government orders are now operational inputs for AI users.
- Most firms have a BCP for the data centre. Very few have one for the model.
Has a frontier AI model really gone dark?
Yes. On 12 June 2026, Anthropic suspended access to its two most capable models to comply with US export controls. Access came back on 1 July. Nineteen days.
Nothing was wrong with the model. Nobody breached a contract. No invoice went unpaid. The capability stopped being available, for reasons that had nothing to do with the customer, the vendor relationship or anyone's risk register.
What should this change in AI governance?
- Model risk isn't only accuracy risk. Most AI governance frameworks treat the model as something that might be wrong. It is also something that might not be there. Those need different controls.
- Capability can shrink without disappearing. In June 2026 a Singapore lab cut a model's context window from 1 million tokens to 256,000. Nothing was withdrawn. Workflows built on the larger number quietly stopped fitting.
- Your dependency is geopolitical. Export controls, national security reviews and compute rationing now feed into your operations, whether or not they appear in your third-party risk assessment.
How do you plan for an AI model outage?
- Map the dependency. List every workflow that calls an external model, and mark which ones are business-critical.
- Name the fallback. For each critical workflow, name an alternative model or a manual process.
- Build the switch before you need it. An abstraction layer lets you change providers by configuration, not by rebuilding.
- Test it. Run a continuity exercise the way you would for a data centre failure. Time the switch and check output quality.
- Write it into contracts and frameworks. Cover availability, notice and suspension in vendor terms, and add model unavailability to your outsourcing and third-party risk framework.
What is the honest test?
If the model you rely on went dark tomorrow morning for nineteen days, what stops? And who in your organisation already knows the answer?
Frequently asked questions
Does an AI model outage count as a third-party risk event?
Yes. If a business process depends on an external model, loss of that model is a third-party service disruption. Financial institutions should check how their outsourcing and third-party risk framework treats a critical provider becoming unavailable by government order.
How do you build a fallback for an AI model?
Route requests through an abstraction layer that can switch providers, keep a tested alternative model for critical workflows, and document a manual process for anything that cannot switch.
What should an AI continuity test check?
Which workflows stop, how long the switch to a fallback takes, whether output quality on the fallback is acceptable, and who decides to switch.
This article is general information, not legal advice. It reflects the position as at the date of publication. A plain-text version for AI assistants is at /blog/ai-model-outage-business-continuity.md.