The Premium on Optionality

A model provider a government can switch off is a supplier you do not control. Businesses have always built on things that can be pulled out from under them, and they have learned, more or less, to live with it. A cloud region goes dark for an afternoon, or a sole supplier raises its price in the week you need it most. These are known risks, and they have known mitigations. The model layer is the newest entry on that list, and the strangest, because it risks the very intelligence the work now runs on. Intelligence doesn’t just improve processes, its fallback is people. The old answers do not quite fit, and governance is still finding its footing.

The response has two halves, and they are the familiar ones. Leadership decides how much exposure to carry and where data may sit; engineering makes substitution cheap enough that those decisions hold. Neither half is free. Optionality is bought the way insurance is bought: you pay in the quiet years and are grateful only on the bad day. Set the price on purpose, against what a loss would cost, rather than meeting it for the first time in an outage.

What leadership owns

Six decisions belong to leadership, not to the platform team that inherits them by default when no one above will own them. The build teams implement; they do not get to decide.

1. Name it as concentration risk. One model provider is a critical-supplier dependence: a government can remove the supplier overnight, with no commercial cause and no force-majeure cover. Regulated finance already treats this kind of concentration as a named risk under DORA.1 Map the controls to a published scheme, the NIST AI framework or ISO/IEC 42001, rather than inventing one.23
2. Map where AI is load-bearing. List the products, processes and decisions that depend on a model. Mark which depend on a single provider, and which on one specific model version. Keep the list as a register with an owner, reviewed, not a one-off audit.
3. Set a data-jurisdiction policy. Decide what may leave EU jurisdiction and what may not. A US-controlled provider can be compelled to produce data wherever it is held, whatever the transfer rules say at the time.4 Sovereignty is becoming a procurement rule too: the EU’s proposed cloud act would keep the least sovereign providers out of the most sensitive contracts.5
4. Write down the risk appetite. Decide which capabilities must have a tested fallback. Set the most exposure you will carry to any one provider. Fix the contract terms that follow. Left unwritten, every team re-argues the trade-off, and the default wins. The default is the incumbent US provider.
5. Buy optionality at contract time. It is cheapest before you sign: portability and exit, data-residency, notice before a model is retired, no lock-in to proprietary formats or model names. Know which EU AI Act duties apply to your use, and take advice; the timeline for the EU AI Act is still moving.6
6. Give it an owner, and rehearse the loss. Name an executive owner. Put the risk on the register and the board agenda. Run the drill: the main provider gone for a week, then a quarter, then for good.

One call stays with the board. A values-aligned vendor is not a hedge against the government it answers to. The diversification that counts is across jurisdiction, not brand. A single directive or regulation out of Washington reaches every US vendor at once, whatever their brand promises.

All of this costs money, but that cost is a valuable indicator. Price it per capability, by what the loss of that capability would do. Carry too little and an outage sets the price for you. Carry too much and you self-host systems no one would miss.

What engineering builds

The guardrails set the requirements; the architecture has to honour them, or they are theatre. Treat the model provider as a runtime dependency you do not control, like a payment processor that can fail and take your checkout down. Leaving the frontier outright is off the table if that creates a gap in your business capabilities. Instead look to what’s achievable: make switching cheap, and keep the frontier for the few tasks that cannot be done without it.

A ladder, cheapest first:

1. Stop hard-wiring. Choose models from configuration, by capability, never by a hardcoded name or version. In June, code with a model name baked in needed a redeploy to recover; code that read the name from config changed one value.7
2. Put a gateway in front of every call. One interface for routing, failover, budgets, observability and logging.
3. Run more than one provider in earnest. Keep an open-weight fallback exercised and a provider-neutral test harness, so a switch is something you have already tried and are comfortable with.
4. Split planning from execution. Let the strongest model plan, and hand the steps to a cheaper, replaceable model. The frontier dependency shrinks to where it earns its cost.
5. Move execution into Europe or onto open weights, hosted in the EU or self-hosted. This is the first rung that buys sovereignty. The earlier rungs buy resilience.
6. Walk the planning tier down as open reasoning models close the gap, keeping a frontier US model only for the hardest tasks.

The second rung has a catch. A gateway helps only if you run it and know where it processes your data. The popular hosted routers are US services: they ease switching while adding a US intermediary, and most do not keep data in Europe by default.8 The sovereignty-aligned choice is a gateway that you host yourself, or one operated in the EU. Even then, a router buys substitutability, not sovereignty. It routes to whatever models you point it at, which means sovereignty comes only when those are European or open.9 The gateway is the steering; the models and the compute are the engine.

Whether to host your own is a question of volume and sensitivity. Below modest scale, a hosted API is cheaper. Past a few hundred million tokens a month, self-hosting wins, and it is the one option with no foreign-government exposure at all.10 Decide by blast radius. For each capability, ask what breaks if the model goes down during peak usage. The answer sorts your systems into those that need a fallback and those that can tolerate the risk.

Coupling the two

Leadership sets the appetite, the data policy and the exit terms. Engineering builds the substitutability and the fallback that meet them. Taken separately, they fail in familiar ways: governance writes policies the architecture cannot honour, or engineering builds resilience no one will pay to keep. Together, with the register naming the risks and the ladder mitigating them, a provider being switched off becomes a contained incident.

None of this ends the dependence on the frontier while capabilities are expanding rapidly. It changes who controls the dependence, and how much warning a withdrawal has to give before it turns into a crisis. You’re paying to build a buffer of days or weeks in which a switch-off is an inconvenience and not a catastrophe. Recent US actions showed what it costs to have bought none. The work is to pay it on purpose, quietly, before the bill arrives on its own terms.

