Your AI Model Can Be Switched Off by Decree: Build the Failover Plan

On 12 June 2026, an AI provider cut off access to two of its models for its entire customer base, within hours, on orders from the US government. Thirteen days later, the White House asked another provider to delay the release of its next model and to approve customer access one account at a time. In two weeks, a model's availability became a decision made outside your contract and outside your jurisdiction. For a regulated European company, this is no longer an innovation question: it is a supply risk on a critical building block.

Two decisions, two weeks, one signal

The first case is an export control. Anthropic received a directive ordering it to suspend all access to Fable 5 and Mythos 5 "by any foreign national," inside and outside the United States. Net effect: the company had to switch both models off for every customer to stay compliant, the stated reason being a possible circumvention of its safeguards. Anthropic is challenging the proportionality of the measure and is working to restore access (CNBC, Fortune, 12-13 June 2026).

The second case is an imposed sequencing. The US administration asked OpenAI to limit the rollout of its next model to a short list of approved partners, with access cleared "customer by customer" during a security review phase (CNN, Axios, 25 June 2026). A first of its kind: a government decides upfront who gets a model, and when.

The common thread is not cybersecurity. It is that access to the model no longer depends on its technical quality or your contractual service level, but on a third-party authority that can interrupt or ration it with no meaningful notice.

This is not a procurement issue, it is a concentration risk

A COMEX's reflexive reading is reassuring: "if one provider fails, we will renegotiate or switch models." It is wrong the moment a production workflow has been welded to a single provider. When your prompts, your safeguards, your data format and your business code call a proprietary SDK directly, switching models is not a contract amendment: it is a project running several months, during which the service stays down.

And this risk already has a name in the regulation you apply. DORA, in force for European financial entities since 17 January 2025, explicitly addresses concentration risk on a critical ICT provider (Article 29) and requires, for any critical or important function, a documented and credible exit strategy along with data portability (EUR-Lex, Regulation 2022/2554). A single foundation model sitting under a critical process ticks exactly that box.

The AI Act, for its part, does not protect you here. It governs how you use the model, not whether a foreign government keeps it switched on. Its transparency obligations (Article 50) still apply from 2 August 2026, and those on high-risk standalone systems (Annex III) have been pushed back to 2 December 2027 by the Digital Omnibus (Council of the EU, agreement of 7 May 2026). None of these deadlines answers the question "what do you do on Tuesday if the model disappears?" That is also the core of the case Arthur Mensch (Mistral AI) made before the French National Assembly on 12 May 2026: Europe has, in his view, "two years" to build its AI infrastructure or risk becoming "a vassal state." At company level, sovereignty is not a slogan; it is an architecture choice.

A model you cannot replace within a few days is not an asset; it is a dependency.

The model failover plan: four disciplines

The model failover plan is the document, and the architecture, that lets you move from one provider to another without interrupting a critical function or rewriting your governance. Four disciplines make it up.

1. An abstraction layer. No business code calls a provider's SDK directly; everything goes through a single internal interface. Sierra, the agent platform cited by LangChain, runs several models in parallel and routes each task to whichever one handles it best. This discipline is not just a performance tweak: it is what makes replacement possible.
2. A second provider qualified per critical workflow. Qualified, not merely "available": it has passed your own evaluation sets on your own use cases. For sovereignty-sensitive uses, the fallback option includes a European model.
3. Portable safeguards and prompts. Externalize prompts, escalation rules and evaluation sets away from the provider. Otherwise, switching models means rewriting your controls, and the failover becomes impossible within the timeframe of an incident.
4. Contractual reversibility. An exit clause and data portability written into the contract, as DORA already requires for your other critical providers.

Mistakes to avoid

• Confusing cloud redundancy with model redundancy. Deploying the same model across several regions protects nothing when it is access to the model, not the infrastructure, that is cut.
• Welding safeguards to the provider. Non-portable prompts and rules turn a few-day failover into a multi-week rewrite.
• Treating the failover as a last-minute purchase. Qualifying a second provider on the night of the incident is too late; qualification takes weeks.
• Never exercising it. A plan never rehearsed under real conditions is an assumption, not a capability.

The same Friday night

Two payment institutions built the same fraud-alert triage assistant on the same model. On Friday night, access is suspended. The first has an abstraction layer, a European fallback provider already qualified and a replayable evaluation set: it fails the workflow over in two days and documents the operation for its regulator. The second welded its prompts and safeguards to the original provider: it freezes the workflow, reverts to manual processing and opens an incident. Same technology, opposite resilience. The difference comes down to a failover plan prepared in advance.

Observable markers for your next COMEX

Four questions, and their evidence:

1. How many days, measured during an exercise, to fail a critical workflow over to another model? If the answer is "unknown," you have a dependency.
2. What percentage of your critical workflows has a second provider genuinely qualified on your use cases?
3. Are your prompts, safeguards and evaluation sets detached from the provider and replayable on another model?
4. Do your contracts include a reversibility clause and data portability, in the DORA sense?

The goal is not to have the best model. It is to be able to switch models faster than an incident lasts. That criterion, measured and exercised every quarter, is what separates a steerable AI function from a gamble.

RegRadar by TokenShift helps COMEX teams map their critical AI dependencies and turn a reversibility obligation into an executable failover plan.

Sources

• Anthropic / suspension of Fable 5 and Mythos 5, CNBC and Fortune, 12-13 June 2026.
• White House / OpenAI, sequenced rollout of the next model, CNN and Axios, 25 June 2026.
• DORA, Regulation (EU) 2022/2554, Articles 28-29, EUR-Lex; in force since 17 January 2025.
• EU AI Act, Digital Omnibus, Council of the EU, agreement of 7 May 2026; transparency (Art. 50) on 2 August 2026; high-risk (Annex III) on 2 December 2027.
• Arthur Mensch (Mistral AI), hearing before the French National Assembly, 12 May 2026.
• LangChain / Sierra (Zack Reneau-Wedeen), multi-model architecture, June 2026.