EU AI Act and AI Email Tools: What Actually Applies

The short answer
Usually yes, but lightly. Buying an AI email assistant makes you a deployer, not a provider, and most obligations sit with providers. General drafting is not high-risk; using it to screen job applicants can be. As of August 2026 your live duties are Article 4 AI literacy and Article 50 transparency.
EU AI Act email tools obligations, mapped: you're a deployer not a provider, drafting isn't high-risk, and what actually applies from August 2026.
On this page
- 01The short answer: you are a deployer, not a provider
- 02Can a buyer accidentally become a provider?
- 03Does the Act reach you if you are outside the EU?
- 04Is an AI email assistant a high-risk AI system?
- 05The Article 6(3) filter, and its hard limit
- 06What changed in July 2026, and why most advice is stale
- 07What Article 50 transparency actually requires
- 08The criteria that actually matter when choosing
- 09Score it
- 10Worked example: three inboxes, three answers
- 11Red flags in vendor claims
- 12What we would pick, and who should pick something else
Most guides to EU AI Act email tools obligations start from the wrong question. They ask whether a product is compliant, as though the Act certifies software the way a safety mark certifies a plug. It does not.
Regulation (EU) 2024/1689 assigns duties to roles and classifies systems by intended purpose. Buy the same AI email assistant as the company next door and you can still end up with different obligations, because you use it differently.
This guide maps the Act onto an inbox: which role you occupy, when a drafting assistant becomes high risk, what is enforceable as of August 2026, and how to score a vendor.
The short answer: you are a deployer, not a provider#
The Act hangs duties off roles. Article 3(3) defines a provider as whoever develops an AI system, or has one developed, and places it on the market under their own name or trademark. A deployer, under Article 3(4), is whoever uses an AI system under their own authority.
When you buy AI email software, the vendor is the provider and you are the deployer. That split decides nearly everything. Risk management, technical documentation, conformity assessment, registration, post-market monitoring — that machinery sits on providers, and only when a system is high risk. A deployer's list is much shorter, and for a general drafting and triage assistant it is nearly empty.
| Role | Who it is | Core duties for a non-high-risk email assistant |
|---|---|---|
| Provider | The vendor that builds the assistant and ships it under its own name | Article 50 transparency; separate obligations if it also supplies the underlying model |
| Deployer | Your company, using the assistant under its own authority | Article 4 AI literacy; Article 50(4) disclosure only for deepfakes or published public-interest text |
| Out of scope | An individual using it for purely personal, non-professional mail | None — Article 2(10) excludes deployers who are natural persons acting non-professionally |
Can a buyer accidentally become a provider?#
Yes, but the bar is higher than people assume. Article 25(1) turns a deployer into a provider in three cases: you put your own name or trademark on a high-risk system, you substantially modify one already on the market, or you change a system's intended purpose so that it becomes high risk.
Writing your own prompts, rules and context files is none of those. Reselling an inbox assistant under your own brand is a different conversation, and worth a lawyer's hour first.
Does the Act reach you if you are outside the EU?#
Often, yes. Article 2(1)(a) covers providers placing systems on the EU market irrespective of where they are established. Article 2(1)(c) goes further, covering providers and deployers located in a third country where the output produced by the AI system is used in the Union.
Read that against an inbox and it is not exotic. A US company whose assistant drafts replies to customers in Germany is producing output used in the Union. The test is where the output lands, not where you are incorporated.
Is an AI email assistant a high-risk AI system?#
As a general drafting, triage and summarisation tool: no. Article 6 has two routes into high risk, and an inbox fails both by default. Article 6(1) covers AI used as a safety component of a product regulated under the Annex I harmonisation law — machinery, medical devices, vehicles. An email client is none of those.
Article 6(2) makes the eight use cases in Annex III high risk. Only one plausibly touches an inbox: point 4, employment and worker management.
Point 4 covers recruitment or selection — in particular placing targeted job advertisements, analysing and filtering job applications, and evaluating candidates in interviews or tests — plus decisions on promotion and termination, allocating tasks, and monitoring or evaluating performance and behaviour.
Read that against real inbox work. Drafting a reply, sorting a thread, summarising a week: none of it is described there. Auto-scoring inbound applications in a careers address and ranking candidates: that is filtering job applications, and it is exactly the described use.