---

Sourcing note: the references below name published instruments as anchors for in-house governance, not as compliance instructions or legal advice. I’m not a lawyer, and I don’t work for you.

References

1. The Digital Operational Resilience Act (DORA) applied to EU financial entities from 17 January 2025. It treats reliance on a limited number of ICT providers as a concentration risk to be identified and managed, and puts the most systemically important providers under direct EU oversight; the European Supervisory Authorities designated the first “critical ICT third-party providers” on 18 November 2025. EIOPA / ESAs https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en ; PwC Legal on the first list https://legal.pwc.de/en/news/articles/esas-publish-first-list-of-critical-ict-third-party-providers-under-dora . The frontier-model concentration and the figure of more than 70% of EU cloud in three US firms are from the first piece in this series, Thinking on Borrowed Compute. ↩

2. NIST AI Risk Management Framework (AI RMF 1.0, January 2023) and its Generative AI Profile (NIST-AI-600-1, 26 July 2024), which maps the framework’s Govern / Map / Measure / Manage functions to twelve generative-AI risk categories. Voluntary, but increasingly referenced in US federal procurement. https://www.nist.gov/itl/ai-risk-management-framework ; https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf ↩

3. ISO/IEC 42001

   , the first international AI management-system standard and the first that is certifiable; a Plan-Do-Check-Act cycle covering risk management, impact assessment, system lifecycle and third-party supplier oversight. https://www.iso.org/standard/42001 ↩

4. The US CLOUD Act and Section 702 of FISA let US authorities compel a US-controlled provider to produce data regardless of where it is stored. The separate transfer-adequacy question is unsettled: the EU General Court upheld the EU-US Data Privacy Framework on 3 September 2025 (dismissing the Latombe challenge), and that decision is under appeal at the Court of Justice (Case C-703/25 P, no hearing date as of mid-2026), which has struck down two such frameworks before. The Framework governs commercial transfer adequacy and does not limit CLOUD Act or FISA 702 demands. IAPP https://iapp.org/news/a/european-general-court-dismisses-latombe-challenge-upholds-eu-us-data-privacy-framework . (Transfer law is moving; confirm the current position before relying on specifics.) ↩

5. The EU’s proposed Cloud and AI Development Act would sort cloud providers into sovereignty tiers, require sovereignty risk assessments before sensitive public contracts, and keep the least sovereign providers out of the most sensitive tiers. Part of the 3 June 2026 Tech Sovereignty Package; proposed, not enacted. European Commission; TechPolicy.Press https://www.techpolicy.press/eu-unveils-sweeping-tech-sovereignty-push-balancing-autonomy-with-openness/ ↩

6. EU AI Act phased timeline as of mid-2026: prohibited practices in force since 2 February 2025; general-purpose-model obligations since 2 August 2025; the Digital Omnibus on AI (political agreement 7 May 2026) deferred the high-risk obligations, moving Annex III use-based systems to 2 December 2027 and Annex I product-embedded systems to 2 August 2028, and postponed the national regulatory-sandbox requirement to August 2027. Consilium https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/ ; European Commission AI Act page https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai . (Which obligations bind a given use is a matter for legal advice; the timeline is still being amended.) ↩

7. The June 2026 shutdown: a US export-control directive suspended Anthropic’s frontier models for foreign nationals and the company disabled them for all users, leaving applications that had hardcoded a model identifier unable to recover without a code change. Full account in the first piece, Thinking on Borrowed Compute. Anthropic https://www.anthropic.com/news/fable-mythos-access ↩

8. Gateways and routers sit on two axes: run-it-yourself versus software-as-a-service, and data jurisdiction. Self-hostable open source includes LiteLLM, Bifrost (Apache-2.0), TensorZero, llmgateway.io, Kong and Helicone. Hosted US SaaS includes OpenRouter (not EU-resident by default; EU in-region routing an enterprise add-on), Martian, Not Diamond, Inworld and Portkey. EU-hosted options include EUrouter, Cortecs, Eden AI, Orq.ai, ShareAI and Requesty’s EU gateway. These are examples, not endorsements; most descriptions are vendor-sourced and statuses change, so check each tool’s own documentation and, for residency, its data-processing terms and sub-processor list. Eden AI https://www.edenai.co/post/top-european-alternatives-to-openrouter ; OpenRouter sovereign-AI docs https://openrouter.ai/docs/guides/features/sovereign-ai ↩

9. A router buys substitutability, not sovereignty. A distinction worth keeping: infrastructure routing answers “which provider serves this model,” intelligence routing answers “which model should handle this prompt”; the second is better owned in your own planner-and-worker logic than handed to a third party. Morph, LLM gateway explainer. https://www.morphllm.com/llm-gateway ↩

10. Cost crossover is directional, from a single analyst write-up: below roughly 50M tokens a month, hosted-API pricing tends to win; above roughly 500M, self-hosting tends to win; the sovereignty-critical crossover sits around 180M tokens a month. EU and self-host inference options include Scaleway, OVHcloud’s sovereign tier, Mistral La Plateforme, Nebius, IONOS and Gcore, with vLLM or Ollama for self-hosting. Self-hosting in the EU or on your own hardware is the only architecture with no foreign-government data exposure, given the CLOUD Act and FISA 702 reach over US-controlled providers. Gosign https://www.gosign.de/en/magazine/self-hosted-open-source-ai-2026/ ; OVHcloud https://blog.ovhcloud.com/reference-architecture-deploy-mistral-large-model-in-sovereign-environment-ovhcloud/ (Treat the TCO figures as directional.) ↩