EU AI Act Article 50 for Email Support: What Disclosure Actually Requires

The question every support leader is suddenly asking

Do we have to tell customers the email came from AI?

Since 2 August 2026 the answer in the EU is mostly yes, and the interesting part is the "mostly." Article 50 of the EU AI Act is now enforceable by national market surveillance authorities, it applies whether or not your system is classified as high-risk, and it reaches companies that have never opened an office in Europe. Fines run to €15 million or 3% of worldwide annual turnover, whichever is higher.

What follows is a practical read of what that means inside a support inbox. It isn't legal advice, and a few of the questions below don't have settled answers yet. But the shape of the obligation is clearer than most support teams realise, and it's narrower in some places and wider in others than the summaries suggest.

What changed on 2 August 2026, and what didn't

A lot of teams stopped paying attention to AI Act deadlines after the AI Omnibus went through. That was a reasonable instinct applied to the wrong provision.

The Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and pushed the obligations for high-risk AI systems out to 2 December 2027. Article 50 was deliberately left out of that deferral. Its transparency duties applied on the original schedule, and enforcement powers came with them. The European Commission adopted its guidelines on the Article 50 transparency obligations on 20 July 2026, two weeks before the date, which tells you how tight the runway was.

One narrow grace period exists. Providers of generative systems already on the EU market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2). That's it. It doesn't extend to the disclosure duty for interactive systems, and it doesn't extend to anything a deployer has to do.

So if your support inbox has an AI agent replying to customers in Europe, the relevant question isn't whether the obligation has started. It's which paragraph of Article 50 you fall under, and whether you're the provider or the deployer.

Does Article 50 even apply to a support inbox?

This is where most published summaries wave their hands, because they were written about chatbots. Article 50(1) covers AI systems that interact directly with people, and the Commission's guidance sets out four cumulative criteria. All four have to be met.

1. The system has to qualify as an AI system under the Act's definition.
2. It has to be designed for a genuine two-way exchange with people, rather than merely collecting data or producing automated responses.
3. The interaction has to be direct — the AI communicates with the person, not through a human intermediary.
4. The interaction has to be with natural persons, whether consumers, professionals, or other users.

Read criterion two carefully, because it's doing more work than it looks. A traditional autoresponder that fires "we've received your ticket, reference #48211" is producing an automated response. It is not conducting a two-way exchange, and it isn't an AI system either. Nothing to disclose.

An AI agent that reads a customer's message, retrieves their order, decides what the actual problem is, and writes a specific reply, then handles the follow-up when the customer pushes back, is doing exactly what criterion two describes. Asynchronous timing doesn't rescue it. The exchange being spread across four hours instead of four seconds changes the reading experience, not the legal character.

The draft-mode question, which is the one worth understanding

Criterion three is the most useful line in the whole framework for support teams, and almost nobody is talking about it.

If a human agent reviews an AI-generated draft, exercises real judgement over it, and sends it under their own name, there is a human intermediary between the AI and the customer. On the face of the criteria, that setup sits outside the Article 50(1) disclosure duty, because the AI isn't communicating directly with the person.

Two cautions before anyone redesigns their stack around this. First, the review has to be real. The Commission has been explicit in a neighbouring context (the exemption for human review of published text under Article 50(4)) that superficial or purely formal checks like spell-checking don't count. A queue where agents click approve on 400 drafts an hour is not human review by any reading a regulator would accept. Second, the exception hasn't been tested, and building compliance on an untested reading of a criterion is a risk decision, not a compliance decision.

The honest position: co-pilot setups with genuine agent judgement have a defensible argument for sitting outside 50(1). Autonomous send does not, and shouldn't try to.

Provider or deployer? The split decides your obligations

Article 50 doesn't put every duty on the same party, and the distinction matters more for support teams than for almost anyone else, because most of you are buying rather than building.

A provider develops an AI system, or has one developed, and places it on the EU market or puts it into service under its own name or trademark. Providers carry Article 50(1), which is designing the system so people are informed they're interacting with AI, plus Article 50(2), the machine-readable marking of generated content.

A deployer uses an AI system under its own authority in a professional capacity. Deployers carry Article 50(3) for emotion recognition and biometric categorisation, and Article 50(4) for deepfakes and public-interest text.

If you licence an email agent from a vendor and run it on your support address, you're the deployer. The vendor is the provider, and the design-level disclosure duty is theirs. That is not a licence to stop thinking about it — you're the one whose customers receive the emails, and you should be asking the vendor to show you exactly how they satisfy 50(1) rather than assuming.

Where teams get caught out is building in-house. Wrap a general-purpose model in your own orchestration, put it into service under your own brand, and you have very likely made yourself the provider of an AI system, inheriting both 50(1) and 50(2). Several enterprise support orgs went down the build path in 2025 precisely to avoid vendor risk, and picked up a regulatory role in the process.

The "unless it's obvious" exception won't save your inbox

Article 50(1) carves out cases where it's obvious to the person that they're dealing with AI. It's a real exception. It just doesn't fit email.

The test is what an average person, reasonably well-informed and observant, would conclude. The Commission's guidance says the exception should be interpreted restrictively, on the grounds that it strips people of transparency they'd otherwise have.

Now picture the artefact. An email arrives from support@yourcompany.com. It's addressed to the customer by name, it references their order, it's written in your brand voice, and it's signed "Priya, Customer Care Team." Nothing about that says machine. Everything about it is engineered to say human, which is the whole point of the way most support email is written — including in our own guidance on auto-replies that don't sound robotic.

The better a support email reads, the weaker your obviousness argument gets. That's an uncomfortable trade-off, and it's the real one at the centre of this regulation.

What "clear and distinguishable" means in an email

Article 50(5) is the horizontal timing and format rule. Information required under paragraphs 1 to 4 has to reach the person in a clear and distinguishable manner, at the latest at the time of first interaction or exposure, and has to meet applicable accessibility requirements.

The guidelines define both halves. Information is clear where it's noticeable and easy to understand, including for people with accessibility needs. It's distinguishable where it's easy to identify as separate from the surrounding information and environment. Disclosure buried in terms and conditions, in a manual, or behind layers of menus does not meet the standard.

Apply that to an email and one common practice looks shaky immediately: the 8-point grey line in the footer, below the unsubscribe link and the confidentiality boilerplate. It's technically present. It's not noticeable, and it isn't distinguishable from the legal furniture it's sitting in.

What holds up better is disclosure in the body — in or immediately adjacent to the signature block, in the same type size as the message, in plain language. Something a person reads rather than scrolls past.

There's a second wrinkle specific to threads. The guidelines clarify that "first interaction or exposure" isn't a one-time event tied to the first person who ever encounters the system. It applies with respect to each natural person exposed to the output. A support thread routinely picks up new humans — the customer forwards it to their finance colleague, a second account contact joins, the ticket gets CC'd. A disclosure that appeared only in message one has, by message five, stopped reaching everyone it's meant to reach. Repeating a short line on every AI-sent message in the thread is the simpler and safer design.

The awkward part: machine-readable marking for plain text

Article 50(2) requires providers of systems generating synthetic audio, image, video or text to mark the outputs in a machine-readable format so they're detectable as AI-generated. For images there's watermarking. For text there is no comparable, reliable, interoperable technique, and everyone involved knows it.

The Act acknowledges this indirectly: implementation has to account for the specificities and limitations of different content types, the cost of implementation, and the generally acknowledged state of the art. The Code of Practice on Transparency of AI-Generated Content is the voluntary route for demonstrating compliance here. Signatories get a degree of legal certainty and predictability; non-signatories have to show compliance by other adequate means and should expect more requests for information.

A narrow exemption is also envisaged for outputs used in business-to-business or industrial contexts, subject to conditions in the guidelines. Whether a B2B support reply qualifies is exactly the kind of question that will get answered by practice over the next eighteen months rather than by reading the text today.

Practical takeaway for a deployer: this is your vendor's obligation, not yours. Ask them which route they've taken. If the answer is a blank look, that tells you something about the rest of their compliance posture too.

