When the Model Became a Critical Dependency

The model had become critical while the controls still treated it as a convenience.

TL;DR

• The Fable 5 and Mythos 5 shutdown turned model availability into an operational-resilience problem, not only an AI-safety or Washington policy story.
• For regulated enterprises outside the United States, the phrase "foreign nationals" is not abstract. It can include staff, customers, and the institutions themselves.
• Data residency never solved sovereignty by itself. The control point matters more than the physical location of the endpoint.
• DORA, FINMA outsourcing rules, Swiss operational-resilience expectations, and cloud exit guidance already contain the governance machinery needed to handle this risk.
• The missing step is applying that machinery to the model layer itself.
• Model portability is harder than cloud portability because model behavior, prompts, evaluations, tool definitions, retention terms, and lineage do not move cleanly between providers.
• A regulator-defensible posture does not require pretending the dependency can always be eliminated. It requires identifying it, testing fallback, documenting residual risk, and owning the control point honestly.

Opening observation

On the evening of 12 June 2026, a frontier model that had been generally available for a matter of days stopped answering.

Anthropic disabled Fable 5 and its Mythos-class sibling worldwide after receiving an export-control directive from the US government. The directive, as Anthropic described it, applied to foreign nationals, including foreign national Anthropic employees. Because the company could not implement that restriction selectively across every account and application surface, the cleanest way to comply was to withdraw the models from everyone. Anthropic disputed the underlying finding, said the capability in question was already available from other deployed models, and said it was working to restore access.

Most of the commentary read this as an AI-safety story, or a Washington story, or an export-control story. Those readings are not wrong.

They are also not the most useful reading for anyone who runs regulated infrastructure for a living.

For regulated enterprises, the important fact is plainer and more uncomfortable. A capability that some production systems had begun to depend on was removed globally by an instruction issued in a jurisdiction those systems did not sit in, aimed explicitly at a class of users many enterprises outside the United States belong to.

From Zürich, "foreign nationals" are not an abstraction.

They are us, our staff, and depending on the interpretation, our customers.

I have watched this shape of problem arrive before, one layer further down the stack.

The resemblance is the point.

Residency was never the same thing as sovereignty

The financial sector already learned, slowly and at some expense, that where data physically sits and whose law governs it are different questions. Only the second question decides what happens when an authority comes asking.

Schrems II and the long argument over transfer mechanisms settled the principle for European data protection. The US CLOUD Act stated the American position more directly: a US-controlled provider can be compelled through US legal process to produce data within its possession, custody, or control, even when the data is stored outside the United States. That sits in obvious tension with the European instinct behind GDPR Article 48, which limits transfers or disclosures to foreign authorities outside recognised legal channels.

A data centre in Frankfurt does not automatically move the control point to Frankfurt.

The wave of sovereign-cloud offerings that followed - EU data boundaries, in-region controls, local operating entities, local support models - limited operational access in genuinely useful ways. But those measures did not always alter the parent's obligations under its home law. The industry eventually settled on "sovereignty washing" for the distance between geographical residency and genuine jurisdictional control.

The durable lesson is that sovereignty is a control-point question, not a geography question.

The thing worth locating is not only the byte.

It is the authority that can compel, alter, or withdraw the service, and the jurisdiction that authority answers to.

The Fable 5 weekend restated that lesson at the model layer, in public, in compressed time. Residency was largely irrelevant to it. There was no European endpoint to fall back to and no in-region configuration that would have kept the model answering, because the control point was not in Europe.

A single directive in one capital reached every customer on the planet.

If you had treated the model as a sovereign-neutral utility - something that simply existed, like electricity - the weekend was an education.

This is not new risk. It is newly visible risk.

The mistake would be to file this under geopolitics and move on, because the obligation to manage it is already written into the regimes most regulated firms operate under.

It simply has not been pointed clearly enough at the model.

For firms in scope of the EU's Digital Operational Resilience Act, and for Swiss groups with EU operations or EU clients, the relevant machinery lives in the ICT third-party-risk framework. DORA requires firms to understand critical ICT dependencies, assess concentration risk, maintain registers of information, and put exit strategies and transition arrangements around ICT services supporting critical or important functions.

The Swiss framework arrives at a similar destination by a different road. FINMA Circular 2018/3 governs outsourcing for banks and insurers. FINMA Circular 2023/1 on operational risks and resilience introduced stronger expectations around critical data, business-critical functions, board-level ownership, and disruption tolerances. The Swiss Bankers Association Cloud Guidelines are especially direct on exit: firms should be able to bring outsourced functions and client data back in-house or transfer them to another provider, with realistic termination periods and usable export formats.

