GDPR-Compliant AI Email Assistant: What to Require

"GDPR compliant AI email assistant" is a phrase vendors use loosely, and no regulator hands out that label. GDPR compliance is a state your organization occupies, not a certification a supplier can transfer to you. It is built from documented choices: a lawful basis for what the AI reads, a signed processor agreement, a named transfer mechanism, a breach clock, and a working route to answer access and erasure requests.

This is the checklist to run before you connect a business mailbox to an AI email tool — what to require in writing, what a good vendor answer sounds like, and the red flags that mean nobody there has done this work yet. Where AI Emaily fits is in the verdict section below, including where it does not replace your own legal review.

One scope note before the checklist: this is a GDPR guide, not an EU AI Act guide. The two overlap where an AI email tool does automated decision-making about a person, but they're separate legal regimes with separate obligations — if your deployment touches the AI Act too, that's a second checklist, not a substitute for this one.

Criteria that actually matter#

Eight things decide whether an AI email tool can sit inside a GDPR-governed workflow. Skip one and the gap is yours to explain to a regulator or an auditor, not the vendor's — a processor's failure is still the controller's exposure under Article 28 GDPR.

• Lawful basis (Article 6) — a documented reason the AI is allowed to process this mail, decided before it processes any of it.
• Processor agreement (Article 28 DPA) — a signed contract naming the processing's subject-matter, duration, purpose, and the categories of data and data subjects involved.
• Sub-processor transparency — a current, named list of who else touches the data, including the LLM provider generating drafts, summaries, or search results.
• Transfer mechanism (Article 46) — Standard Contractual Clauses, an adequacy decision, or another named safeguard if any processor sits outside the EEA.
• Security measures (Article 32) — specific technical and organizational controls: encryption, access restriction, incident response, and regular testing of those controls.
• Data subject rights workflow (Articles 12–22) — a real mechanism to locate, export, or erase one person's mail data inside the tool, on the one-month clock Article 12 sets.
• Breach notification duty (Article 33) — a contractual commitment on how fast the vendor tells you, so you can meet your own 72-hour duty to the supervisory authority.
• DPIA screening (Article 35) — a documented decision on whether this deployment is likely to result in a high risk to individuals, and therefore needs a full Data Protection Impact Assessment before it goes live.

Tie these eight back to one principle and the list stops feeling arbitrary: Article 5(2) makes the controller responsible for demonstrating compliance, not just achieving it. A lawful basis nobody wrote down, a DPA that exists but was never signed, a sub-processor list kept only in someone's memory — none of these fail because the underlying processing was unlawful. They fail an audit because nothing on paper proves the work was done.

Scoring the vendor#

Use this as a scorecard on a sales call or a security questionnaire. A vendor that answers all eight with specifics, in writing, has done the work. One that answers with a link to a general privacy policy has not.

Weight the rows unevenly. A weak answer on sub-processor disclosure or the transfer mechanism is a harder blocker than a weak answer on, say, DPIA screening for a low-risk internal deployment — the first two are near-mechanical legal requirements, the second is genuinely risk-dependent.

Worked example: onboarding an AI email assistant at a 40-person company#

This is one plausible sequence for a small company running its first AI email pilot, not the only correct order. What matters is that all seven steps happen before the tool touches a real mailbox, not after a data subject request forces the question.

1. 1

   Fix the lawful basis before the trial starts

   Decide why the AI is allowed to read this mail. Internal triage for staff usually rests on legitimate interests under Article 6(1)(f); an AI answering customer requests under a support contract usually rests on contract. Write the basis down before day one.

2. 2

   Ask for the DPA in the sales call, not after signature

   A processor that stalls on Article 28 paperwork until after you've paid is telling you where compliance ranks on its list. Get the DPA executed before any real mailbox connects, even for a pilot.

3. 3

   Get the sub-processor list in writing

   Ask by name: which company generates the drafts, which company hosts the search index, which company sends push notifications. "We use several AI providers" is not a list.

