On June 12, 2026, Anthropic published a statement saying the US government had issued an export-control directive requiring it to suspend access to Fable 5 and Mythos 5 by foreign nationals.

The practical result, according to Anthropic, was abrupt: the company said it had to disable those models for all customers to ensure compliance.

Associated Press reported the same event as the US government's most significant step so far to restrict access to advanced AI models.

I am not writing this as a legal analysis of the directive. I am not close enough to the facts to know whether the national-security concern is strong, weak, temporary, misunderstood, or something else entirely.

But as an operational resilience issue, it is enormous.

Because if a tool can be turned off by a foreign government order with effectively no operational notice, then it is not just a software procurement question. It is a continuity question.

It is a board question.

It is a risk question.

It is a sovereignty question.

We have seen this pattern before

I am old enough to remember the encryption wars.

In the 1990s, strong encryption was not treated like ordinary commercial software. It sat inside export-control logic. There were limits, review processes, export-grade versions, and a long argument about whether code, mathematics, commerce, privacy, and national security could be separated cleanly.

That history matters because it reminds us of something uncomfortable: software can suddenly become strategic infrastructure.

Yesterday it is a tool.

Today it is a national-security concern.

Tomorrow your access path depends on policy decisions made in another country.

For a long time, a lot of companies treated US software as the default. The best tools came from there. The platform ecosystem came from there. The cloud stack came from there. The AI stack, in many cases, now comes from there.

That does not mean those tools are bad. Many of them are excellent.

But excellent is not the same as resilient.

The frightening part is the control plane

If an experimental tool disappears, it is annoying.

If a model you were using for a side project disappears, you find another model.

That is irritating, but survivable.

The problem comes when the tool is no longer a side tool.

What if it is part of your software delivery process?

What if it is part of your fraud process?

What if it is part of your customer support process?

What if it is part of your compliance monitoring?

What if it is built into your emergency response, planning, manufacturing, defence, healthcare, energy, water, transport, or telecoms workflow?

What if the agentic system you are using is not just answering questions, but helping coordinate work across teams?

Then the question is not, "Which AI model is best?"

The question is, "Can we still operate if this model, provider, region, account, API, licence, or jurisdiction is unavailable tomorrow morning?"

This is not anti-US

I want to be careful here.

This is not an anti-US argument.

Any state with serious strategic technology will eventually ask strategic questions about it. The US is doing that now. Europe will do it. The UK will do it. China already does it. Other countries will follow.

The lesson is not "never use American software."

The lesson is "do not confuse buying access with owning resilience."

A supplier can be good, honest, competent, and commercially committed to you, and still be legally unable to serve you tomorrow.

The supplier may not be the problem.

The jurisdiction may be the problem.

The concentration may be the problem.

Your dependency model may be the problem.

DORA already points in this direction

In financial services, this language is not new.

The EU's Digital Operational Resilience Act asks regulated financial entities to think seriously about ICT risk, third-party providers, continuity, recovery, testing, and the ability to withstand disruption.

That is the right mental model.

But this question is now bigger than banking.

AI is becoming part of operational work in councils, universities, SMEs, hospitals, consultancies, software teams, public bodies, manufacturers, and charities. Not always formally. Not always approved. But it is entering the work.

So the resilience question has to move with it.

When a model becomes part of how work is done, it should be treated like an ICT dependency, not like a clever website.

Infographic showing the operational resilience controls needed when access to a critical external AI or software service stops.
The resilience question is not whether the tool is impressive. It is whether the organisation can keep operating when access changes.

Sovereign AI is not a slogan

This is why sovereign AI matters.

Not as a flag-waving exercise.

Not as a claim that local models are always better.

Not as a fantasy that every country can instantly reproduce the frontier.

Sovereign AI matters because continuity matters.

If Europe is three or four months behind on a model but the tool is available, auditable, contractable, governable, and resilient inside European legal and operational boundaries, that may be better for many critical use cases than a more powerful tool that can disappear overnight.

For some work, the best model is the best model.

For operational work, the best model may be the one you can still use during a policy shock.

That is a different procurement test.

What I would ask on Monday morning

If I were looking at this from a board, risk, or operating seat, I would not start with panic.

I would start with a map.

  • Which AI tools and US software services are now part of real work?
  • Which ones are experimental, useful, important, critical, or control-plane dependencies?
  • Which providers, models, APIs, cloud regions, identity systems, and licences could stop access quickly?
  • Which dependencies sit under US jurisdiction, EU jurisdiction, UK jurisdiction, or another legal regime?
  • Which workflows stop if the service is unavailable for an hour, a day, a week, or permanently?
  • Which prompts, runbooks, evaluations, source files, and process knowledge are portable?
  • Which data cannot move to a fallback provider?
  • Which local, sovereign, open-source, or lower-capability backup route would keep the work moving?
  • Who is allowed to decide that degraded mode is good enough?
  • When did we last test the fallback?

That last question matters.

An untested fallback is often just a comfort blanket.

Procurement needs a new question

Most procurement questions still focus on cost, data protection, security, support, uptime, and commercial terms.

Those still matter.

But AI and strategic software need another question:

Who can legally stop this supplier from serving us?

Not technically.

Legally.

Politically.

Jurisdictionally.

That is not a comfortable question, because it moves beyond vendor management into geopolitics. But the work has moved there already.

The board does not need a twenty-page essay on export controls every time someone buys a software tool.

It does need a clear view of concentration risk.

If a critical process depends on one vendor, one country, one cloud, one model family, one account, one API key, and one policy environment, that is not resilience.

That is hope.

The practical control set

My practical control set would be simple.

First, classify AI use by criticality. A chat assistant is not the same as an agent that changes production systems.

Second, keep your working context portable. Prompts, guardrails, evaluation cases, source data descriptions, process maps, and decision rules should not live only inside one provider's harness.

Third, define degraded modes. What happens if the frontier model disappears and you have to use a smaller model, a local model, a human queue, or a slower manual process?

Fourth, test provider failure. Not theoretically. Actually switch off the tool in a controlled exercise and see what breaks.

Fifth, maintain strategic alternatives. That may be a European provider, a local model, an open-source option, a second cloud, or a human-reviewed fallback process.

Sixth, make the risk visible to the board. A dependency that can interrupt critical work should not be hidden inside a team subscription.

None of this says you cannot use the best US tools.

Use them.

But know what you are betting on.

The wake-up call

This is the wake-up call for me.

Not that the US is bad.

Not that Anthropic is bad.

Not that export controls are always wrong.

The wake-up call is that a modern organisation can find that a critical digital capability has moved from "available" to "not available" because of a decision outside the supplier, outside the customer, and outside the operating country.

That is exactly the kind of scenario operational resilience is meant to handle.

So yes, build with powerful tools.

Yes, use frontier models where they create value.

Yes, keep moving.

But if the tool matters, have a plan for the day it is turned off.

Because now we know that day is not theoretical.

Research notes