Read those obligations with the Fable 5 event in mind and the gap becomes obvious.

We have spent years hardening this discipline for cloud and infrastructure.

Almost nobody has yet drawn the model itself onto the same map.

The large language model that now sits behind a credit-decision assistant, a client-communication drafter, a code-modernisation pipeline, or a transaction-monitoring triage tool has often entered production as a rapid-innovation feature. It may be federated through an enterprise gateway. It may be procured under a platform agreement. It may even have an approval record.

But in many organizations it is still governed as a feature.

That is no longer enough.

It has quietly become a third-party dependency supporting functions the business increasingly cannot perform without it.

The directive that pulled Fable 5 was, in the vocabulary of regulations we already answer to, an unplanned and externally imposed termination of a critical service with no notice and no committed restoration date.

That is the textbook scenario exit-strategy requirements were written for.

The novelty is that the service was a model.

Why the model layer is harder than the cloud layer

It would be convenient if extending third-party discipline upward were a matter of copying the cloud playbook one shelf higher.

It is not.

The differences are where the operational friction lives.

A database has a schema and an export. When you plan to leave a cloud provider, the exit is painful but legible. You know what the data is, what format it lands in, and roughly how long the migration takes.

A model has no equivalent clean boundary.

The behavior you depend on is an emergent property of weights you cannot extract, coupled tightly to the prompts, system instructions, tool definitions, routing logic, and evaluation thresholds your teams have tuned against one specific model's quirks.

Move to a substitute and the contracts and data may port cleanly while the behavior does not.

The prompts that were load-bearing on one model degrade quietly on another, and you discover the coupling only in production.

Lineage, in the sense a regulator means it, is also harder. Reconstructing why a given output occurred months later, when the model that produced it has since been deprecated or withdrawn, is a problem most governance functions have not yet had to solve at scale.

There are sharper edges still.

Frontier models carry retirement and deprecation cadences measured in quarters, not the multi-year horizons we assume for infrastructure. Fallback is rarely free. Dropping from a top-tier model to a smaller one to keep a service alive is a capability cliff, not graceful degradation. Whether a degraded model remains fit for a regulated purpose is a question the risk function has to answer in advance, not improvise during an outage.

The Fable 5 launch also carried a governance wrinkle that deserves more than a footnote.

Anthropic's documentation for Mythos-class models states that prompts and outputs are retained for 30 days for trust and safety purposes, and that some flagged material can be retained for longer under the policy. Anthropic says the data is not used for training and describes access controls and deletion practices. The security rationale is defensible on its face.

It is still a material trust-boundary change.

For a firm bound by banking secrecy, FADP, GDPR, outsourcing expectations, or client confidentiality, that is not a setting to discover after deployment.

This is worth dwelling on because it is tempting to file the whole episode under European sovereignty anxiety. The most instructive counterexample came from inside the United States. Reporting from The Verge said Microsoft restricted internal employee use of Claude Fable 5 while legal teams assessed the data-retention terms, even as the model remained available to external customers through other channels.

When a sophisticated enterprise software company blocks a model for its own staff over a data-governance term while still making it commercially available elsewhere, the conclusion is hard to avoid.

The incompatibility is not a regional preference.

It is a baseline control question that mature buyers will not waive casually.

None of this disqualifies the model as a class of tool.

All of it is the kind of thing you want understood and written down before a supervisor asks, rather than after a directive forces the question.

What portability discipline looks like one layer up

The honest response is unglamorous, which is usually how you can tell it is the right one.

It is not a manifesto about leaving American AI.

It is the slow extension of disciplines this sector already knows how to run.

The first move is to name the dependency. A model that supports a critical or important function belongs in the same register and under the same scrutiny as the cloud platform it runs on. It should be classified by criticality, assessed for concentration, and carry an exit strategy someone has actually rehearsed.

The supervisory community has already converged on the view that a right-to-exit clause nobody could execute is exactly what an examiner probes. An untested exit is not a credible one.

The equivalent at the model layer is a fallback path exercised against real workloads, with the capability difference measured rather than assumed.

Not a paragraph in a contract.

Not a spare model name in a slide.

A tested fallback.

The architectural enabler is the one good engineers reach for instinctively and good governance should now insist on: structural decoupling of the model from the rest of the estate, so that it becomes a substitutable reasoning engine rather than a load-bearing wall.

In practice, that means keeping the model out of the experience layer entirely. The application talks to a standardized, semantically described interface. The data the model reasons over arrives from source and runtime systems through a stable semantic model rather than becoming entangled with one vendor's API. The choice of which model sits behind that interface becomes a routing decision expressed in metadata, not a dependency wired into core platform logic.

