Data Residency for AI Email Tools: EU, US and In Between

Two clauses that read the same in a sales demo mean different things once you get to a DPA. "Data resides in the EU" usually means the mailbox is stored in an EU region. It rarely means the AI processing is. That gap is where every awkward audit conversation starts.

If you're evaluating an EU data residency AI email tool for a European team — or a US team with European customers — you need to separate two questions the marketing pages routinely fuse. Where does the mail sit at rest? Where is a model call actually served from when the assistant drafts a reply?

This guide walks the axes that decide the answer, gives you a scoring table you can run against any vendor, works one example end to end, and — because it's a decision guide and honesty is the point — grades our own product on the same rubric. If your bar is region-guaranteed inference with a signed DPA, we'll name the vendors that clear it and where we do not.

The short answer#

Storage residency and inference residency are separate promises. Confirming one does not confirm the other, and most vendors only publish one clearly.

Storage residency is where the mail — messages, attachments, metadata — physically sits at rest. If the tool doesn't host the mailbox (an overlay on Gmail or Outlook, or an IMAP client), storage residency is your provider's problem. Google Workspace's data-region controls let Business Plus and Enterprise customers pin covered data at rest to Europe or the US. Microsoft 365 assigns your tenant a geo at creation, with Advanced Data Residency sold as an add-on for tighter guarantees. Those regions carry through to any tool that reads the mailbox rather than replacing it.

Inference residency is where the LLM call is served. It is a separate contract, often with a separate provider, and it is where surprises live. An "EU-hosted" email tool can send drafts to a US-region model endpoint if the vendor's inference provider only offers capacity there. The mailbox stayed put; a copy of the relevant text still crossed the Atlantic to generate the reply.

Whether you can require the EU depends on what the vendor publishes. GDPR Chapter V governs the transfer mechanism when personal data leaves the EEA — Standard Contractual Clauses, the EU–US Data Privacy Framework, or an adequacy decision for a listed country. What you actually want is an EU-only routing option written into the DPA: a commitment that the vendor's inference sub-processor serves your calls from an EU region, with sub-processors named per region.

Ask both questions separately. Verify both in writing. A vendor that treats them as one question has usually only answered one.

Criteria that actually matter#

Feature grids will not save you here. These are the six axes that decide whether a tool passes a serious data-residency review, and each is checkable before you sign.

• Mailbox storage region and control — where the mail lives at rest, and whether the region is chosen or assumed.
• Inference region and routing — which LLM provider handles calls, from which region, and whether EU-only is offered as an option.
• Transfer mechanism — SCCs, DPF, adequacy, or intra-EEA — named per data flow, not just once for the whole contract.
• Sub-processor list and residency — every processor named, with country of processing and a change-notification window.
• Retention and training posture — zero-retention with model providers, no training on user mail, spelled out in writing.
• Data sovereignty versus residency — residency is where data sits; sovereignty is whose law reaches it.

Two audit-adjacent items belong on the list even though vendors rarely lead with them. Backup and DR region matters because a primary EU region with a US failover is not EU-resident data during failover — one page-nine sentence in a DPA can undo everything on page one. Log and telemetry region matters because support logs and error traces routinely ship to a US observability provider by default, and email bodies leak into stack traces more often than sales teams admit.

None of this is exotic. It is the same list a good procurement team runs on any SaaS. The email-specific twist is that a mail body is the personal data of everyone your team corresponds with, not just of your users. A shortcoming here is your customer's regulator problem, not only yours.

Scoring table you can run against any vendor#

Score each axis pass, partial or fail. A single fail on axis 1 or 2 outweighs three passes elsewhere — a broken storage or inference commitment is not compensated for by an otherwise tidy DPA.

Worked example: a 40-seat German firm on Google Workspace#

Take a German professional services firm, 40 seats, working under standard GDPR obligations for its client mail. Mail already sits on Google Workspace Enterprise Standard with data regions set to Europe. The team wants an AI email tool for triage, drafting and follow-ups. Requirements: mailbox stays in-region, inference stays in-region, DPA signed with SCCs where applicable, no training on user mail.

Their finalist is a Gmail overlay whose vendor publishes an EU-region routing option under its enterprise tier. Run the axes.

1. 1

   Axis 1 — storage

   The tool is an overlay; it never hosts the mail. Storage stays in Google Workspace's EU region, confirmed at the tenant and covered by Google's own DPA. Pass.

2. 2

   Axis 2 — inference

   The vendor uses one LLM provider that offers an EU region under its enterprise plan. The vendor's DPA names the provider and sets the region to the EU for this contract, in writing. Pass.

3. 3

   Axis 3 — transfer mechanism

   The vendor's parent is US-registered, but processing for the covered mail flows is EU-only, so no international transfer occurs for those flows. The DPA lists SCCs to cover incident-handling flows that cross regions. Pass.