4. 4

   Confirm the transfer mechanism, not the marketing page

   If any processor sits outside the EEA, ask which Article 46 safeguard applies and when it was last reviewed. "We're GDPR compliant" is not an answer to an Article 46 question.

5. 5

   Map the data subject rights path before you need it

   Walk through, end to end, how you'd export or delete one employee's mail history in the tool if asked tomorrow. If the answer involves a support ticket and a guess, it isn't a process.

6. 6

   Set the breach-notice window in the contract

   Your 72-hour clock to the supervisory authority starts when you become aware, which may be later than when the vendor knew. Contract for a notice window that leaves you room to act.

7. 7

   Screen for a DPIA, and write down the answer either way

   Article 35 requires a Data Protection Impact Assessment where processing is likely to be high risk — large-scale monitoring, or automated decisions with legal or similarly significant effect are the usual triggers. Most internal-triage deployments won't cross that line, but the screening decision itself should exist on paper.

Red flags that mean the vendor hasn't done this work#

These show up in sales decks and security questionnaires more often than they should. None of them is disqualifying on its own, but two or more together mean the compliance work hasn't happened yet — and it's cheaper to find that out in a sales call than in a breach post-mortem.

• A "GDPR certified" badge with no scheme named. GDPR provides for certification mechanisms under Article 42, but none is in wide use — a badge with no certifying body behind it is a marketing claim, not a legal one.
• No DPA offered, or a claim that "we don't need one because we're just a tool." Anyone processing personal data on your behalf, under your instructions, is a processor under Article 28.
• A sub-processor list that names categories instead of companies, such as "leading AI providers."
• No clear answer to where data physically sits or which Article 46 mechanism covers a transfer.
• A privacy page that describes principles but never states an actual breach-notification timeline.
• A salesperson who answers a DPA question with a security-certification answer, or vice versa — the two documents cover different obligations, and conflating them is usually a sign nobody internally owns this.
• Pressure to sign before legal has seen the DPA, framed as a limited-time pricing offer. A real processor agreement doesn't expire on a sales deadline.

What we'd pick and why (honest)#

Run this checklist against any AI email vendor, including us — we build AI Emaily, and we're naming it here because a reader working through this list is probably weighing our product page too.

What we can tell you without overclaiming: every AI action that touches a send goes through an approval step by default in Copilot mode, and every action, approved or not, lands in an audit log — the kind of accountability record Article 5(2) asks a controller to be able to produce. OAuth tokens and any BYOK provider keys are encrypted before storage, which is a concrete answer to the Article 32 question above, not a marketing sentence. We don't train models on user mail content. Provider coverage spans Gmail, Outlook, and IMAP, so a mixed mailbox estate is one compliance conversation instead of three.

Our security page and privacy-model documentation describe the mechanism in more depth than a blog post should — encryption approach, what's stored where, and how the approval gate works end to end. That's where to verify anything in this paragraph before you rely on it, not this post.

What we won't tell you here is that we already have a specific DPA template or a published sub-processor list sitting ready — ask our team directly for the current one before you commit, the same way this guide told you to ask any vendor. We're not a law firm and can't write your lawful-basis memo or run a DPIA for you.

Right fit: a controller who wants one AI layer across an existing mailbox stack with an approval gate and an audit trail to point at Article 32, and who still owns the DPA conversation and the lawful-basis decision. Wrong fit: a team that needs a signed BAA for health data under HIPAA — that's a different framework, and we don't offer one — or a team that wants the vendor to make the lawful-basis call for them, which no vendor can honestly do.

Whichever vendor you pick, treat this as a review you repeat, not a form you file once. A sub-processor list changes when a vendor swaps LLM providers, a transfer mechanism changes when a court revisits an adequacy decision, and a lawful basis can stop fitting once the tool's scope grows past what you originally approved.