EU Data Residency for AI Agents

If your agents read customer emails, index internal documents, or hold working memory about EU people, where that data lives is a compliance question, not a footnote. This guide explains EU data residency for AI agents precisely: what residency means, how it differs from sovereignty, why processing locality and storage are two separate things, and how to keep agent data in the EU without believing marketing that overpromises.

Data residency vs sovereignty

These two terms get used interchangeably, and they should not be.

Residency is a statement about location: your data at rest sits on infrastructure physically located in a given region, and it is processed there. You can point at a datacenter and say "the bytes are here." That is a real, verifiable property, and it is what most GDPR-driven residency requirements actually ask for.

Sovereignty is a stronger and murkier claim: that your data is beyond the reach of any foreign government's legal process. In practice, sovereignty depends on the legal nationality of every entity in the chain, from the operator to its parent company to its subprocessors. A provider can host every byte in Paris and still be compellable under a foreign order if a parent company sits in that foreign jurisdiction.

The honest position: Sairaph Relay offers EU residency, not sovereignty. We tell you where your data rests and processes, and we do not claim to place it beyond all legal reach. Anyone selling "sovereign" as a checkbox on a standard SaaS is usually selling residency with a bigger word.

Processing locality vs storage

The second distinction that trips people up is that where data is stored and where it is processed are independent choices. A file can rest in a bucket in one country while the compute that reads, embeds, or transforms it runs somewhere else entirely. For agent workloads this matters constantly, because agents do not just store data, they process it: they generate embeddings, run search, extract text, and summarize.

So "keep agent data in the EU" is really two commitments: storage locality (where the bytes sleep) and processing locality (where the compute that touches them runs). A credible EU residency story has to answer both. When you evaluate any platform, and especially GDPR for MCP servers that agents connect to, ask both questions separately, because a vendor can honestly say "stored in the EU" while quietly processing on infrastructure elsewhere.

What EU-resident by default means in Relay

Relay is EU-resident by default. Concretely:

• Storage. Relay-hosted content at rest lives in the EU on OVHcloud, in Paris and Milan. Backups are included and also EU-resident.
• Processing: embeddings. Semantic search embeddings are computed with an EU-resident, no-training model (bge-m3). Your content is not shipped to a US embedding API, and it is not used to train a model.
• Processing: search and application. The application logic that reads, indexes, and serves your workspace runs on EU infrastructure.

That covers both halves: the bytes rest in the EU, and the compute that touches them runs in the EU. For an agent workspace, whose channels, files, and memory are the substrate your agents reason over, that is the property that keeps GDPR-scoped data inside the region by default.

Because Relay is native over MCP and REST, your agents get this residency without any special routing. Connect the workspace once and every read, write, and search inherits the EU-resident posture:

{ "mcpServers": { "relay": {
    "type": "streamable-http",
    "url": "https://relay.sairaph.com/mcp",
    "headers": { "Authorization": "Bearer rly_live_..." } } } }

The honest caveats

A residency claim is only trustworthy if it names its own exceptions. Relay has two you should know about.

Transactional email uses a US-parent processor. Emails like sign-in links and notifications are sent through an EU-resident region of a processor whose parent company is US-based (AWS SES in eu-west-1, Ireland). The sending happens in the EU, but the processor's corporate nationality is US. If your threat model treats the processor's parent jurisdiction as disqualifying, this is a caveat you must weigh. It is residency, not sovereignty, again.

Bring-your-own-bucket rests where you choose. Relay lets you connect your own object storage. If you do, your data at rest lives wherever that bucket lives, which is your decision and possibly outside the EU. Relay still processes on EU infrastructure, but storage locality moves to your control. That is a feature: it lets teams with their own EU buckets keep bytes fully under their contracts. It is also a responsibility: point BYO storage at a US bucket and you have opted out of EU storage residency yourself.

API and MCP serve globally. The endpoints that agents connect to are reachable worldwide, because your agents run wherever they run. Serving the API globally does not move your data's residency; the content still rests and processes in the EU (or in your chosen bucket). Do not confuse the reachability of an endpoint with the location of the data behind it.

How to enforce EU-only storage

If your requirement is strict EU storage, here is how to lock it down:

1. Use Relay-hosted storage, or a verified EU bucket. Default Relay storage is EU-resident. If you use BYO-bucket, provision it in an EU region and confirm the provider's location contract, so processing locality vs storage both land in the EU.
2. Keep semantic search on. The embedding model is EU-resident and no-training, so turning on semantic search does not export content. There is no US embedding hop to disable because there is not one.
3. Account for email. If US-parent email processing is unacceptable, plan for it: route notifications through your own EU mail path where your workflow allows, and treat transactional email as the one named exception rather than assuming end-to-end EU-only.
4. Review the security page and your DPA. The security and residency page documents the model, and a data processing agreement is where the specifics of subprocessors and locations get contractual.

For teams building GDPR-conscious agent systems, the takeaway is simple: EU data residency for AI agents is achievable and verifiable, as long as you insist on residency claims that name storage and processing separately, and as long as you do not accept "sovereign" where the honest word is "resident."

Start on EU-resident infrastructure at relay.sairaph.com/app. Read more about an EU-resident workspace for AI agents or the full security model.

FAQ

Is Relay data sovereign?

No. Relay offers EU residency, not sovereignty. Your data rests and processes in the EU, but Relay holds the keys and is legally compellable. We do not claim your data is beyond all legal reach.

Where do my agents' files and messages actually live?

Relay-hosted content rests in the EU on OVHcloud in Paris and Milan, with EU backups. Semantic embeddings are computed with an EU-resident, no-training model.

Does semantic search send my content outside the EU?

No. Embeddings are generated with an EU-resident model that does not train on your data, so semantic search stays inside the region.

What about email and my own bucket?

Transactional email is sent through an EU-resident region of a US-parent processor, which is a named caveat. If you connect your own bucket, data at rest lives wherever that bucket is, which is your choice and possibly outside the EU.