Configure data residency and provider no-retention

Regulated data carries two obligations that are easy to state and easy to violate. The first is residency: data that falls under a regional regime (personal data subject to the GDPR in the EU, or data covered by a US contractual commitment) must stay inside an approved geography for the whole of its journey, including the moment it reaches an upstream AI provider. The second is retention: even when a request stays in-region, the provider on the receiving end may log prompts and completions for abuse monitoring or model improvement unless it has been configured not to. A residency boundary that the gateway honours on the way out is undone if the provider retains the payload afterwards.

---

Tetrate Agent Router addresses both obligations at the layer where requests are routed. Residency is enforced by mapping a policy to provider entries that live only inside the approved region, so a request can never reach an out-of-region endpoint: not on the primary path, and not on any fallback or load-balanced alternative. No-retention is enforced one step further out, on the upstream provider itself, by applying whatever zero-data-retention or no-logging setting that provider supports and recording which setting was applied. This guide covers the operator-side work in the Admin Dashboard, the operator-facing application within the platform: selecting a residency region, binding it to routing so the boundary holds under failover, configuring upstream providers for no-retention where supported, verifying where a request was actually served, and documenting the result for audit.

The compliance artifacts that sit alongside this configuration (SOC 2, ISO 27001, and the provider data-processing agreements that make the no-retention claim contractually real) are catalogued separately in Compliance reference. This guide configures the runtime behaviour; that page records the evidence.

important

The exact no-retention or zero-data-retention setting differs by provider, and some providers gate it behind a specific contract tier or enterprise agreement. The setting names, the tiers that unlock them, and the contractual basis for each must be confirmed with the Tetrate field team and the customer's legal stakeholders before the configuration is treated as compliant. This guide describes the mechanism, not a guarantee that any particular provider offers it.

Persona: Platform operator working in the Admin Dashboard, in coordination with compliance and legal stakeholders who own the residency and retention requirements.

Estimated time: 30--60 minutes for a first pass against one region, depending on how many providers are in scope and how quickly provider-side retention settings can be confirmed.

When this guide applies

This guide is the right starting point in any of these situations:

Situation	Why this guide helps
A workload is bound to a single geography (for example EU-only or US-only)	Residency must be enforced at the routing layer so requests cannot reach an out-of-region endpoint
Regulated data must not be retained by upstream providers	Provider-side no-retention settings have to be applied and recorded, not assumed
A residency policy must survive provider failure	Fallback and load balancing must be constrained so failover never crosses the boundary
An auditor or legal stakeholder asks where requests are served and what the provider does with them	The verification and documentation steps produce the answer
Preparing a region-restricted evaluation environment	The settings applied in the POC need to be captured for the evaluation record

Outcomes

By the end of this guide:

• A data-residency region (for example US or EU) has been selected for the regulated workload.
• Routing for that workload reaches only provider entries inside the approved region, on the primary path and on every fallback and load-balanced alternative.
• Each upstream provider in scope has had its no-retention or zero-data-retention setting applied where the provider supports it, with the applied setting recorded.
• The region in which a sample request was served has been verified by inspection rather than assumption.
• The applied residency and retention settings are documented in a form an auditor can read.

Prerequisites

• Administrator access to the Admin Dashboard, typically the super_admin or provider_admin role. The role model is covered in Configure single sign-on.
• A written residency requirement from the compliance or legal stakeholder: the approved region or regions, and the data classes the requirement covers.
• Per-region provider entries already configured, one per subscription and region, each reporting a healthy connection. Laying out this structure is covered in Connect provider subscriptions across clouds and regions. This guide assumes those entries exist and builds the residency policy on top of them.
• The provider-side retention setting for each provider in scope, confirmed with the field and legal teams: the setting name, the contract tier that unlocks it, and whether it is in effect for the account being used.
• A baseline understanding of how the data plane reaches providers, covered in Architecture overview.

Step 1: capture the residency and retention requirement

Configuration that is not traceable to a stated requirement cannot be audited. The first step is to write the requirement down in a form the later steps can be checked against.