The Article 6(3) filter, and its hard limit#
Even a system that lands in Annex III is not automatically high risk. Article 6(3) removes it where it poses no significant risk of harm and meets one of four conditions: it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing or influencing a prior human assessment absent proper review, or performs a preparatory task.
A draft that a person reads and sends fits condition (b) or (d) comfortably. That is the argument for approve-before-send as a compliance control rather than a convenience feature.
The filter has a hard limit: an Annex III system that performs profiling of natural persons is always high risk, with no derogation. Scoring people is where the argument stops working.
The filter is the provider's homework, not yours
What changed in July 2026, and why most advice is stale#
The Digital Omnibus on AI — Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026 — amended the AI Act. It did not repeal the high-risk regime; it moved the dates and softened Article 4. That matters, because it invalidated the single date almost every compliance guide was built around.
| Obligation | Applies from | Changed by the Omnibus? |
|---|---|---|
| Article 5 prohibited practices | 2 February 2025 | New prohibition added for AI-generated CSAM and non-consensual intimate imagery, transitioning to 2 December 2026 |
| Article 4 AI literacy | 2 February 2025; supervised from 2 August 2026 | Yes — reworded from ensuring literacy to supporting its development |
| General-purpose AI model duties | 2 August 2025 | No — legacy models have until 2 August 2027 |
| Article 50 transparency | 2 August 2026 | No — marking for existing systems runs to 2 December 2026 |
| Annex III high-risk obligations | 2 December 2027 | Yes — moved back from 2 August 2026 |
| Annex I high-risk obligations | 2 August 2028 | Yes — moved back from 2 August 2027 |
Check the date on anything you read, including this page
What Article 50 transparency actually requires#
Article 50 is the one that went live this month, and the one email-tool content mostly skips. It binds providers and deployers differently.
Article 50(1) requires providers of systems designed to interact directly with people to make sure those people know they are dealing with an AI system, unless that is obvious. A support chatbot is squarely in it; a drafting assistant you review privately is not interacting with the recipient at all.
Article 50(2) requires providers of generative systems to mark synthetic audio, image, video or text in a machine-readable, detectable format. It carves out assistive editing functions that do not substantially alter the input data — which is where a rewrite-my-sentence tool and a write-this-from-scratch tool part company.
Article 50(4) is the deployer's paragraph, and narrower than the panic suggests: deepfakes, and AI-generated text published to inform the public. Ordinary business email is neither.
The criteria that actually matter when choosing#
Because the Act does not certify products, a compliance comparison has to be a comparison of controls. These six change your exposure, roughly in order of how much work they do.
- Role stated in writing. The terms should say the vendor is the provider and you are the deployer, and name the model suppliers.
- Human approval before send, on by default. This does the most regulatory work: it keeps drafting a preparatory task under Article 6(3), and it is what Article 26(2) oversight looks like in practice.
- An exportable action log. Article 26(6) requires deployers of high-risk systems to keep generated logs for at least six months. A log you can read but not export will not survive a request.
- A documented Article 6(3) assessment, if the vendor sells into recruiting or HR.
- Article 50 posture. Does the vendor mark generative output machine-readably, and say which features generate versus assist?
- No training on your mail, in the contract. Not an AI Act duty as such, but the fastest way to fail the GDPR review running alongside it.
Score it#
Weight the first three heavily. They keep paying off if your use later drifts toward Annex III, and they are checkable in a trial rather than a questionnaire.
| Criterion | Weight | What a pass looks like |
|---|---|---|
| Provider role and model suppliers named | High | Terms name the vendor as provider and list model subprocessors |
| Approve-before-send on by default | High | Nothing sends without a human action, per connected account |
| Exportable action log | High | Machine-readable export covering six months of agent actions |
| Documented Article 6(3) assessment | High if you recruit, none if you do not | Vendor supplies the written assessment on request |
| Synthetic-content marking | Medium | Vendor states which features generate and which assist |
| No model training on customer mail | Medium | Written into the contract, not just a marketing page |
Worked example: three inboxes, three answers#
A founder in Berlin drafting investor replies is a deployer of a system that is not high risk under any Annex III entry. The live duty is Article 4: whoever uses it should understand what it does and where it fails. A short briefing and a written note, not a programme.
A 40-person agency in Dublin triaging a shared support inbox gets the same answer, with one addition. If the tool also monitors or evaluates how staff handle threads, that is Annex III point 4 territory from 2 December 2027 — and Article 26(7) would require informing worker representatives and affected workers first.
A recruiting firm letting the assistant rank and shortlist applications is the case that genuinely changes. Filtering applications is the described use, ranking people trips the profiling bar in Article 6(3), and from 2 December 2027 the full high-risk stack applies — to the provider first, and to the deployer under Article 26.

