Every AI component I run is a foreign-vendor dependency, and a vendor can stop answering for reasons unrelated to the terms I agreed to. A 2026 US export-control directive made that concrete for EU users. My reflex was to rank dependencies by data exposure and buy privacy controls. What reset my sovereign and local AI priorities was a different question.
TL;DR
Rank every AI dependency by one question: does it keep working if the vendor’s servers go dark to me? That grade, not a jurisdiction flag on a map, sets migration priority.
The decision, and the two criteria
The decision is which dependencies to migrate first, and the criteria come before any option. The first, cutoff survival, asks whether a component keeps working when its vendor is cut off. The second rules out the obvious answer: service cutoff is a distinct axis from data exposure, so exposure controls are not cutoff controls.
Cutoff is a failure class, not a privacy problem
Service cutoff went unclassified in my stack, so it drove no migration priority. The privacy controls I already ran sit on the other axis. Zero data retention, store:false, and end-to-end encryption reduce exposure, not cutoff.
The class is live. A 2026 US export-control directive forced the Claude Fable/Mythos foreign-user blockade, a foreign vendor cutting service to EU users.
Two neighboring migrations run beside this one: leaving a foreign cloud for mail, docs, and calendar starts from the same motive and follows its own method . The security boundary is a separate register, set by what an automation account can reach on the box .
Two ways to rank the same migration
With the criteria set, two approaches can order the same migration work.
- A jurisdiction flag on a dependency map. Read where each vendor is based and treat an EU-jurisdiction vendor as safe. The EU’s sovereign-AI push gives it substance, with Mistral‘s sovereign-stack partnerships as the case.
- The cutoff-survival test. Ask one question of every component: does it keep working if the vendor’s servers go dark to me? It costs a per-component interrogation and answers the criteria’s failure.
The comparison
The two approaches agree on a component that runs offline, and separate on a live managed service:
| The component | Jurisdiction flag | Cutoff-survival test |
|---|---|---|
| Runs offline, self-hosted, or local-first | Safe if the vendor is EU | PASS |
| A live service from an EU-jurisdiction vendor | Safe: EU flag | FAIL: live vendor connection |
| A live service from a US-jurisdiction vendor | Unsafe: US flag | FAIL: live vendor connection |
A flag reads a vendor’s location; the test reads what the component needs to run. The middle row is where the flag goes wrong: an EU jurisdiction does not keep a service reachable once the vendor withdraws.
What the test chose, and why
The cutoff-survival test won. Local-first or self-hosted removes the cutoff vector regardless of vendor jurisdiction, so the test, not the flag, sets the migration sequence. Every component is graded PASS (offline, self-hosted, or local-first) or FAIL (needs a live vendor cloud connection); that grade orders the work.
An EU-jurisdiction vendor is still a remote chokepoint, outside my control and able to withdraw. Local-first routing tiers are the architecture that removes the vector , and on-device inference is sovereignty at its strongest, because the model never leaves the machine .
What I gave up, and when the map is right
The test is not a mandate to self-host everything, and my own reversal is the case. I planned to self-host a LiteLLM gateway on my virtual private server (VPS), chosen over Bifrost. That comparison weighed only markup: 0% self-hosted against a managed router’s 5 to 5.5% fee. At the moment of the evaluation, my actual model spend was about $2 to $10/month, so the fee difference is cents at that volume.
The second cost does not. A self-maintained, self-patched service is a new single point of failure on the box that also serves a revenue site. So I abandoned the gateway for a managed EU-jurisdiction router, Cortecs, with OpenRouter kept wired in as a permanent fallback. Cortecs won over EUrouter on maturity, 4 to 5 years against under 18 months, and over Eden AI on the near-identical fee, 5% against 5.5%, noise at this volume. The switch is parked, not live, until the model-tier work reaches the VPS.
Two vectors close the class beyond one country: Chinese top-tier models, open-weight included, may later be restricted on CN-sovereignty grounds, and US-EU tariff retaliation on cross-border GPU compute routing is a lower-confidence vector. The single EU model as the default workhorse is its own decision , and separating spec, build, and quality assurance in an agent team is a different register.
This stack is mine to operate, and its trade-offs are on the about page. If this is the shape of your problem, let’s talk.