1. Record the approved region or regions for the workload: for example EU for a GDPR-bound workload, or US for a workload under a US-only commitment.
2. Record the data classes the requirement covers, so it is clear which routing configurations the policy must be applied to and which are out of scope.
3. Record the retention requirement separately from the residency requirement. The two are independent: a request can stay in-region and still be retained, and a no-retention provider can still serve from the wrong region. Both have to hold.
4. Identify, with the field and legal teams, which providers can satisfy each requirement. A provider with no in-region endpoint cannot serve a residency-bound workload; a provider with no no-retention setting cannot serve a no-retention workload, regardless of where it runs.

The output of this step is a short statement (region, data classes, retention expectation, and the providers eligible to serve under it) that drives the policy built in the steps that follow.

Step 2: select the residency region and its provider entries

Residency is enforced by routing a workload only to provider entries that live inside the approved region. The per-region entries created in Connect provider subscriptions across clouds and regions are the building blocks; this step selects the subset that sits inside the boundary.

1. Open Providers Management from the sidebar.
2. Identify the provider entries whose endpoint sits in the approved region. Where a naming convention encodes the region in the identifier (for example an entry named for the provider, cloud, and region together) the in-region entries are identifiable at a glance; otherwise the endpoint URL distinguishes them, since a region-specific endpoint carries its region in the host name.
3. Confirm each in-region entry reports a healthy status. A residency policy that points at an unhealthy entry has nowhere to send traffic and fails closed rather than crossing the boundary.
4. Record the exact set of entries that are inside the boundary. This set, and only this set, is what the workload's routing is permitted to reference.

The discipline here is exclusion as much as selection. An out-of-region entry for the same provider and the same logical model is a correct entry for some other workload, but it must not appear anywhere in the residency-bound workload's routing: not as a primary, not as a fallback, and not as a load-balancing member.

Step 3: enforce the boundary through routing

A region selected in the abstract enforces nothing. The boundary holds only when the workload's routing references in-region entries exclusively.

1. For the routing configuration that serves the regulated workload, map the logical model only to the in-region provider entries recorded in Step 2.
2. Exclude every out-of-region entry from the configuration, even where it serves the same logical model and would be a valid choice for an unconstrained workload.
3. Keep residency-bound routing separate from unconstrained routing. A single configuration that mixes in-region and out-of-region entries cannot guarantee residency, because the routing layer is free to choose any member. Separation is what makes the guarantee inspectable.

The composition of residency with fallback and load balancing is the part that most often goes wrong, and it has its own step below. The principle stated here carries forward to it: every backend the routing layer can reach for this workload, by any path, must sit inside the boundary.

Step 4: configure upstream providers for no-retention

Residency governs where a request is served; it says nothing about what the provider does with the payload afterwards. No-retention is configured on the provider side, and the platform's responsibility is to apply the setting where it exists and to record which setting was applied.

1. For each provider entry in the residency set, determine, with the field and legal teams, whether the provider offers a no-retention or zero-data-retention mode, and what unlocks it. Some providers expose it as an account-level or organisation-level setting; some require an enterprise agreement or a specific contract tier; some do not offer it at all.
2. Apply the setting through whichever surface the provider exposes it on. For some providers this is an account flag configured in the provider's own console; for others it is a contractual term that takes effect at the account level rather than a toggle. The platform routes to the provider endpoint; the retention posture of that endpoint is established on the provider side.
3. Record, for each provider, the exact setting that was applied, where it was applied, and the date. A claim of no-retention that cannot be traced to a named setting on a named account is not auditable.
4. Treat a provider that offers no no-retention mode as ineligible for the no-retention workload. It may still be a valid backend for workloads without a retention requirement, but it must not appear in the routing for one that has it, the same exclusion discipline as residency.

important

The presence of a no-retention setting in a provider's console is not the same as a contractual no-retention commitment. The setting names referenced here are illustrative; the binding ones for any given provider, and the agreement that makes them enforceable, must be confirmed with the field and legal teams and recorded in Compliance reference.

