# EU data residency for AI agents, leg by leg > EU data residency for AI agents spans three legs: the app, the control plane and the model. Elaichi's eu region keeps data, credentials and calls in the EU. **TL;DR** EU data residency for AI agents is three separate promises: the SaaS app's hosting region, the control plane's region and the model provider's region. In Elaichi's eu region, the organization's data store, its connector credentials, every request and tool call, and the audit trail all stay in the EU. The model provider and the apps keep their own settings, which Elaichi does not control, so each needs its own answer in your transfer records. A support lead in Munich wants Claude on the help desk. A finance team in Dublin wants ChatGPT on the accounting system. The data protection officer asks whether customer data stays in the EU. A US company with EU customers hears the same question in every security review. ## What does EU data residency for AI agents actually cover? EU data residency for AI agents is three promises, made by three different vendors. The SaaS app keeps its records where its vendor hosts them. The control plane between the agent and the app keeps its own records. The model provider processes the prompt and every tool result the agent reads. Each leg has its own region setting, and no single setting covers all three. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi is a governed MCP control plane. Each SaaS account is connected once, and its tools are served through one organization-wide endpoint, the single address every AI client points at: `https://api.elaichi.ai/mcp`. Claude, ChatGPT, Cursor, any MCP client, and the Elaichi Agent all use it. Each member signs in with OAuth, which gives the client a revocable grant instead of a password. This post describes the mechanism, not the law. For the legal reading, start with the regulation. Chapter V allows a transfer to a third country only when its conditions are met ([GDPR Article 44, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj)). Article 28 requires a binding contract with every processor. The European Data Protection Board's [Recommendations 01/2020](https://www.edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer_en) cover the measures that supplement transfer tools. A map of the legs is where that work starts. ## How do we keep data in the EU when employees use AI agents on SaaS tools? Pin each leg separately, then write down the legs you cannot pin. No vendor owns all three legs, so no vendor can do this for you. Work in this order: 1. **The app.** Check where each SaaS vendor hosts your tenant. If the help desk tenant sits in the US, no agent setup moves it. 2. **The model provider.** Check which region the AI client offers for prompts, conversations and inference on your plan. Tool results enter the model's context, so whatever the agent reads is processed here. 3. **The control plane.** Choose a vendor whose region covers its own records: who connected what, which rules apply, and the log of every call. In Elaichi, that is the `eu` region. 4. **The gaps.** List every leg that is not pinned, with the safeguard your lawyers rely on for it. Article 46 names standard contractual clauses as one such safeguard ([GDPR text](https://eur-lex.europa.eu/eli/reg/2016/679/oj)). The fourth step carries the most weight. A rollout can include a leg outside the EU, but not one nobody wrote down. ## Which leg does Elaichi's eu region cover? The control plane leg, and no other leg. In the `eu` region, the organization's data store, its connector credentials and the execution of every request and tool call all stay in the EU. Elaichi has three regions, `eu`, `us` and `apac`, chosen when the organization is created. The `eu` region is available on every plan. **The data store.** Elaichi keeps one Durable Object per organization, and for an `eu` organization it runs and stores data in the EU. It holds the members, teams, roles, sharing grants, connection records, toolboxes, restrictions, OAuth grants and Elaichi Agent conversations. **The credentials.** Connector credentials are stored in the organization's region. They are encrypted at rest with AES-256-GCM, and each ciphertext records the ID of the key that wrote it, so keys can be rotated. **The execution.** Every request and tool call for an `eu` organization runs in a gateway placed in the EU. The credential is read and the SaaS app is called from inside the EU, and the app's response is handled there too. Background work such as queues and webhooks runs there as well. **The audit trail.** An `eu` organization's audit trail stays in the EU. Elaichi never sends an `eu` organization's audit trail to a US instance. **Stored tool files.** Files Elaichi keeps from tool results go to a bucket kept in the EU. **Kept globally.** User accounts, the organization record, sign-in sessions, API tokens, SSO settings and MCP OAuth token records are global stores, not part of the EU region. List them in your vendor review and your transfer records. The region is fixed at creation, so choose it before the first member joins. Read the region as a statement about the control plane, not about every system in the path. The model provider and the app are separate legs. ## Where does the model provider process the prompt? Wherever the AI client's vendor processes it, under that vendor's settings on your plan. Elaichi has no say in it. Anthropic's API documentation lists two inference geographies, `global` and `us`, and says workspace geo, where data is stored at rest, is `us` only ([Anthropic data residency](https://platform.claude.com/docs/en/manage-claude/data-residency), checked October 2026). This covers the Claude API. Ask Anthropic separately about Claude Team or Enterprise workspaces. On Amazon Bedrock and Google Cloud, the same page says, the endpoint sets the region. Claude also reaches a custom connector from Anthropic's cloud, not from the user's device, on every Claude client. OpenAI offers European data residency for new ChatGPT Enterprise and Edu workspaces and for new API Projects ([OpenAI, data residency in Europe](https://openai.com/index/introducing-data-residency-in-europe/), checked October 2026). Its help center lists Europe as an inference residency region for eligible ChatGPT Enterprise and Edu customers. The same page excludes data processed outside OpenAI's infrastructure "through external integrations (e.g., Apps & MCP, Web Search, if enabled)" ([OpenAI Help Center](https://help.openai.com/en/articles/9903489-data-residency-and-inference-residency), checked October 2026). That exclusion is why the MCP leg, where the agent reaches your apps, needs its own answer. The Elaichi Agent is the one client where you choose the model leg yourself. Its model access is bring-your-own-key only. An admin sets a key for Anthropic, OpenRouter, Fireworks, or an OpenAI-compatible gateway at a base URL the admin enters. So a team can use a provider endpoint whose processing location it already has under contract. ## Why does the control plane leg matter if it is only one of three? It holds the records a regulator or a customer asks about first: who reached what, through which account, and when. It also holds the credentials and runs every call. Those records describe your people and your customers' accounts, even without the payload. **The audit trail.** Elaichi writes one entry per tool-call attempt, succeeded or failed, and each names the account the call actually reached. Of the arguments, it keeps argument names and counts, and never argument values. The error text in the trail is never derived from the third party's response, so a remote error body cannot carry customer data into the log. Each organization has its own log tenant, and a free read-only Auditor seat can review it. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. **What the agent can reach.** Restrictions decide which connectors and which individual tools a target may reach. They are enforced on the server, not left to the model. Every tool you withhold is data that never enters the model's context, so this leg also shrinks what the model provider receives. **Credentials.** Connector credentials never live in the organization store. A separate credential service holds them in the organization's region, encrypted with AES-256-GCM, and owns refresh. A connect URL is a one-time session that carries no token. **Deletion.** Deleting an organization tears down the rest of the workspace and deletes every connected account's credential. Three stores keep residue: the audit log tenant, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. Elaichi has no purge path for them and returns that residue by name. The audit history ages out on the log instance's retention period. Describe it that way in an erasure answer, with all three stores named. ## Is there an enterprise MCP platform with EU data residency? Yes. Elaichi offers it for the control plane leg, on every plan. Choose `eu` when the organization is created. The data store, the connector credentials, the execution of every request and the audit trail then stay in the EU. The model provider and the apps keep their own regions. One address serves every client, so there is no per-team or per-user server to place in a region. Elaichi authors and serves its connectors from its own infrastructure, so you do not run MCP servers in your own EU cloud. SAML and OIDC sign-in are built in-house, with SCIM v2 provisioning and group-to-role mapping. A role or restriction change takes effect within about two minutes. Offboarding holds on the next call: removing or suspending a member revokes every live grant in the same transaction as the membership change. Elaichi has two plans, Gold and Black. Gold is $15 per user per month at the USD list price, and the pricing page shows your local price. Pick the region when you create the organization, because it is fixed after that. [See pricing](/pricing/) ## Where do I check Elaichi's compliance statements? Check the Trust Center at [trust.elaichi.ai](https://trust.elaichi.ai), the page Elaichi points to for what it attests. Attribute any SOC 2 or HIPAA statement for a compliance file to that page. For the control mapping, see [SOC 2 evidence for CC6 and CC7](/blog/soc2-evidence-ai-agents-cc-controls/). For ChatGPT, OpenAI's residency excludes Apps and MCP, so the endpoint's region is a separate question. [The ChatGPT setup guide](/blog/connect-elaichi-to-chatgpt/) covers connecting that endpoint. The security page covers how credentials are held, how access is shared, and where the Trust Center sits. [Check what the Trust Center covers](/security/) ## When does Elaichi's eu region not solve the problem? When the leg that breaks your policy is not the control plane. Elaichi's region cannot move a model, an app tenant or a retention clock. - **Your policy requires EU inference for Claude through Anthropic's API.** Anthropic's page lists `global` and `us` as the geographies (checked October 2026). The region is chosen at the provider, for example through a cloud endpoint, not in Elaichi. - **The app tenant is hosted outside the EU.** Moving it is a conversation with that vendor. - **An erasure deadline requires everything purged on request.** Three stores survive organization deletion: the audit log tenant, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. The audit history ages out on its retention period. - **No AI client points at company data.** Then the work is policy first, as laid out in [when you may not need an MCP gateway](/blog/when-you-dont-need-an-mcp-gateway/). For what a good record should hold, see [what an AI audit log must capture](/blog/what-an-ai-audit-log-must-capture/). For the wider category, start with [what an MCP gateway is](/blog/what-is-an-mcp-gateway/), and browse the 500+ connectors at [/connectors/](/connectors/). ## FAQ ### Is there an enterprise MCP platform with EU data residency? Elaichi offers EU data residency for the control plane, on every plan. An organization created in the eu region keeps its data store, its connector credentials, the execution of every request and tool call, and its audit trail in the EU. Claude, ChatGPT, Cursor, any MCP client and the Elaichi Agent reach the apps through one endpoint, https://api.elaichi.ai/mcp, under roles, restrictions and an audit log. The model provider and each SaaS app keep their own region settings, which Elaichi does not control. ### How do we keep data in the EU when employees use AI agents on our SaaS tools? Pin each leg of the data path separately. Check where each SaaS vendor hosts your tenant. Check which region the AI client's vendor offers for prompts, conversations and inference on your plan. Choose a control plane with an EU region for its own records. Then document every leg you could not pin, with the transfer safeguard your lawyers rely on for it. No single vendor setting covers all three legs. ### Does choosing an EU control plane keep prompts in the EU? No. The prompt, the conversation and every tool result the agent reads are processed by the model provider, such as Anthropic or OpenAI, under that provider's own region settings. An EU control plane such as Elaichi's eu region keeps the control plane in the EU: the organization store, the connector credentials, the execution of every request and the audit trail. It cannot move inference. ### Can an existing Elaichi organization move to the eu region? No. The region is chosen when the organization is created and is fixed from then on. The choices are eu, us and apac. The eu region is available on every plan. Each of the three regions keeps the organization's data, its connector credentials and the execution of every request in that region, so an EU commitment needs the eu region from day one. ## Read next - [AI agents and PHI: four questions for your BAA](/blog/hipaa-ai-agents-baa-reviewer-questions/) — AI agents and PHI raise four BAA questions, all about access: minimum necessary, audit controls, workforce clearance and what happens when someone leaves. - [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) — An AI agent audit log must capture who acted, which client called, which account was reached, what was tried and how it ended. Argument values stay out. - [SOC 2 evidence for AI agents: CC6 and CC7](/blog/soc2-evidence-ai-agents-cc-controls/) — SOC 2 evidence for AI agents maps to CC6.1, CC6.2, CC6.3 and CC7.2: who can reach what, how access starts and ends, and a log of every tool call.