Skip to content

Model Residency

Model residency tells you where each model processes prompt and response data, and whether that stays inside the data boundary you require. It is meant for teams with a compliance need, for example EU customers who must confirm their data is processed inside the EU.

The gateway reads the residency of every configured model from the config you already write (no extra credentials, no calls to the providers) and shows the result in the LLM Providers page of the admin portal:

  • a residency label per model (e.g. "EU (multi-region)", "Sweden region", "Global"),
  • a compliance verdict per model and per provider (compliant / not compliant / unknown).

Turning it on

Residency is off until you set a preferred boundary in the residency section of the config file:

residency:
  preferred: eu
  • preferred: the data boundary models are checked against. eu is the only value for now. Leave the whole residency section out (or set no preferred) to turn the compliance check off.

When the check is off, the Providers page still shows each model's residency label, but no compliant / not-compliant verdict, because there is nothing to check against.

How a model is classified

The gateway works out two things for each model:

  1. Scope — how wide the processing can range:
    • single region — one region, tied to one country;
    • multi-region — a geographic zone with no single country (e.g. an EU zone);
    • global — can leave any boundary;
    • unknown — cannot be placed.
  2. Boundary — the region/zone the processing is confined to (EU, US, APAC, or a single country).

The signal it reads depends on the provider, and comes from fields you set on the model in the llms config:

Provider (source) Field(s) that drive residency How it is read
AzureOpenAI, AzureAnthropic, AzureCohere, AzureMistral sku + region sku gives the scope (Global* = global, DataZone* = multi-region, Standard/ProvisionedManaged = single region, DeveloperTier = unknown); region gives the country.
AwsBedrock* deployment_name prefix (+ region) The eu. / us. / apac. / global. prefix is the primary signal; a model with no prefix is single-region, placed by its region.
GoogleVertexAI url (the locations/<X>/ segment) global = global; eu / us = multi-region; a regional location (e.g. europe-west1) = single region.

Any other source has no residency data in config and shows as unknown.

Azure needs region and sku

Azure models carry residency only if you set both region (e.g. swedencentral) and sku (e.g. GlobalStandard) on the model. Both fields are optional and existing configs keep working without them: the app starts as before and such a model simply shows as unknown residency (never a wrong "compliant").

To find the region and sku a deployment uses, see Microsoft's model region availability list.

Note that a model with no sku, or a region not in the map, also logs a WARNING at startup (see the fail-safe note below). This happens even when no preferred boundary is set, so add the fields or expect these warnings if you have Azure models and do not use the feature.

Example:

llms:
  azure-sweden-gpt-5:
    deployment_name: gpt-5
    type: AzureOpenAIText
    source: AzureOpenAI
    url: "https://<resource>.openai.azure.com"
    api_key: "secret:bss-llm-gateway-model-sweden"
    cost_profile: azure-gpt-5
    api_version: "2025-04-01-preview"
    region: swedencentral      # residency: country
    sku: DataZoneStandard      # residency: scope

AWS reads the deployment prefix

For AWS Bedrock the deployment_name prefix wins over the region. eu.anthropic... is an EU multi-region profile even if the region names a single country; the region is kept only to name that country for information.

  "aws-eu-central-1-anthropic.claude-sonnet-4-6":
    deployment_name: "eu.anthropic.claude-sonnet-4-6"   # eu. -> EU multi-region
    type: AwsBedrockText
    source: AwsBedrockAnthropic
    api_key: "secret:bss-llm-gateway-model-aws-bedrock"
    cost_profile: "anthropic.claude-sonnet-4-6"
    region: eu-central-1

Google reads the url location

For Google Vertex the locations/<X>/ segment of the url is the single source of truth. No extra field is needed.

  google-eu-gemini-2.5-flash:
    deployment_name: google/gemini-2.5-flash
    source: GoogleVertexAI
    # locations/europe-west1 -> Belgium (single EU region)
    url: "https://europe-west1-aiplatform.googleapis.com/v1/projects/<project>/locations/europe-west1/endpoints/openapi"
    cost_profile: google-gemini-2.5-flash

The EU boundary

The eu boundary is the set of EU member states plus the EEA, matched by ISO country code. It is a fixed, hand-maintained list.

  • Inside: EU members and Norway (EEA).
  • Outside (read as not compliant): Switzerland (CH, EFTA but not EEA) and the United Kingdom (GB, post-Brexit), even though both are GDPR-adequate. Their data leaves the EU boundary, so the label says so.

Verdict rules

With a preferred boundary set, each model gets one of three verdicts:

  • Compliant — the model's boundary matches the preferred one (e.g. an EU zone or an EU country region when preferred: eu).
  • Not compliant (warning) — the model can leave the boundary. This covers global scope and any known boundary or country outside the preferred one (US, GB, ...). A known non-EU location reads as a warning, not "unknown".
  • Unknown — the gateway cannot place the model: an unknown sku, a region or location not in its maps, a source with no residency data, or preferred not set.

Fail safe

A model the gateway cannot classify never reads as compliant. It degrades to unknown and the app logs a startup warning naming the model, so a config typo (an unmapped region, a missing sku, a url with no location) shows up without breaking startup.

Provider-level verdict

Providers roll their models up into one verdict:

  • Compliant only when the provider has models and all of them are compliant;
  • Not compliant if any model is a warning (the provider can leak data);
  • Unknown otherwise (no models, or a mix that includes unknown).

Adding new regions

The region/location maps and the EU country list are maintained inside the gateway (llmgw/proxy/services/residency). A new deployment region or Vertex location that is not in the maps yet makes its models show as unknown until it is added. The startup warning is the signal that a region needs adding. The EU list should also be reviewed from time to time.