Sub-Processors and LLM Providers: Who Else Sees Your Mail

When you connect an AI email tool to your mailbox, your messages do not stay inside one company. They pass through the vendor's own systems and through the outside services the vendor relies on to run — its hosting, its storage, and the AI model that writes your drafts. An AI vendor sub-processor list is the document that names every one of those outside parties, the LLM layer included. This guide shows you how to read one for the entries that actually matter.

Most sub-processor lists name the obvious infrastructure and stop there. The line they tend to skip is the AI model layer: the gateway that routes your text to a language model, and the model provider on the other end. That is the part this guide spends the most time on, because it is where your mail is most exposed and least disclosed.

The short answer#

Who can see email sent through an AI email tool? In practice, four kinds of party can: the hosting and compute provider that runs the application, the storage provider that holds your message bodies at rest, the AI gateway that routes your text to a model, and the model provider (the LLM) that generates the draft or summary. A vendor's sub-processor list should name each one.

Under the General Data Protection Regulation, these outside parties have a precise legal status. Your vendor is a processor acting on your instructions; anyone the vendor hands your data to is a sub-processor. Article 28(2) says the processor "shall not engage another processor without prior specific or general written authorisation of the controller," and must inform you of "any intended changes concerning the addition or replacement" so you get the chance to object. Article 28(4) says the same data protection obligations must be imposed on that sub-processor by contract, and the original processor "shall remain fully liable" for the sub-processor's performance.

The one entry to check hardest is the model layer. Everything else on the list tends to be a well-known cloud provider with published terms; the AI provider is the one most often left vague, and it is the one reading the actual content of your mail.

The path your email takes: four layers#

Before you can read a sub-processor list well, it helps to know the path a single email travels once an AI feature touches it. Each stop is a place your data can be seen, and each is a candidate for the list.

• Hosting and compute. The servers that run the application — usually a cloud provider or a hosting company. This is where the request is received and orchestrated. Most lists name this correctly.
• Storage. Where your message bodies live at rest: an object store, a database, a search index. This is a residency and retention question — where the data sits and for how long.
• The AI gateway. Some tools call a model provider directly; many route through a gateway that can pick a model per request. The gateway sees your prompt on the way through, so it is a sub-processor in its own right, separate from the model it forwards to.
• The model provider (the LLM). The language model that reads your message text and produces the draft, reply, or summary. This is the party that actually processes your content, and its retention and training terms are the ones that matter most.

Criteria that actually matter when you read the list#

Once you know the path, the list itself is quick to judge. These are the dimensions that separate a real disclosure from a placeholder. As of August 2026, look for each of these before you trust a tool with sensitive mail.

• Does a list exist at all? A named, dated sub-processor list linked from the DPA is the baseline. "We use trusted third parties" in a privacy policy is not a list.
• Are hosting and storage named specifically? A strong list names the cloud provider and the region. "Cloud infrastructure providers," unnamed, tells you nothing about residency.
• Is the model layer on the list? This is the entry most often missing. The list should name the AI gateway and the model provider(s), not fold them into a generic line.
• What binds the model provider? The list should point to terms that say the provider does not train on your content and holds to a short or zero retention window. A named provider with no data terms is only half a disclosure.
• Is there notification of new sub-processors? Article 28(2) gives you the right to be told of changes and to object. A vendor that can swap in a new AI provider silently has not given you that.
• Do the same obligations flow down? Article 28(4) requires the sub-processor to be bound to equivalent terms, with the vendor staying liable. The DPA should say so in writing.

How to score a sub-processor list#

Run the list against this table. Each row is one thing to check, what a strong disclosure looks like, what a weak or missing one looks like, and where on the vendor's site to find it. Cells describe documentation shape, not any specific vendor's numbers.

Worked example: reading one vendor's list#

Say you are evaluating an AI email assistant and you open its sub-processor list. Here is a common shape: the infrastructure is disclosed in full, and the AI layer is a single vague line. This is what that looks like scored against the criteria above.