What Article 50 does not require

Compliance conversations tend to over-scope, and over-scoping has a real cost in customer experience. Four things the Article does not ask for.

• Naming the model. You don't have to tell customers which foundation model wrote the reply, who provides it, or how it was trained.
• Explaining the reasoning. There's no obligation under Article 50 to justify how the AI reached its answer. That's a different part of the Act, aimed at different systems.
• Labelling support email as public-interest text. Article 50(4) covers text published to inform the public on matters of public interest — politics, public health, justice, consumer safety and similar. A one-to-one reply about a delayed parcel is neither published nor a matter of public interest.
• Retroactive labelling. Content generated before 2 August 2026 doesn't need to be labelled after the fact, though the Commission encourages it where feasible.

Nor does the Act tell you the disclosure has to be cold. "This reply was generated by our AI assistant. If you'd like a person to look at it, just reply and ask." is compliant, human, and gives the customer something useful. Our transparency playbook for AI email responses goes deeper on the wording, which turns out to affect CSAT considerably more than the presence of the disclosure itself.

Why a US or Indian company is still in scope

Territorial reach catches people out. The AI Act applies to providers and deployers established outside the EU where the output of the AI system is used in the Union.

Your support agent is in Austin or Bengaluru. Your customer is in Dublin. The output, meaning the reply landing in that customer's inbox, is used in the EU. You're in scope, and the fact that you have no EU entity doesn't change it. Any company with European customers and an autonomous email agent should assume the obligation applies rather than hoping geography saves them.

What a compliant setup actually looks like

Stripped of the legal apparatus, the operational shape is not complicated:

• Every autonomously sent email carries a plain-language AI disclosure in the body, at message-text size, in or near the signature block.
• The disclosure repeats on each AI-sent message in a thread rather than appearing once at the start.
• The line is localised properly — a disclosure in English to a German customer is arguably neither clear nor accessible.
• The disclosure names a route to a human, which isn't required but materially softens the customer reaction.
• Every send is logged with the disclosure text as it appeared, so you can prove what a specific customer saw on a specific date. Our note on audit trails for AI email support covers what that record needs to contain.
• Genuine draft-review workflows are documented as such, with evidence that review is substantive rather than a rubber stamp.

Most of that is a fortnight of engineering. The audit evidence is the piece teams underestimate, because proving disclosure happened is a different problem from making it happen.

Where this is still genuinely unsettled

Three open questions, stated plainly rather than papered over.

Whether asynchronous email meets the "genuine two-way exchange" criterion in the same way live chat does hasn't been tested by any authority. The reading above is the cautious one. A narrower reading exists.

The boundary of the human-intermediary exception is undefined at the edges. Everyone agrees rubber-stamping fails and careful rewriting passes. The large middle ground has no answer yet: an agent who reads the draft, changes one sentence, and sends it.

And enforcement posture is unknown. Article 50 sits with national market surveillance authorities, which means twenty-seven of them, with different resourcing and different appetites. Early enforcement will probably concentrate on deepfakes and synthetic media rather than support inboxes. Probably is not a compliance strategy, but it's a reasonable input to how fast you move.

If you operate in regulated sectors, the sequencing matters more, since Article 50 stacks on top of obligations you already carry — our overview of compliance by industry maps where those overlap.

How Robylon approaches it

Robylon's email agents support a configurable disclosure line on autonomously sent replies, localised across 40+ languages, with the sent text captured in the audit log alongside the retrieved context and any actions taken. Human-in-the-loop workflows with confidence thresholds and tone-shift detection keep sensitive intents in a review path, which also gives compliance teams a documented basis for treating those flows differently. We'd rather customers configure this deliberately than inherit a default and discover later that it was the wrong one for their jurisdiction.

Ready to run email automation that discloses properly and logs the proof? Robylon AI resolves 60–80% of customer emails autonomously with agents that take action across Zendesk, Shopify, Salesforce and 60+ other integrations. See how Robylon handles email