EU data residency for AI agents, leg by leg

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). Article 28 requires a binding contract with every processor. The European Data Protection Board's Recommendations 01/2020 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).

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, 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, 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, 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.

Where do I check Elaichi's compliance statements?

Check the Trust Center at 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. For ChatGPT, OpenAI's residency excludes Apps and MCP, so the endpoint's region is a separate question. The ChatGPT setup guide covers connecting that endpoint.

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.

For what a good record should hold, see what an AI audit log must capture. For the wider category, start with what an MCP gateway is, and browse the 500+ connectors at /connectors/.