Skip to content

10. Cross-tenant and cross-region

Right-to-be-forgotten is the most explicit form of the data subject's control. The next dimension is the platform's structural reality: many tenants, many regions, many regulatory regimes. The discipline of the previous chapters holds; the implementation has to handle the multi-dimensional reality.

A platform engineer at a Mumbai consumer-tech company is asked to support a new tenant in the EU. The existing tenants are all in India under DPDP; the new tenant requires GDPR compliance, EU residency, and the right to refuse any cross-border data transfer. The engineer maps the change. Some pieces are easy — the model gateway already supports regional routing. Some are harder — the audit log is in a single region; the analytics warehouse aggregates across tenants; the vector index is global. The team's instinct is to "add a column" for region everywhere. The deeper move is to recognise that regional segregation is structural, not a column. Within four months, the platform has region-local primary stores, region-local audit, regional gateways, and a global control plane that does not see user data. The new EU tenant onboards safely; the existing tenants are unaffected; the operating posture is now defensible across both regulatory regimes.

This chapter is the discipline that makes that re-architecture work. Cross-tenant isolation is one dimension; cross-region residency is another; both compose to multi-dimensional governance.

The two dimensions

Dimension Concern Defence
Cross-tenant Data of tenant A reachable by code acting for tenant B Tenant scope at the data layer; per-call enforcement (chapter 04)
Cross-region Data of tenant in jurisdiction X processed in jurisdiction Y Regional segregation; gateway-enforced privacy zones

The two interact. A multi-tenant platform with global stores faces both at once: tenant A's data in a global store could be touched by a region B request. Regional segregation per tenant is the structural answer.

Cross-tenant: the discipline

Chapter 04 covered tenant scope at the per-call level. This section is about ensuring the per-call discipline scales across the entire platform.

Tenant boundary at the data layer. Every record in every store carries the tenant identifier. Every query filters by tenant. Storage-level enforcement (row-level security or query-builder enforcement) ensures the filter cannot be omitted. Chapter 04's scope discipline applies here.

No tenant-spanning queries from agent paths. A query like "all customers across all tenants" should not be possible from any agent code path. Platform-admin tools (separate code path, separate credentials, separate audit) handle the exceptions.

Audit by tenant. The audit log's tenant_id field is queryable; cross-tenant queries can be detected and alarmed.

Eval and sample stores partitioned. Even the eval set and the sample store partition by tenant if the data is real. Cross-tenant samples are a leak surface.

Cross-region: the discipline

Three structural patterns.

Region-local stores. Tenant A in ap-south-1 has its data physically in ap-south-1. Replicas, derived stores (vector index, analytics warehouse, audit), all in the same region. Cross-region replication only occurs where the tenant's policy allows.

Regional gateways. The model gateway is deployed per region (02_ai_infrastructure/01 chapter 02). A tenant's calls are served by the regional gateway corresponding to their privacy zone. Cross-region calls within the gateway require explicit policy.

Global control plane, no user data. Some operations — routing policy, eval definitions, deprecation calendar, software deploys — need to be globally consistent. The control plane is a separate system holding only metadata. User data does not flow through the control plane.

The platform looks like:

+---------------- ap-south-1 ----------------+
|                                            |
|   Regional gateway (in-region tenants)    |
|   Primary database (Indian tenants)        |
|   Vector index (Indian tenants)            |
|   Audit log (Indian-region calls)          |
|   Sample store (Indian-region calls)       |
|                                            |
+--------------------------------------------+

+---------------- eu-west-1 -----------------+
|                                            |
|   Regional gateway (EU tenants)            |
|   Primary database (EU tenants)            |
|   Vector index (EU tenants)                |
|   Audit log (EU-region calls)              |
|   Sample store (EU-region calls)           |
|                                            |
+--------------------------------------------+

+---------------- Global plane --------------+
|                                            |
|   Routing policy / alias mapping           |
|   Eval definitions (synthetic data)        |
|   Deprecation calendar                     |
|   Cost reconciliation aggregates (no PII)  |
|   Platform team's dashboards               |
|                                            |
+--------------------------------------------+

User data lives in regions; coordination lives globally; the boundary is the type of data.

Operational implications of regional segregation

Engineers cannot directly query a region they are not in. A platform engineer in India debugging a problem for an EU tenant cannot read EU production data directly. The team operates with structured tools — break-glass access with audit, on-call escalations to in-region staff, queries that surface aggregates only.

Cross-region incidents need cross-region people. An incident in EU is responded to by EU on-call (or by India on-call with EU break-glass), not by India on-call freely reading EU data.

Deploys are per-region. A change to the agent platform's code deploys to each region. Coordination is the global plane's job; data is per-region.

Eval can run cross-region only on synthetic data. The eval framework that runs nightly against production may sample real production traffic — if so, the sample is regional, processed by regional infrastructure.

What flows globally, and what does not

Two categories.

Globally flowable.

  • Routing policy, alias mappings (no user data)
  • Eval definitions and synthetic data
  • Deprecation calendar
  • Software deploys
  • Cost summaries aggregated above any per-user identifier
  • Platform-team dashboards on aggregated metrics

Region-locked.

  • Customer data
  • Audit logs
  • Prompt and response samples
  • Embeddings derived from customer data
  • Conversation memory
  • Per-user metrics

If something is in the second category and needs cross-region visibility, the answer is aggregate first, then transfer — the aggregate has no per-user information; the transfer is fine. Direct cross-region transfer of region-locked data is the breach.

Some tenants explicitly allow cross-region processing — they have weighed the convenience against the regulatory exposure and chosen flexibility. The platform supports this with explicit consent recorded in the tenant configuration:

