Most organisations do not decide to put their AI on the bottom rung of the Sovereignty Ladder. They accumulate their way there: a pilot on one API, a proof of concept on another, a team subscription that quietly became infrastructure. This note is the checklist we use to find out how exposed a stack actually is. You can run it on your own.

What "Exposed" means

We call a system Exposed when the models and the data both run in a third-party cloud under foreign jurisdiction. You rent the capability; the provider holds the keys, the logs, and the off-switch. Nothing about that is inherently reckless. For a throwaway prototype it is often the right call. It becomes a problem when the prototype turns into a dependency and nobody re-examines the terms it stands on.

The defining feature of an Exposed stack is not which vendor it uses. It is that the organisation could not answer, in writing, what would happen if that vendor changed its terms, its prices, or its mind.

The five checks we run

When we audit exposure during a Feasibility Sprint, five questions do most of the work. Each has a concrete test, not an opinion.

  • 1. Where do the weights live? If your provider deleted your account tonight, what would you still have tomorrow? If the answer is "our prompt templates and an invoice", the model layer is rented, not owned. Test: can anyone in your organisation produce the model artefacts and run inference without the vendor?
  • 2. Who holds the logs? Prompts, telemetry, and usage data often live only on the provider's side. That is your operational history, and in regulated industries it may be evidence you are required to keep. Test: request a full export of your own logs and see what actually comes back.
  • 3. Whose law applies? EU-region hosting is not the same as EU jurisdiction. What matters is who owns the provider and which courts can compel access to your data through that ownership. Test: trace the corporate chain of every processor in your DPA and note the first non-EU link.
  • 4. How much have the terms drifted? Pricing, rate limits, model deprecations, and behaviour changes are the rent going up. Test: list what changed in your provider's terms and models over the last twelve months, and what notice you got.
  • 5. What would an exit cost? Not in theory. In engineering time, against your actual integration surface. Test: has an exit ever been rehearsed, even on paper? If the answer is no, the honest exit estimate is "unknown", and unknown is the most expensive number in procurement.

What the checklist produces

Run honestly, the five checks produce two things: a defensible position on the Sovereignty Ladder, and a shortlist of dependencies ranked by blast radius. In our experience the surprise is rarely the headline model API. It is the quiet dependencies around it: the embedding service, the OCR step, the monitoring tool, each one an unexamined tenant in the middle of the pipeline.

We publish no aggregate figures on this yet. When we have run enough audits to report numbers that mean something, they will appear here with the method attached.

Climbing off the bottom rung

Two moves matter more than the rest. First, contain the data path: know exactly what leaves your perimeter, and stop what does not need to. Second, move the weights: open-weight models running on infrastructure you control turn the provider relationship from a dependency into a choice. EU hosting and a better DPA are worth having, but they move you one rung, not four. The order we recommend is inventory, contain, then re-platform, with the exit designed before it is needed.

Exposure is rarely a decision. It is an accumulation. The fix starts with an inventory, not a migration.

Want a quick estimate of where you stand? The two-minute self-check places you on the ladder. A two-week Sprint replaces the estimate with an audited answer.