Read this way, the gap is obvious. The vendor has done the easy half — the cloud host and mail delivery, both well-documented providers — and left the hard half undefined. "An AI provider" could mean one model, or a gateway routing across several, and the list does not say. It also does not tell you whether that provider retains your prompts or trains on them.

The fix is not to walk away automatically. It is to ask the vendor two direct questions: which model provider or gateway processes message content, and what terms bind it on training and retention. A vendor that can answer both in writing has a real disclosure. One that cannot has told you where its documentation ends.

For context, the well-run providers publish clear answers here. OpenAI's documented policy, as of August 2026, is that it does not train on business or API data by default, retains API inputs and outputs for up to 30 days for abuse monitoring before deletion, and offers a zero-data-retention option — verify the current terms on OpenAI's enterprise privacy page. Google's Cloud Data Processing Addendum commits Google to maintaining a list of sub-processors and to giving customers notice and an opportunity to object before a new one takes on your data. A vendor that routes to those providers can point to those terms; the vague-line vendor cannot.

Red flags in a sub-processor list#

One of these is a reason to ask questions. Two or three together is a reason to keep looking.

• No sub-processor list and no DPA. If you cannot find who else touches your mail, you cannot answer that for your own clients either.
• The model layer is simply absent. The list names hosting and storage but never mentions the AI provider that reads your content — the most exposed party is the one left off.
• "We may use third-party AI providers," with no names and no data terms. That is a category, not a disclosure, and it leaves training and retention unanswered.
• No notification mechanism. If the vendor can add or swap an AI provider without telling you, you have lost the Article 28(2) right to object.
• Silence on training at the model layer. "We may use data to improve our services" is not the same as a no. A clear list states that the model provider does not train on your content.
• Routing is described nowhere. You cannot tell whether the tool calls a model directly or through a gateway, so you cannot tell how many hands your prompt passes through.

What we'd pick, and why (honest)#

For most people weighing an AI email tool on this question, the decision comes down to whether the vendor will name its full chain — model layer included — and bind it in writing. Disclosure first: we build AI Emaily, so treat this as an interested opinion and check it against our security and privacy-model pages at aiemaily.com.

AI Emaily is the pick when you want the AI to do real work across more than one mailbox without losing sight of who processes your content. It routes model calls through OpenRouter, a gateway that lets us send each task to a fit-for-purpose model, and we hold the model providers to zero-retention terms and do not train on your mail. Because routing is done through a gateway, we describe it as a gateway plus the providers it may route to — we do not claim a single fixed model reads every message, because that is not how routing works. Message bodies live in encrypted storage, OAuth and any bring-your-own-key credentials are envelope-encrypted and never logged, and BYOK lets you run AI requests against your own model account and terms. In Copilot mode nothing is sent until you approve it, and the agent holds an action for your review rather than acting when it is not confident, with an undo window and an audit log behind it. Packaging is a 7-day free trial on the Pro and Autopilot tiers — card required, $0 if you cancel before day seven — not a permanent free plan; current pricing is at aiemaily.com/pricing.

Where we'd send you elsewhere. If your requirement is that the model never leaves infrastructure you fully control — a self-hosted open model, or an enterprise LLM inside your own cloud tenancy — a shared cloud gateway is not that, and a self-hosted or single-tenant setup is the better fit. If you need a countersigned enterprise DPA with named sub-processors and specific compliance certifications for a procurement review, ask us for our current terms, but weigh any vendor on the documents it will actually sign, not on a blog page. State the limit plainly: a gateway model gives you strong retention and no-training terms across providers, not the physical isolation a self-hosted model gives.

In short: AI Emaily is right for you if you want a private assistant that acts across your accounts with a human in the loop and a disclosed, bound model layer. It is the wrong pick if your bar is that the LLM must run only on hardware you own — that is a real trade-off, and a self-hosted option answers it better.