Data Residency Has to Hold at Inference, Not Only at Rest

When we incorporated RENEDOR LLC in Dubai in 2024, every institution we spoke to asked the same question in different language. Where does the prompt go when a model runs?

They were not asking about object storage. They already knew how to keep a document in a region. They were asking whether a clause review, an incident summary, or a credit-file narrative would leave their residency perimeter the moment someone pressed run.

Most AI vendors answer with a storage map. Primary in region A, backups in region B, training opt-out in the contract. That is a disk policy. Inference is a network policy. If the gateway forwards the prompt to a provider endpoint in another jurisdiction, residency failed at the only moment that matters.

Invocation is the control point

Eridian evaluates residency on every request, before routing, before cache lookup, before the provider call.

{
  "residency": {
    "region": "ae-dubai",
    "pinning": "strict",
    "allowed_providers": ["eridian-hosted", "provider_ae_1"],
    "on_violation": "fail_closed"
  }
}

strict means the request does not leave ae-dubai for a "compatible" endpoint in another country. Soft pinning is a different product. We offer it only for non-regulated sandboxes, and we label it as such in the audit record. Production legal, ops, and risk projects default to fail closed.

A fail-closed residency miss returns error.code residency_pin_failed. The application sees a structured error, not a silently rerouted call. The record stores the requested region, the candidate routes, and the reason each candidate was rejected.

Cache is a residency object

Semantic cache is the easy way to accidentally export a prompt. A hit served from an index in the wrong region is still an export. Our cache partitions are region-scoped. A Dubai project cannot read a Hong Kong partition, even inside the same organization, unless an admin with dual control publishes a documented exception.

Exceptions are named, time-bounded, and visible on the project policy page. They are not comments in a ticket.

What we do not claim

We do not claim that a provider's marketing region names are equivalent to your charter. europe-west on a vendor console is not GDPR. me-central is not PDPL. We map provider endpoints to our own region objects and we refuse to route when the mapping is incomplete.

We also do not treat "the model is hosted by a US company" as an automatic fail if the inference endpoint, the keys, and the logs stay in the pinned region. Legal still reviews the subprocessors list. Engineering still has to prove the path.

How we started

The first production path we certified for a UAE institution was boring on purpose: one region, one project, one workflow template, dual control on policy edits, and a weekly export of invocation records to their SIEM. No multi-region failover. Failover without a residency rule is how you discover the gap during an outage.

Multi-region comes later, with pinning that survives failover. We will write that up when we have the operating evidence. For now the rule is simpler. If the charter says Dubai, the model call happens in Dubai, or it does not happen.