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 and any other MCP client 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:
- The app. Check where each SaaS vendor hosts your tenant. If the help desk tenant sits in the US, no agent setup moves it.
- 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.
- The control plane. Choose a vendor whose region covers its own records: who connected what, which rules apply, and the log of each call that reaches execution. In Elaichi, that is the
euregion. - 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 and the execution of its org-scoped requests and tool calls are pinned to the EU. Elaichi has three regions, eu, us and apac, chosen when the organization is created and fixed afterwards. The eu region is available on every plan.
The data store. Elaichi keeps one data store per organization, and for an eu organization it is pinned to the EU. It holds the members, teams, roles, sharing grants, connection records, toolboxes, restrictions, access requests, OAuth grants and Elaichi Agent conversations.
The credentials. Connections created since 2026-10-05 have their credentials placed in the organization's region, inside the EU for an eu organization. Older connections stay where they were until they are reconnected, which copies them into the region. Credentials 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. Requests and tool calls that act inside an eu organization run in the EU. That covers the REST API inside the organization, POST /mcp, SCIM, file downloads, invites and OAuth callbacks. Requests that do not act inside an organization run at the edge, wherever the request lands. Those are sign-in and sign-up, a person's own profile, creating and listing organizations, OAuth server endpoints and webhook intake.
The audit trail. Every organization's audit trail, whatever its region, is stored in one log instance in the EU (see the privacy policy). An eu organization's records go only to the EU endpoint.
Stored tool files. Files Elaichi keeps from tool results go to one private bucket in the EU for every organization, whatever its region.
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, which works inside the app, is the one place 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 the calls. Those records describe your people and your customers' accounts, even without the payload.
The audit trail. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), and each names the account the call actually reached. Of the arguments, it keeps the one path argument that names the object, as the target id, and nothing else about the arguments. 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. Every region's audit trail is stored in one EU log instance, with each organization's records kept apart, 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. A tool you withhold keeps its schema out of 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, encrypted with AES-256-GCM, and owns refresh. Connections created since 2026-10-05 are placed in the organization's region. 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 history, 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. Deletion does not purge the audit history. Each record ages out under the log server's 90-day retention, counted from when it was written. 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 and the execution of its org-scoped requests and tool calls are then pinned to the EU, and the audit trail is stored there. User accounts and sign-in sessions are kept globally. 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 most of its connectors from its own infrastructure, and the rest are vendors' own MCP servers, 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
globalandusas 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 history, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. Deletion does not purge the audit history. Each record ages out under the log server's 90-day retention, counted from when it was written.
- 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 600+ connectors at /connectors/.
