TeNova

Docs / Multi-Cloud Data Boundary

Multi-Cloud Data Boundary Guide

How the SWT3 AI Witness Protocol addresses EU data sovereignty requirements for organizations running AI across multiple cloud providers and jurisdictions.

Audience: Data Protection Officers, Cloud Architects, EU AI Act compliance leads, and legal teams evaluating AI data residency requirements under GDPR, Schrems II, and the EU Data Boundary.

1. The Problem

AI deployments increasingly span multiple cloud providers and jurisdictions. A single AI application may use OpenAI (US), Anthropic (US, now also a Microsoft subprocessor), Bedrock (AWS, multi-region), and Azure OpenAI (EU regions available). Each provider has different data residency guarantees, and the EU Data Boundary (EUDB) coverage varies significantly.

Anthropic as Microsoft subprocessor: Since Anthropic's integration into Microsoft 365 (Claude in M365), customer data processed by Claude may flow through Anthropic's US infrastructure even when the M365 tenant is EU-hosted. This creates a data transfer scenario that requires evaluation under GDPR Chapter V and the Schrems II framework.

The core question for compliance teams: how do you prove, per-inference, which jurisdiction processed a given AI request, what legal basis applied, and whether the data crossed a boundary?

2. The SWT3 Sovereign Boundary

SWT3 enforces a strict separation between the inference path and the evidence path:

What stays in your infrastructure

Prompts, responses, model weights, training data, business context, PII, and all raw content. The SWT3 SDK operates locally within your deployment. It computes SHA-256 hashes of prompts and responses but never transmits the content itself.

What crosses the network boundary

SHA-256 hashes (truncated to 16 hex characters), three numeric compliance factors per procedure, a clearing level indicator, and CJT metadata (jurisdiction code, legal basis, purpose classification). No prompt content, no model output, no PII.

Sovereign boundary principle: Raw prompts and responses never leave the deployment infrastructure. This is a protocol-level guarantee, not a configuration option. The SDK physically cannot transmit content because it only has access to hashed values after the hash function executes.

3. Clearing Levels for Data Residency

The SWT3 clearing protocol provides four levels of data minimization. Higher levels transmit less metadata, suitable for stricter data residency requirements.

Level Name What crosses the boundary Recommended use
0 Analytics Hashes + factors + model ID + provider name + guardrail names + ai_context details Internal analytics, development environments, non-regulated workloads
1 Standard Hashes + factors + model ID + provider + ai_context (no guardrail names) Standard production, GDPR-compliant workloads with adequate legal basis
2 Sensitive Hashes + factors only. No ai_context, no provider name, no model ID in cleartext Healthcare, legal, financial services, cross-border sensitive workloads
3 Classified Numeric factors only. All identifiers hashed. Minimal metadata footprint. Government, defense, air-gapped environments, maximum data minimization

CJT fields (jurisdiction, legal_basis, purpose_class) and operational metadata (agent_id, cycle_id, policy_version_hash) survive all clearing levels. These are compliance metadata, not personal data.

4. CJT Fields: Per-Inference Jurisdiction Binding

Every SWT3 witness anchor carries three jurisdiction fields that create a per-inference regulatory audit trail:

FieldFormatExamplePurpose
jurisdiction ISO 3166-1 alpha-2 "DE", "US-VA", "EU" Which jurisdiction's laws governed this inference
legal_basis GDPR article reference "consent", "legitimate_interest", "contract" Legal basis for processing under GDPR Art. 6
purpose_class Free-text classification "clinical_decision_support", "content_moderation" Purpose limitation documentation per GDPR Art. 5(1)(b)

These fields are set once in the SDK configuration and automatically embedded in every anchor. When an AI application operates across multiple jurisdictions (e.g., a customer support agent serving EU and US users), the application can update the jurisdiction field per-request to create an accurate geographic audit trail.

5. Multi-Region Configuration Examples

EU-Only Deployment

# .swt3.yaml
clearing_level: 2
jurisdiction: "EU"
legal_basis: "legitimate_interest"
purpose_class: "customer_support"

US-EU Split (jurisdiction per request)

# .swt3.yaml (base config)
clearing_level: 1
purpose_class: "content_generation"

# Application code sets jurisdiction per request:
# witness.config.jurisdiction = user.region === "EU" ? "EU" : "US"

APAC Triple-Region with Elevated Clearing

# .swt3.yaml
clearing_level: 2
jurisdiction: "SG"
legal_basis: "consent"
purpose_class: "financial_analysis"

# Singapore PDPA requires consent basis
# Level 2 ensures no provider names or model IDs cross boundary

Maximum Data Minimization (Government/Defense)

# .swt3.yaml
clearing_level: 3
jurisdiction: "US"
purpose_class: "classified_analysis"

# Level 3: only numeric factors cross the boundary
# Air-gap mode: use .pulse bundles for offline evidence transfer

6. Provider Matrix

What SWT3 witnesses vs. what the cloud provider controls:

Provider Data residency SWT3 witnesses Provider controls
AWS Bedrock Region-specific (eu-west-1, etc.) Model identity, inference provenance, latency, guardrails Compute region, network isolation, encryption at rest
Azure OpenAI EU Data Boundary eligible (select regions) Model identity, inference provenance, content marking Data processing region, EUDB enrollment, encryption
GCP Vertex AI Region-specific Model identity, inference provenance, adapter stacks Compute region, VPC-SC, CMEK
Anthropic (direct) US only (as of 2026) Model identity, inference provenance, tool witnessing US processing, 30-day retention (API), trust and safety
Anthropic (via M365) US (Anthropic infra), EU tenant possible (M365) Model identity, inference provenance, jurisdiction field M365 tenant region, Anthropic processing region (US)
Self-hosted (Ollama, vLLM) Operator-controlled Full: model weights, hardware, environment, skills Everything (operator owns the infrastructure)
SWT3 does not control data residency. The protocol witnesses where inference happened and under what legal basis. Data residency is a provider and operator responsibility. SWT3 creates the evidence trail that proves compliance decisions were made and recorded per-inference.

7. Assessor Quick Reference

When the assessor asks...Where to look
"Does AI data leave the EU?" SWT3 anchor jurisdiction field shows per-inference jurisdiction. Clearing level determines what metadata crosses the network. At Level 2+, no provider names or model IDs are transmitted.
"What is the legal basis for processing?" SWT3 anchor legal_basis field. Set per-config or per-request. Persists in the ledger for the retention period.
"Can you prove GDPR data minimization?" Clearing levels 2-3 demonstrate data minimization by design. Only hashes and numeric factors are transmitted. No prompt content, no PII, no model outputs cross the boundary.
"What about Schrems II adequacy?" SWT3 witness anchors contain no personal data (only SHA-256 hashes and numeric factors). The Schrems II transfer assessment may differ for the witness evidence path vs. the inference path. SWT3 addresses only the evidence path.
"How do you handle multi-provider deployments?" Each inference anchor records which provider processed the request (at clearing levels 0-1). The jurisdiction field captures which legal jurisdiction applied. Multi-provider deployments produce a per-inference audit trail showing exactly which requests went where.

8. Document Lineage

SWT3 Protocol:

Regulatory Sources:

Related Guides: