AI email and GDPR: the 2026 compliance guide

A decade ago, the question didn't come up. You installed an Outlook plugin, turned on an extension, ticked the "I agree" box — and that was that. In 2026, the same decision triggers a full chain of obligations: controller responsibility, processing agreement, impact assessment, AI Act transparency, data hosting, extraterritorial transfers. An AI email assistant is no longer a piece of software like any other: it is a processing of personal data that reads every incoming and every outgoing email.

Two major texts now govern these deployments. The GDPR, in application since 2018, remains the underlying matrix. The AI Act, adopted in 2024, entered into application on 2 August 2026 for most of its general provisions. Added to these two texts is a geopolitical reality: the US CLOUD Act, which allows extraterritorial access to data held by operators subject to US law, regardless of the physical location of the servers. Three frameworks that interlock, sometimes overlap, and leave the controller with the burden of demonstrating compliance.

This guide is aimed at DPOs, executives, CIOs, lawyers and accountants who must pick an AI email assistant in 2026 without making a mistake. It sets out the legal framework, describes the actual processing performed by an AI email assistant, distinguishes compliant architectures from risky ones, and offers a 7-question DPO checklist to arbitrate.

1. Why AI email raises specific GDPR questions

A "classic" email processing operation — Outlook, Gmail, Thunderbird — has been governed by the GDPR since 2018. Address, content, attachments: they are personal data as soon as they concern an identified or identifiable person. Professional mail falls under the controller (the company), with its usual duties of information, security and limited retention.

Adding an AI layer does not change the base. It stacks processing operations on top of it. Three specificities make the matter more complex than a mere additional use case:

Content leaves the company perimeter

Without AI, an email sent from an Outlook workstation to an internal Exchange server (or to Microsoft 365) stays inside a contractualised perimeter, whose sub-processing regimes have been documented for years. With an AI assistant, at every click on "Generate", the content of the email — subject, body, thread history, sometimes attachments — leaves that architecture to join the model's servers. It is an additional data flow, with its own sub-processing, its own transfers, its own risks.

The processing is a "processing of processing"

The AI does not merely convey data: it reads it, understands it, produces an output. That output may be a drafted reply, a summary, a classification, an extraction of a deadline. Each output is a secondary processing, derived from the original content, potentially retained, potentially reused to train the model. The purpose changes, the legal basis must be requalified, the information owed to data subjects may evolve.

The recipient never consented to anything

When you reply to a client, the AI reads that client's email. That client, a data subject within the meaning of the GDPR, has not consented to their writing being fed into a third-party AI model. It is the most delicate specificity — and the one that triggers the impact assessment obligation in most serious professional cases. The CNIL indeed reminded in April 2024 that the processing of content written by third parties by a generative AI constitutes a full-fledged processing activity.

2. What the CNIL says about AI in 2026

The CNIL is the reference authority in France on these topics. Its doctrine has become clearer in several waves since 2023.

The April 2024 recommendations

In April 2024, the CNIL published a series of practical fact sheets dedicated to generative AI systems. The essential points for an email assistant:

• Training a model on personal data constitutes a separate processing activity, with its own purpose and its own legal basis — it cannot be silently bundled into the usage contract.
• Legitimate interest can ground the professional use of drafting assistance, provided a serious balancing test is carried out.
• Expected technical measures include minimising data sent to the model, limiting retention, and traceability of accesses.
• An impact assessment (DPIA) is strongly recommended for any organisation-wide deployment.

Interaction with the AI Act since 2 August 2026

Since 2 August 2026, the EU AI Act has been in application for its general provisions. The CNIL has been designated in France as one of the authorities competent for its supervision, alongside other sectoral regulators depending on cases. In practice, an AI email assistant will be examined from two angles: GDPR compliance (personal data processing) and AI Act compliance (transparency, risk classification). The two texts apply together, without one absorbing the other.

3. EU AI Act: what becomes mandatory

EU Regulation 2024/1689 ("AI Act") was adopted in 2024 after several years of negotiation. Its architecture rests on a classification of AI systems into four risk levels, each with its own obligations.

The four risk levels

Where an AI email assistant sits

An assistant that drafts, summarises or sorts emails sits in limited risk. It is a generative AI system applied to a common professional use, without sensitive profiling nor high-impact automated decision-making. The main obligations stem from article 50 of the regulation: information on the automated nature of the system, marking of generated outputs when they are disseminated to the public.

Beware of the shift to high risk. The same engine, used to sort incoming CVs on a jobs@ address, to automatically rate employees based on their emails, or to make decisions on sensitive client files (health, credit, insurance), would fall into the higher category with much more constraining obligations. The deployment matters more than the software.