Step 5: compose residency with fallback and load balancing

Fallback and load balancing exist to keep a workload serving when a single backend degrades. For a residency-bound workload they introduce a specific hazard: a failover that reaches for a healthy backend in the wrong region would breach the boundary at the worst possible moment, silently, under load. The composition has to be constrained so that this cannot happen.

• Fallback walks an ordered list of backends when the primary fails. Every entry in that ordered list must sit inside the approved region. A fallback chain whose later entries point out of region will hold residency only until the primary fails, which is exactly when residency must not give way. Build the fallback chain from in-region entries only, and accept that if every in-region backend is unavailable the request fails rather than crossing the boundary. Failing closed is the correct behaviour for a residency requirement.
• Load balancing distributes requests across several backends for the same logical model. Every member of the load-balancing set must sit inside the approved region. A set that includes an out-of-region member will route some fraction of traffic across the boundary by design, not by accident. The regional load-balancing mechanics are covered in Load balance across regional deployments; the residency constraint on top of them is that the member set never extends past the boundary.

The rule that unifies both is the one stated in Step 3: every backend the routing layer can reach for this workload, by any path, must be in-region. Fallback and load balancing widen the set of reachable backends, so they widen the surface that has to be checked; they do not relax the constraint.

Step 6: verify where a request was served

A residency policy is only as trustworthy as the evidence that it held. Configuration can be correct in intent and wrong in effect; the verification step replaces assumption with an observed fact about where a sample request actually went.

1. Send a representative request through the residency-bound routing configuration.
2. Inspect the request record to confirm which provider entry served it. Request-level attribution, the provider entry and therefore the region that handled the request, is surfaced in the request logs; configuring and reading them is covered in Configuring request logs.
3. Confirm the serving entry is one of the in-region entries recorded in Step 2. An entry outside that set, even for the correct provider and model, is a residency breach and means the routing configuration still references an out-of-region backend somewhere.
4. Exercise the failover path deliberately where the environment allows it, for example by draining or disabling the primary in-region entry, and confirm the request is served by another in-region entry or fails, never by an out-of-region one. Verifying the primary path alone leaves the fallback path untested, and the fallback path is where residency is most likely to leak.

Verification by inspection, including a deliberate failover, is what turns a configured policy into a demonstrated one. For a POC evaluation, the served-region observation and the failover observation are the evidence that the residency criterion is met.

Step 7: document the applied settings for audit

The configuration is complete only when it is written down in a form a reviewer who was not present can follow. The documentation is the deliverable an auditor or legal stakeholder reads; the running configuration is what it describes.

• Record the residency policy: the approved region, the data classes it covers, and the exact set of in-region provider entries the workload's routing references.
• Record the no-retention posture per provider: the setting applied, where it was applied, the account or organisation it applies to, the date, and the contract basis confirmed with the legal team.
• Record the verification result: the region a sample request was served from, the failover observation, and the date the check was run.
• Note explicitly which providers were excluded from the workload and why: no in-region endpoint, no no-retention mode, or both. The exclusions are as much a part of the audit record as the inclusions, because they show the boundary was applied deliberately rather than by omission.

The retention and purge of the request logs that produced the verification evidence are themselves a compliance concern, covered in Manage log retention and purge. The compliance artifacts that back the no-retention claim contractually are catalogued in Compliance reference.

What to do next

• Manage log retention and purge: the request logs used to verify residency carry their own retention obligation; configure how long they are kept and how they are purged. See Manage log retention and purge.
• Review compliance artifacts: pair the runtime configuration with the SOC 2, ISO 27001, and data-processing-agreement evidence that backs it. See Compliance reference.
• Audit platform activity: once the residency policy is live, the audit and request-log surfaces are where ongoing adherence is observed. See Configuring request logs.

---

Where to go next

Manage log retention and purge

The request logs used to verify residency carry their own retention obligation.

Export audit and policy decisions to a SIEM

Deliver audit and decision records into the organisation's system of record.