4. 4

   Axis 4 — sub-processors

   Public list names the LLM provider, the payment processor, the observability platform and the transactional-email vendor, each with country of processing and a 14-day change-notification window. Pass.

5. 5

   Axis 5 — retention and training

   The DPA states the LLM sub-processor has zero retention and does not train on customer content. The sub-processor's own enterprise terms are linked. Pass.

6. 6

   Axis 6 — sovereignty

   The parent is US-registered, which the buyer flags as a CLOUD Act concern. Partial for residency-only requirements; fail if the bar is strict sovereignty. This is where the shortlist splits.

The example is deliberately imperfect. Real evaluations end with a decision on which axis is disqualifying. For most private-sector firms, axes 1–5 are the bar and axis 6 is a stretch goal. For a public-sector buyer, axis 6 becomes the bar and the shortlist shrinks accordingly — often down to European-owned mail hosts rather than any of the mainstream AI assistants.

Red flags worth catching on the sales call#

• "We host in the EU." Storage residency only. Ask about inference in the same sentence and note the pause.
• "Our LLM provider is compliant." Compliance is not a region. Ask which region the endpoint runs in for your specific contract.
• "Sub-processor list on request." Anything routed through a support queue is not something you can rely on during an audit or a data-subject request.
• "We're SOC 2 / ISO 27001 certified." Neither certification asserts data residency. Both are worth having; neither answers this question.
• "Data never leaves the EU." Confirm the sentence covers telemetry, error traces, backups and support tickets. Frequently it does not.
• "We use OpenAI, Anthropic or Google." Fine — but each has multiple regions and multiple enterprise tiers. The question is which one, under which contract.
• "The model runs on our servers." Confirm whether that is inference on hosted weights or a proxy call to a third-party API. Sales teams use the same words for both, and only one answer is defensible under an EU-only clause.

What we'd pick and why — honest scoping#

Because this is our site, the honest answer starts with where we do not clear this bar today. We build AI Emaily.

AI Emaily runs on a European-hosted VPS with our own Postgres, Redis and object storage, and routes model calls through OpenRouter across multiple LLM providers. We do not train on user mail, OAuth tokens and BYOK keys are envelope-encrypted server-side, and we never host your mailbox — it stays with Google, Microsoft, iCloud, Fastmail, Proton or your IMAP host. That covers axes 1, 4 and 5 credibly.

What we do not ship today: a region-selection UI, a contractually pinned EU-only inference route per customer, or a signed EU-only DPA option. If the bar for your buy is region-guaranteed inference under an audit-ready DPA, we are not the right pick, and we would rather say that once than sell you a fit we cannot support. See app.aiemaily.com/pricing for the current plan and the 7-day trial terms.

With that stated, here is the honest picture per bucket.

If the requirement is sovereignty#

European ownership, no CLOUD Act exposure, ideally end-to-end encrypted mail. Proton Mail (Swiss-based, end-to-end encrypted, Swiss privacy law) is a serious pick for the mail itself, and Tuta (German, end-to-end encrypted) is the other name that usually comes up. Neither is an AI email assistant of the shape this post is otherwise about — they are mail hosts with strong sovereignty posture and comparatively limited AI features. Proton and Tuta are stronger on data sovereignty than we are today, and buyers whose primary bar is jurisdiction rather than assistant capability should start there.

If the requirement is EU storage residency with mainstream AI features#

Keep the mail on Google Workspace with data regions set to Europe, or Microsoft 365 with an EU geo (Advanced Data Residency if the tenant qualifies). Both give strong storage guarantees on the mailbox side. Then evaluate any overlay AI assistant only on axis 2: which LLM sub-processor, which region, EU-only in writing.

If the requirement is EU inference under a signed DPA#

The shortlist is small and moves quickly. Vendors that offer EU-region model routing under a signed DPA publish it prominently when they have it; if the language is not on a public page, assume the option is not offered. This is the axis that most eliminates candidates in 2026, and it is where an AI email tool with an EU-only promise on its landing page most often turns out to mean storage only.

Where AI Emaily is a fair candidate#

You are a Gmail, Outlook or IMAP user under GDPR whose bar is "no training on my mail, credentials envelope-encrypted, no vendor-hosted mailbox, honest sub-processor disclosure," and region-guaranteed inference is a preference rather than a hard contractual requirement. On that brief we are a good fit: your mail stays with your provider, we do not train on it, and we publish what we do and don't do rather than implying more. Start the 7-day trial at app.aiemaily.com and read the current sub-processor posture on aiemaily.com/security.

If the bar tightens to a contractually pinned EU inference region, that is a real feature and we do not ship it today. Conceding it here is cheaper for both of us than losing an audit for you later.