The 2026-2027 deadlines

The regulation provides for a staggered application. The prohibitions of unacceptable risk entered into force in February 2025. The general provisions, including article 50 on transparency, have applied since 2 August 2026. Obligations bearing on high-risk systems listed in Annex III (HR, education, credit scoring, access to public services) also apply from 2 August 2026. Those on high-risk systems listed in Annex I (products already subject to an EU harmonisation legislation — medical devices, toys, elevators, etc.) will enter into application on 2 August 2027. For an AI email assistant in limited risk, compliance is due today.

4. The 4 GDPR processing activities hidden in an AI email assistant

This is the part underestimated by most deployments. Installing an AI email assistant does not activate one but several distinct processing operations, each with its own purpose, legal basis, retention period. Identifying them is what makes for a correct record and a useful DPIA.

Processing 1 — Sending content to the model for generation

At every click on "Generate", the email content (subject, body, thread history, sometimes attachments) is transmitted to the model. Purpose: drafting assistance. Usual legal basis: legitimate interest of the employer for common professional use. Sensitive points: third-party content (the incoming mail I process is written by someone who did not consent), recipients of the transfer (model operator, potential sub-processors), post-processing retention (should be zero by default).

Processing 2 — Learning the user's writing style

Assistants that learn your writing style — this is a central use in 2026 — analyse your outgoing email history to build a personal writing profile. Purpose: personalisation. Legal basis: legitimate interest or consent, depending on the depth of the profile built. Sensitive point: outgoing emails contain third-party data (recipients, contents). Our detailed article on how AI learns the user's writing style describes the technical mechanism and the associated guarantees.

Processing 3 — Contact profiles (per-correspondent personalisation)

The most advanced assistants build a profile per contact: tone adopted with this person, exchange frequency, relational history. Purpose: adaptation per recipient. Legal basis: legitimate interest. Sensitive point: this is the broadest processing — every professional contact of the user thus sees a profile being built on them, without being directly informed. Collective information (legal notices, privacy policy) becomes important.

Processing 4 — Measurement and improvement metadata

Usage metadata (number of generations, acceptance rate, response time, corrections applied) generally feed a product analytics layer. Purpose: measurement and continuous improvement. Legal basis: legitimate interest, with expected anonymisation or pseudonymisation. Sensitive point: the boundary between metadata and personal data can blur if metadata makes it possible to reconstruct an individual's patterns.

5. EU vs US hosting: why it changes everything

This is the first point your DPO will question. Where are the servers that host the model? The question sounds simple, the answer is not — because physical hosting is only one of the relevant criteria.

Three questions to disentangle

• Where are the servers? Physical location. A vendor can operate from European datacentres while being a US-law company.
• Under which jurisdiction is the vendor? A vendor incorporated in the United States is subject to US law, even if it physically operates in Europe.
• Are there transfers to a third country? The vendor's sub-processors, administrative access, backups can create less obvious transfers.

The post-Schrems II EDPB framework

The Schrems II decision by the CJEU in 2020 invalidated the Privacy Shield between the EU and the United States, imposing case-by-case assessment of transfers to third countries. The European Data Protection Board (EDPB) published guidelines detailing transfer impact assessments ("TIA"). The EU-US Data Privacy Framework (DPF), adopted on 10 July 2023 through an adequacy decision of the European Commission, restored a basis for certain transfers to self-certified US companies. But the legal debate remains open: several appeals challenge the robustness of this framework, along the same reasoning that had led to the fall of the Privacy Shield.

Strict EU hosting: what it means

"Strict EU hosting" designates an architecture where the vendor is incorporated in the European Union, servers are physically in the EU, operational sub-processors are themselves in the EU, and no non-EU administrative access exists. This is the only configuration that fully takes the setup out of scope of foreign extraterritorial access laws. See the 4 France hosting configurations available in 2026 for an AI email assistant for the detailed analysis (SecNumCloud, French hoster without label, hyperscaler with a France region, sovereign hosting via a Mistral EU model) and the associated legal comparison.

6. The CLOUD Act: the invisible legal risk

This is the most misunderstood topic — and probably the most important for professions covered by professional secrecy.

What the CLOUD Act actually says

The Clarifying Lawful Overseas Use of Data Act was adopted in the United States in 2018. It authorises US judicial authorities to compel an operator subject to US law to produce data it holds, regardless of the physical location of that data. A company incorporated in the United States, or a subsidiary controlled from the United States, can therefore be compelled to hand over to US authorities data hosted on European servers.

The concrete mechanism

A US judicial authority issues a warrant targeting an operator subject to the CLOUD Act. The operator must comply, on pain of internal sanctions. It is generally not required to inform the end user, nor the European regulator. The conflict with the GDPR is head-on — article 48 GDPR conditions the recognition of a foreign judicial decision requesting a data transfer on the existence of an international agreement such as an MLAT (Mutual Legal Assistance Treaty). Outside this framework, the US operator ends up having to choose between violating US law or European law.

Who is actually exposed

The major US hyperscaler cloud platforms and the leading US generative AI model providers are legally subject to the CLOUD Act, regardless of the location of their servers. This is true for any operator incorporated in the United States, on the same footing as for the major transatlantic cloud hosting providers. European vendors (Mistral, OVH, Scaleway, others) are not — unless they depend contractually on a US operator for their underlying infrastructure.

Practical impact for professional email

For everyday use, the probabilistic risk is low: CLOUD Act warrants target criminal cases, not mass reading of ordinary correspondence. For professions covered by strict professional secrecy (lawyers, accountants, physicians, HR on sensitive files), the legal risk exists and must be documented in the DPIA. Our detailed analysis lays out the real risks of the CLOUD Act for your professional mailbox, with documented scenarios and available legal remedies.

7. Sub-processing and DPA: the contract your DPO must require

The DPA (Data Processing Agreement) is the central document in the relationship with the AI vendor. Without a proper DPA, compliance is not achieved — regardless of the technical seriousness of the vendor. Article 28 GDPR precisely governs this contract.

The 8 mandatory items (art. 28 GDPR)

1. The subject-matter and duration of the processing
2. The nature and purpose of the processing
3. The type of personal data processed
4. The categories of data subjects
5. The obligations and rights of the controller
6. The processor's commitment to confidentiality, security measures, and assistance in case of breach
7. The conditions for engaging a sub-processor (authorisation, information)
8. The return or destruction of data at the end of the contract

Specific clauses to require in 2026 on an AI DPA

Beyond the 8 classical items, an AI assistant DPA in 2026 must include specific clauses your DPO must check line by line:

• Explicit no-training mode — clause written in black and white: transmitted data is not used to train the general model, third parties, or future models
• Post-request retention period — ideally zero (stateless processing), otherwise a precise and short duration
• List of downstream sub-processors — named, located, with their jurisdiction and role
• Breach notification — delay (often 24 h), channel, format
• Cooperation for DPIA and rights requests — the vendor commits to providing the technical elements needed
• No non-EU administrative access for "EU sovereignty" DPAs
• Reversibility and export — ability to retrieve data at any time, in a standard format
• Professional liability insurance covering AI processing-related incidents

For a technical reading of how these commitments translate at product level, see our detailed privacy policy.

8. Sensitive use cases by profession

Generic compliance is not enough in sectors with strong constraints. Here are the points of attention by profession — each adds a layer to comply with on top of the GDPR/AI Act base.

Lawyers — absolute professional secrecy

The professional secrecy of lawyers (article 66-5 of the French law of 31 December 1971) is public order. It covers lawyer-client correspondence, whatever the channel. Using an AI assistant that routes confidential correspondence to a third-party server creates a direct problem — all the more so if that third party is subject to a foreign jurisdiction likely to request access. The French National Bar Council (CNB) published in 2024 recommendations on the use of AI in law firms that go in this direction.

Accountants — professional secrecy and tax data

Article 21 of the 1945 French ordinance imposes on accountants a professional secrecy close to that of lawyers. The data processed (balance sheets, client accounts, tax elements) is particularly sensitive. The Order of Accountants has been raising awareness since 2024 on the question of choosing AI tools. The selection grid systematically favours architectures under EU jurisdiction.

Healthcare and HR — sensitive data under article 9 GDPR

Health data and certain HR data (ethnic origin, religious or trade-union opinion, sexual orientation, biometrics) fall under article 9 GDPR, with a principle of prohibition and strict derogatory bases. An email assistant that could read this content must be configured with reinforced guarantees: end-to-end encryption, strict minimisation, logical isolation, possibly client-side pre-filtering.

Banking and insurance — banking secrecy and AML/CFT

Financial institutions combine banking secrecy, AML/CFT (anti-money laundering / counter-financing of terrorism) obligations and supervision by the French Prudential Supervision Authority (ACPR). Using an AI assistant must be compatible with traceability, regulatory archiving and auditability obligations. Large banks have generally adopted internal architectures or very restrictive framework agreements with major vendors.

9. The 7-question DPO checklist

Here is the concrete tool. Seven questions to ask any AI email assistant vendor before any deployment — each eliminatory if the answer is not clear and documented. This checklist complements our broader guide on how to choose an AI email assistant.

Question 1 — Where are the servers hosting the model physically located?

Expected answer: precise location (EU, US, other), with country. A vendor answering "in the cloud" or "on AWS" without more precision is eliminatory.

Question 2 — Under which jurisdiction is the vendor?

Expected answer: country of incorporation of the parent company, relevant subsidiaries, applicable jurisdictions. A vendor incorporated in the United States remains subject to the CLOUD Act even if it operates in Europe.

Question 3 — Are my emails used to train the model?

Expected answer: no, with a written DPA clause. Any evasive or conditional answer ("in general no", "with your consent") must trigger a thorough review.

Question 4 — What is the post-request retention period?

Expected answer: ideally zero (stateless), otherwise a precise duration justified by a clear operational purpose (typically a few days for technical debugging). Beware of application logs that may keep data longer.

Question 5 — Is a GDPR article 28 compliant DPA provided?

Expected answer: yes, with prior delivery for reading by your DPO. Any reluctance to provide the DPA upfront is eliminatory — the signature must not be the first reading.

Question 6 — Is a template DPIA provided?

Expected answer: yes, with a reusable and adaptable template. The DPIA remains your responsibility (controller), but a serious vendor provides the technical building blocks (processing description, security measures, balancing elements).

Question 7 — Can I export and delete my data at any time?

Expected answer: yes, with a documented procedure and maximum delay. Portability and the right to erasure (articles 17 and 20 GDPR) are rights, not options — a vendor who does not clearly document them is a vendor to rule out.

10. The Neston approach to compliance

Our architecture has been designed to meet these requirements in the standard configuration, without the client having to negotiate point by point. Emails remain on the client's Microsoft infrastructure (Outlook or Exchange) — we do not host the emails. Reading by the model happens only at the moment of user-requested generation, and content is not retained after processing. No-training mode is enabled by default on all plans.

For professions under reinforced secrecy — lawyers, accountants, physicians, HR on sensitive files — an optional Mistral EU routing is available in one click. It routes generation calls to a model hosted in the European Union, under strict EU jurisdiction, outside the scope of the CLOUD Act. It is an option, not a requirement: each user configures according to their own risk profile and the recommendations of their DPO.

We provide the article 28 compliant DPA, the DPIA template adapted to an AI email assistant, a ready-to-fill record entry, and a detailed privacy policy. Human validation before sending is a non-negotiable product constraint: no automatic sending function exists. To dig further, our manifesto lays out the Neston vision on AI sovereignty and the underlying reasons behind these architectural choices.

11. Frequently asked questions (FAQ)

12. In summary: the key points to remember

• Two cumulative frameworks — GDPR (legal basis, DPA, record, DPIA) and AI Act (limited risk, transparency art. 50) apply together
• An AI email assistant = 4 distinct processing activities: sending to model, style learning, contact profiling, metadata
• The vendor's jurisdiction matters more than the servers' location — the CLOUD Act sees to that
• GDPR article 28 DPA: 8 mandatory items + AI-specific clauses (no-training, named sub-processors, reversibility)
• DPIA required in most professional cases, using the April 2024 CNIL template
• 7-question DPO checklist — each answer must fit in three clear sentences, otherwise eliminatory
• Sensitive professions (lawyers, accountants, healthcare, HR, banking) — reinforced configuration required, often with a model under strict EU jurisdiction
• Sanctions: up to EUR 20 M or 4% of turnover (GDPR) and EUR 35 M or 7% of turnover (AI Act) — not counting reputational and civil liability impacts

The GDPR compliance of an AI email assistant is neither a mystery nor a tick-box exercise. It is structured work: identify the processing activities, choose a vendor whose guarantees hold at the contractual level, document the deployment in the record and the DPIA, inform the data subjects. Done properly, this work takes a few days per deployment — and covers the organisation for years to come.

📚 Read more

• France hosting for an AI email assistant — The complete guide
• CLOUD Act and professional email: the real risks
• How to choose an AI email assistant — 2026 guide
• How AI learns your email writing style
• The Neston manifesto: sovereignty and human validation
• Detailed privacy policy
• Mistral AI + Outlook: the 2026 guide (French GDPR-ready plugin)
• Automated decisions in business: what the Uber fine means (Article 22)
• Must you disclose an AI-written email? (AI Act Article 50)
• How long to keep business emails: the matrix by category

Article published August 24, 2026 · Updated August 25, 2026 · Reading time: 18 minutes · ≈ 4,520 words