Skip to main content
When an auditor or a privacy regime asks “where does this evidence live?”, they mean the artifact — the signed PDF, CSV, or JSON your compliance report renders into. OrcaRouter’s ai data residency setting answers exactly that question: it declares the region your signed compliance reports are stored and served under, stamps every report you generate with it, and withholds any report whose stamped region no longer matches. This is a property of the report artifact, not a claim about where inference runs. If you came here looking to pin model traffic to a region, that is an upstream routing decision and lives elsewhere — read section 4 before you rely on it.

​
1. What ai data residency controls

One workspace declares one region. From that point on:
  • every compliance report you generate is stamped with the declared region;
  • the rendered artifact is stored region-partitioned;
  • a cross-region read is withheld — a report stamped eu will not download while the workspace declares us;
  • the report’s data-flows disclosure states plainly that upstream model providers (subprocessors) process request data in their own regions.
The region is one of six codes:
CodeRegion
usUnited States
euEuropean Union (EEA)
ukUnited Kingdom
apAsia-Pacific
cnChina
globalGlobal / no restriction
Leaving residency unset is also valid — an unstamped report carries no residency claim and is served without a region check.
Reading the current region is open to any workspace Member (it is part of the free, browse-only compliance surface). Changing it requires workspace Admin — unlike installing a pack or going live, setting residency is not separately paywalled. See Plan gating.

​
2. Set the region (one concrete flow)

Set residency from the console under Compliance → Settings, signed in as a workspace Admin. The console drives the management route for you using your session — this is a UserAuth route, never a relay (sk-orca-…) key: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
The response echoes the region you set. To read the current value and the selectable options (for a settings dropdown), the matching read route is open to Members: 
GET /api/compliance/residency
Authorization: Bearer <your console session>

{
  "region": "eu",
  "options": [
    { "code": "us", "label": "United States" },
    { "code": "eu", "label": "European Union (EEA)" },
    { "code": "uk", "label": "United Kingdom" },
    { "code": "ap", "label": "Asia-Pacific" },
    { "code": "cn", "label": "China" },
    { "code": "global", "label": "Global / no restriction" }
  ]
}
Set residency once, up front, before you generate the reports your auditor will rely on. The region a report carries is fixed at generation time — see the next section for what happens when you change it later.

​
3. Changing the region after reports exist

Residency is enforced at download time against the workspace’s current declared region. A report stamped under the region that was declared when it was generated will only serve while the workspace still declares that same region. So if you generate reports under us, then switch the workspace to eu, those earlier us-stamped reports stop downloading — the gateway withholds them rather than serve an artifact under a residency claim it can no longer satisfy. The fix is to regenerate the report under the new region.
Changing residency does not retroactively re-stamp existing reports. After a region change, regenerate any report you still need to download. This is intentional: an artifact is never re-labelled with a region it was not produced under. The dedicated Cross-region reads page covers multi-region programs in depth.

​
4. What residency is NOT

This is the distinction most teams get wrong, so it gets its own section.
Setting region: eu does not route your model traffic through EU infrastructure. It governs where the evidence artifact lives, not where the model runs. Upstream providers process request data in their own regions; the report discloses that flow rather than constraining it.
Residency stamps compliance reports. Request-log storage and retention are governed separately — see Retention for the 30-day default and 180-day server-clamped maximum.
A declared region plus the report’s subprocessor disclosure is evidence you can hand an auditor — it is not a legal data-processing agreement. Pair it with your own contractual controls.
If a regulation genuinely requires inference to stay in-region, that is an upstream routing decision distinct from where your evidence is stored. Be precise with auditors about which guarantee you are making.

​
5. Where this fits

Residency is one knob in the broader compliance flow — install a pack, observe it, go live, generate a signed report, and store that report under a declared region.

Compliance overview

The full loop — install, observe, enforce, and ship signed evidence.

Cross-region reads

Why a report stamped one region won’t serve under another, and how to run a multi-region program.

Signed report

How each report gets its SHA-256 hash and Ed25519 signature.

Plan gating

Which compliance actions are free to read and which need a paid Admin.
For the boundary between what the gateway guarantees and what stays yours, the Shared responsibility map puts residency in context: the gateway controls its own evidence artifacts; your subprocessor and infrastructure decisions remain yours.