When a model goes dark - withdrawn, deprecated, restricted, or degraded - the request routes to a fallback through the same interface, and the platform survives the loss without a rewrite.

This is the anti-corruption layer of older architecture vocabulary, applied to a component that happens to think.

The portability that decoupling buys is only real if it has been exercised. That means prompts and evaluations maintained as first-class portable assets rather than artifacts welded to one vendor's behavior. It means a regression suite that can quickly show how a candidate replacement performs on the cases that matter to the business. It also means confronting a cost teams consistently underestimate.

A credible fallback is not a single prompt set with a spare model named beside it.

It is a second pipeline, maintained and evaluated in parallel with the first.

Because prompt behavior does not transfer cleanly between models, the instructions that drive the secondary model have to be written, tuned, and regression-tested continuously, in peacetime. The one moment your developers cannot be improvising fallback prompts is the moment the primary model has just gone away.

That standing expense is the real price of portability discipline at this layer.

It belongs in the business case rather than arriving as a surprise during the first incident.

Sovereignty is not self-sufficiency

Where this gets genuinely difficult is the temptation to mistake sovereignty for self-sufficiency.

You cannot simply self-host a frontier model because the board would like the dependency to disappear. European and open-weight alternatives are real, improving, and strategically important. But they do not erase the capability, infrastructure, energy, tooling, and ecosystem gap that exists around the largest frontier-model providers.

Pretending otherwise in a board paper is its own kind of risk.

The mature posture is not independence, which may be unavailable for some workloads.

It is diversification and graceful degradation.

That means knowing which functions could fall back to a sovereign or open alternative at reduced capability, which could tolerate a temporary outage, which could move to another global provider, and which genuinely cannot run without a specific frontier model.

The last category is uncomfortable, but it is better to say it plainly.

DORA-style operational-resilience thinking makes room for this honesty. Where no near-term substitute for a critical dependency exists, the requirement is not to invent one by assertion. It is to document the constraint truthfully and demonstrate active management of the residual risk.

A regulator-defensible architecture is not one that claims to have eliminated the dependency.

It is one that can show, on demand, that the dependency was identified, its control point located, its failure modes rehearsed, and its irreducible residue accepted with eyes open.

What I would do Monday morning

If I were reviewing regulated AI adoption after the Fable 5 shutdown, I would start with the model register.

Which models support critical or important functions?

Which provider controls them?

Which jurisdiction can compel or restrict them?

Which model versions are embedded in production workflows, prompts, evaluations, retrieval systems, agents, and tool chains?

Then I would review fallback reality rather than fallback intention. I would ask whether the organization has run a model-substitution exercise against real workloads in the last quarter, whether the degraded output remains fit for the regulated purpose, whether prompts and evaluations are portable assets, and whether the business knows what capability is lost when the fallback path is used.

I would then look at data retention and trust boundaries. Which prompts and outputs leave the enterprise boundary? Which can be retained by the provider? Which are used for safety review, abuse detection, quality improvement, or training? Which terms differ across model classes or delivery channels? Which of those differences would matter under banking secrecy, FADP, GDPR, outsourcing expectations, or client confidentiality?

Finally, I would ask who owns the model dependency.

Not who owns the application.

Not who owns the vendor contract.

Who owns the model as a critical dependency?

That owner should be able to explain the control point, the exit path, the fallback test, the residual risk, and the evidence trail to a supervisor without needing three weeks of reconstruction.

The bill for an unowned dependency

What the Fable 5 weekend exposed was less a flaw in any one model than a gap in how the rest of us had been governing it.

The model had become critical while the controls still treated it as a convenience.

The directive simply presented the invoice for that mismatch ahead of schedule.

The firms that felt the disruption least were probably not the ones with a sovereign frontier model of their own. Almost nobody has that. They were the ones that had already classified the dependency, kept the model layer decoupled, and could route around a single provider's absence while they worked out what it meant.

The structural lesson is that the model layer now needs an owner in the same sense the cloud relationship has one.

A function must be accountable for treating the model as a named third-party dependency rather than as shadow infrastructure that entered through a side door. Someone has to hold the register entry, maintain the tested fallback, understand where the trust boundary actually runs, and explain the arrangement to a supervisor in language grounded in the regimes we already answer to.

That work existed before 12 June.

The shutdown only made it impossible to keep deferring.

None of this argues against using the best available models, including American ones, for the work they do well.

It argues for using them the way this sector has learned, painfully, to use every other critical service it does not control: with the control point identified, the exit rehearsed, and the residual risk written down honestly enough to survive the scrutiny of someone whose job is to assume it will fail.