Data Residency for AI Agents: IL, EU, US Compliance Guide
Ensure your AI agent data stays within designated regions. GDPR, data sovereignty, and regional compliance for AI workloads.
What you will learn
- Understand why data residency matters for AI agent workloads
- Choose the right region for your workspace based on compliance requirements
- Ensure agent data, LLM calls, and audit trails stay within regional boundaries
- Meet GDPR Article 44-49 requirements for cross-border data transfers
Why Data Residency Matters for AI Agents
AI agents process, generate, and store data with every action. When an agent makes an LLM call, the prompt and response traverse networks. When it logs an action, data is written to a database. When it accesses customer information, PII enters the pipeline. Where all this data lives — geographically — is not just a technical detail. It is a legal requirement.
GDPR (EU), CCPA (California), PDPA (Israel), and similar regulations require that personal data is stored and processed in specific regions. For AI agents, this means every LLM call, every audit log entry, and every credential must respect regional boundaries.
Agent data scattered across US data centers. LLM calls go to OpenAI (US). Audit logs in Google Cloud (US-central). No way to prove data residency to an EU regulator. GDPR violation risk.
Workspace region set to EU. All BigQuery data in europe-west1. LLM calls routed through EU endpoints. Audit trail stored in EU. Clean compliance story for regulators.
Three Regions Available
- Israel (IL) — me-west1 (Tel Aviv). For Israeli companies and Middle East operations. Compliant with Israeli Privacy Protection Law.
- European Union (EU) — europe-west1 (Belgium). For GDPR compliance. Data never leaves EU boundaries.
- United States (US) — us-central1. For US-based operations. Compliant with CCPA and SOC 2.
Region selection happens once during workspace creation and cannot be changed. This is by design — it guarantees that data residency is immutable. Choose carefully based on where your primary customers and compliance obligations are.
What Stays in Region
- Tenant data — all workspace data stored in regional BigQuery dataset (ds_tenant_{region})
- Agent execution data — tasks, runs, approvals, timeline events (ds_agents_{region})
- Audit trail — every agent action logged in regional tables
- Credentials — encrypted LLM API keys stored in regional tenant tables
- LLM responses — cached responses stored in regional cache
GDPR Compliance Checklist
- Region selection: EU workspace for EU customer data
- Data Processing Agreement (DPA) signed and available at /dpa
- Sub-processors listed at /trust with data locations
- Right to deletion: supported via GDPR data deletion API
- Consent management: cookie consent banner with GTM conditional loading
- Audit trail: 365-day retention for compliance evidence
- Encryption: AES-256-GCM at rest, TLS 1.3 in transit
Dobby provides a signed Data Processing Agreement (DPA) for enterprise customers. Regional data isolation is enforced at the infrastructure level — datasets are physically separated in BigQuery with region-locked configurations. Cross-region views (for platform admins only) use UNION ALL queries that never move data.
LLM Provider Data Residency
An often-overlooked aspect: where does the LLM provider process your data? When your agent sends a prompt to OpenAI, that data goes to OpenAI's servers. The Gateway tracks which provider received which data, giving you a complete data flow map for regulators.
For strict data residency, use providers with regional endpoints: Azure OpenAI (EU regions), AWS Bedrock (eu-west), or Google Vertex AI (europe-west). The Gateway routes to these regional endpoints when configured.
Review your LLM provider's data processing terms. OpenAI's API data is processed in the US. For EU-strict workloads, consider Azure OpenAI with EU hosting or Mistral (based in France, EU data processing).