Red flags in vendor claims#
- An AI Act compliant badge. There is no such certification for a non-high-risk system, and for a high-risk one the route is a documented conformity process, not a logo.
- A high-risk deadline of 2 August 2026. That date moved to 2 December 2027, and quoting it tells you when the page was last touched.
- Refusal to name model suppliers. You cannot assess Article 50 marking or your own transfer position without it.
- Fine figures quoted without an article number. Article 99 caps differ sharply: up to €35m or 7% of turnover for Article 5 prohibited practices, up to €15m or 3% for the operator duties Article 99(4) lists — Article 50 among them — and up to €7.5m or 1% for supplying incorrect information.
- An approval step that can be disabled globally at rollout. The control only counts if it survives the person who wants it gone.
The whole record can be one page
What we would pick, and who should pick something else#
For the reader this guide is actually for — a founder, an operator, a small team running an inbox in the EU or sending into it — this is a light-touch problem. Buy on the controls, not the compliance marketing, and weight approve-before-send and the exportable log highest.
We build AI Emaily, so treat what follows as an interested recommendation and check it yourself. It scores well on the two heaviest criteria: Copilot mode holds every reply for human approval before anything sends, Autopilot is gated rather than a default, and every agent action lands in an audit log with undo.
Voice matching runs from a Personal Context brain and per-client profiles you write, not a model trained on your mail. Those were trust decisions rather than legal ones, and they happen to be the controls Article 6(3) and Article 26(2) care about.
Where we lose, plainly: we do not hold an ISO/IEC 42001 certificate. Microsoft publishes ISO/IEC 42001 certification covering Microsoft 365 Copilot and several other Copilot services, with certificates available through its Service Trust Portal. If procurement needs a third-party AI management system certificate before a tool is approved, that is a real, checkable advantage we have no answer to. Buy the certificate.
And if your plan is to point an email assistant at inbound job applications and let it rank candidates, stop here. That use heads into Annex III point 4 from 2 December 2027, and needs a vendor acting as a high-risk provider — conformity assessment, technical documentation, registration, the whole of Chapter III. We are not building that, and neither are most inbox tools. Buy from an HR-tech vendor that says out loud it does that work.
Frequently asked
See it in AI Emaily
Keep reading
Sources
- Regulation (EU) 2024/1689 — the Artificial Intelligence Act (EUR-Lex)
- Regulation (EU) 2026/1744 — Digital Omnibus on AI, amending the AI Act (EUR-Lex)
- European Commission — AI Act Service Desk, article texts
- EU AI Act — article explorer
- ISO — AI management systems (ISO/IEC 42001)
- Microsoft — ISO/IEC 42001 certification scope for Copilot services

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.