tenants:
  acme-corp:
    privacy_zone: in-region-only
    allow_cross_region_for: []

  flexible-globe:
    privacy_zone: any
    allow_cross_region_for: [model_inference, analytics, evals]
    consent_recorded_at: 2026-01-15
    consent_document: contract-clause-7.3

The consent is documented, dated, and tied to a contract clause. The platform's defaults remain strict; flexibility is opt-in.

The chapter-opening expansion

Returning to the platform that added a new EU tenant. The work that succeeded:

  • Built a regional eu-west-1 deployment of all per-tenant stores: primary, vector index, audit, sample.
  • Deployed a regional gateway in eu-west-1.
  • Migrated the platform's existing global stores into regional ones — Indian-tenant data in ap-south-1, EU-tenant data in eu-west-1.
  • Separated the global control plane from the data plane.
  • Updated the routing policy to enforce privacy zones (already in place from 02_ai_infrastructure/01 chapter 10).
  • Updated the audit query tools to span regions only where the requester has authority for both regions.

The work that did not succeed at first attempt:

  • The analytics warehouse was global; aggregated EU-tenant data was already in the same place as Indian-tenant data when the new tenant onboarded. Re-architected to region-local aggregates with global aggregates produced from anonymised inputs.
  • The eval framework sampled production traffic from a single global queue; the EU samples were briefly in a US region. Re-architected to per-region sample queues.

Each was a multi-week effort. The lesson: the regional discipline is structural; bolting it on later is more expensive than designing for it from the start.

Common mistakes

Adding a region column without partitioning. "We have a region field; we're done." If queries do not filter by region (and the storage does not enforce it), the field is metadata, not boundary.

Global derived stores. A global vector index aggregating across tenants is a cross-tenant leak surface, especially if the platform also serves multiple regions.

Cross-region audit aggregation by default. The audit log is region-local for governance; aggregated dashboards are produced from anonymised aggregates.

Engineers with cross-region read access by default. Convenient for debugging; corrosive for governance. The discipline is structured access via tools with audit.

Consent treated as informal. Tenants who allow cross-region need explicit, dated, contract-bound consent. Informal arrangements fail compliance review.

How cross-tenant and cross-region interact with the other surfaces

  • Scope (chapter 04) — tenant scope is enforced per call; region scope is enforced by gateway and storage.
  • Audit (chapter 07) — audit is region-local; per-tenant; queryable from authorised positions.
  • Retention (chapter 06) — jurisdiction drives retention; each region's policy applies.
  • RTBF (chapter 09) — erasure must reach all regions where the data was processed.
  • Model gateway (02_ai_infrastructure/01 chapter 10) — privacy zones are the routing enforcement.
  • Incident response (chapter 11) — incidents may be region-local or cross-region; response is by region with cross-region coordination.

Interview Q&A

Q1. The platform serves tenants in India and the EU on the same infrastructure. Where does this fail compliance? Several places. EU tenants' data may transit Indian regions for processing or storage; that is a cross-border transfer that may require SCCs or refusal under DPDP-GDPR alignment. The audit log if global, contains EU data in India. The vector index if shared, holds EU embeddings in India. The eval framework if global-sampled, has EU samples in India. Each is a structural issue; "shared infrastructure" is the failure mode. The fix is region-local stores per tenant's jurisdiction. Wrong-answer notes: "we'll add a region column" misses the structural reality.

Q2. The platform team needs to debug an issue for an EU tenant. The on-call is in India. What does the access look like? Structured. The Indian on-call does not have direct read access to EU production data. Either an EU on-call rotates in, or the Indian engineer uses a break-glass tool that aggregates the relevant information without exposing raw PII (e.g., "show me the error rate and the top failure modes for this tenant in the last hour"). All such accesses are audited. For deeper investigation, an EU on-call is paged or the case is escalated to engineering with appropriate jurisdictional staff. Wrong-answer notes: "we VPN in and read the logs" is the convenience answer that erodes the governance.

Q3. The platform's global vector index aggregates embeddings across all tenants. What do you do? Re-architect to per-region vector indexes (and within region, per-tenant if needed). The global vector index is a cross-tenant and cross-region leak surface. The migration: build per-region indexes; backfill the existing data into them per tenant's jurisdiction; route queries to the right index per the gateway's privacy zone; decommission the global index. This is multi-week work but addresses a real compliance gap. Wrong-answer notes: "add a region filter to queries" is filter-level, not structural; the index still holds the data globally.

Q4. A tenant explicitly opts in to cross-region processing. How does the platform represent this? Per-tenant configuration with consent fields: privacy_zone set to permit broader, an allow_cross_region_for list naming the specific operations, a consent_recorded_at timestamp, and a reference to the contract clause that captures the consent. The default is restrictive; the broader posture is opt-in with paper trail. The audit records the consent reference on every call that benefits from it. Wrong-answer notes: "they told us in an email" is informal; compliance review wants the explicit configuration and the contract reference.

What to do differently after reading this

  • Treat regional segregation as structural; design for it. Add region columns and enforce them at storage and gateway.
  • Make tenant scope the default. Cross-tenant queries from agent paths are forbidden.
  • Build a global control plane that holds no user data. Coordination above; data below.
  • Consent for cross-region is explicit, dated, and contract-bound.
  • Practice cross-region operations: how does the on-call investigate without direct read access? Build the tools.

Bridge. The discipline now spans classification, purpose, scope, PII, retention, audit, leak detection, RTBF, and multi-tenant multi-region structure. One last topic: what happens when, despite all of this, a leak occurs. The next chapter is incident response for data breaches. → 11-incident-response-data-breach.md