Where your data actually goes

There is a sentence that appears on almost every sovereign-AI website, ours included at one point: "your data stays in region X".

It is a good sentence. Buyers want it, procurement teams look for it, and it closes deals. It is also, for most vendors saying it, not quite true — and the gap between what it promises and what the architecture delivers is where the unpleasant discoveries live.

We have taken it off our own pages. This is why.

The claim and the architecture rarely match

Running a model request involves more moving parts than a residency claim usually admits. Take the honest inventory for a gateway like ours:

• Inference happens at the model provider. If your request is served by a third-party model, the prompt goes to that provider, in whatever region they serve it from. No amount of UK hosting on our side changes that.
• Retry safety needs storage. Our gateway holds real response bodies for 24 hours so that a retried request cannot double-charge you or produce two different answers. That store is encrypted and tenant-scoped, and it sits in the node's region.
• A gateway in one region is a gateway in one region. We run in the UK. Where else we run, if anywhere, is on the products page rather than fixed here.

Given those three facts, the strongest sentence we can write and stand behind is: "UK-hosted gateway, with each model's processing region disclosed". It is longer, less quotable, and does not fit a badge. It has the advantage of being true.

When a tenant can land on a node in their own region, the stronger claim closes by construction — and we will make it then, not before.

"Global" is a caveat, never a tick

A detail that matters more than it sounds. In our model catalogue, a model whose processing region is unclassified is marked global.

That word means no residency guarantee is being made. It does not mean "available everywhere", and it must never render as a green tick in a UI. We have written that constraint into the code that generates our own pages, because the failure mode is so easy: a designer sees a status field, picks an icon set, and a caveat becomes a reassurance without anyone deciding to lie.

If you are evaluating any vendor's residency story, ask what their equivalent of "global" is, and then ask to see how it is displayed.

Curated lists beat clever rules

The obvious way to enforce residency is a per-request policy: inspect the request, look up the model's region, allow or deny. It demos beautifully.

We do not do that, deliberately. Instead an administrator curates a Model Access List — an explicit set of approved models — and the gateway enforces that list.

The reason is failure direction. An automatic rule fails open: a new model appears in the catalogue, the rule has no opinion about it, and it silently becomes available. A curated list fails closed: a model nobody approved is a model nobody can call.

The honest cost is that residency compliance becomes an administrative act rather than a switch. Somebody has to review models and approve them. We think that is the correct trade, and we would rather explain it than pretend the clever version is safe.

What our systems structurally cannot see

Policy commitments about data handling are worth roughly what the enforcement behind them is worth. "We don't log prompts" is a sentence, and sentences drift as teams change.

So the parts of our platform that record what happened — telemetry, metrics, the audit chain, the usage ledger — are typed so that prompt content cannot enter them. Not a policy someone could forget: a structure that will not compile if you try. A test in our continuous integration scans every column of every table for a canary string, so the guarantee is checked on every change rather than asserted once in a data-handling policy.

That is the difference we would ask you to look for in any vendor's answer. Do you log prompts? invites a promise. What would have to be true for you to be unable to? invites an architecture.

When you need the opposite

There is a case this cuts against, and it is worth being straight about rather than letting the principle sound purer than it is.

Some organisations are required to keep a record of exactly what was asked, what was answered, and why the agent did what it did. A regulated firm reviewing conduct. An investigation into how a decision was reached. A supervisor who has to demonstrate that an outcome was reasonable rather than assert it. For them, a platform that structurally cannot retain content is not a feature — it is a gap they will have to fill somewhere else, probably worse.

Both things can be true at once, and the whole question is where the content lives:

• e21 core does not collect it. The platform's own records — telemetry, metering, the audit chain, the usage ledger — stay content-free for every customer at every tier. That is the structural guarantee above, and it does not move.
• An interaction record belongs at the enterprise layer, for organisations whose obligations require one. Separate, explicit, and configured by the customer — because it is their record for their regulator, not something the platform accumulates on the side because it might come in useful. It runs hosted by us, or inside your own boundary in the e21 OS private cloud variant, which is the answer for organisations that cannot have content of that kind hosted anywhere but their own estate.

Keeping those apart is the entire point. A single system that does both is a system where "we do not log prompts" is a setting rather than a property — and a setting is only as good as the current configuration and whoever last changed it. Once the platform's own telemetry is capable of holding content, you are back to trusting a promise, which is where this post started.

So the honest formulation is not "we never retain what you asked". It is: the platform cannot, and where your obligations require that someone does, that is a decision you make explicitly, at a layer built for it, with the record belonging to you.

The exceptions, enumerated

Every system has content somewhere. The difference is whether the list is published or discovered. Ours:

1. Idempotency replay store — real response bodies, 24 hours, encrypted, tenant-scoped, on by default. This is the one that makes the strong residency claim false, and it is the reason we do not make it.
2. Semantic caching — not shipped. When it ships it will be opt-in, TTL-bound, per-tenant encrypted and purgeable.
3. Payload-replay debugging — not shipped. Off by default, and enabling it will itself be audit-logged.
4. Enterprise interaction records — content, deliberately, where an organisation's obligations require a record of what was asked, what was answered and why. Enterprise layer only, never in core, and never on by default. Hosted by us, or inside your own boundary in the e21 OS private cloud variant — which is the option for organisations that cannot have this hosted at all.

A tenant in strict zero-data-retention mode turns all of it off, and routes only to provider endpoints that have attested they do not retain or train on content. That mode is available today.

The point

We are not going to imply more certification than we hold while a market rewards implying it. Where that stands is set out plainly on the FAQ and kept current — not softened there, and not frozen here.

What we can offer instead is a description of our own system precise enough that you could catch us out. That is a deliberately uncomfortable position to take, and it is the only one that survives contact with a buyer who actually reads.

If a vendor's residency claim is shorter and more confident than ours, that may be because their architecture is better. It is worth finding out which.