AI Act Article 50: chatbot disclosure, synthetic content and deepfakes

A customer opens “Smart Support” and receives a fluent answer about a complaint. Is it a person, a rules-based bot or an AI agent? A reference to automation somewhere in the terms may leave that question unanswered at the moment it matters.

Article 50 of the AI Act addresses specific transparency situations. It has applied since 2 August 2026, independently of whether the system is classified as high-risk. For many products, implementation requires a change in the interaction or publication process, as well as legal documentation.

There is no single rule that every AI-generated item needs the same visible label. The obligation depends on the function, the organisation’s role and how the output is used.

Law and Commission materials checked as at 1 October 2026. The Commission’s July 2026 guidelines support interpretation; they do not replace the Regulation or binding judicial interpretation.

What you will learn

In brief

• Providers of systems intended to interact directly with people have an interaction-disclosure duty, subject to the statutory obviousness exception.
• Providers of systems generating synthetic content have a separate technical marking and detectability duty.
• Deployers have particular disclosure duties for emotion recognition, biometric categorisation, deepfakes and certain public-interest text.
• An interface notice does not automatically satisfy technical marking, or vice versa.
• Product terms can explain the service but cannot replace every required notice at the point of interaction or publication.

The dates: a narrow transition, not a general postponement

Article 50 applies from 2 August 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, added a specific transition in Article 111(4).

Providers of generative systems placed on the market before 2 August 2026 have until 2 December 2026 to comply with the technical marking obligation in Article 50(2). This does not postpone the whole of Article 50, all chatbot disclosure or every deployer obligation.

The Commission’s guidance also explains that content generated and published before 2 August does not need retrospective labelling. Map the relevant system, output and publication date rather than treating “our company used AI before August” as a blanket exception.

Four situations, different duties

1. Direct interaction with a person

Under Article 50(1), the provider must design and develop the system so people are informed that they are interacting with AI. The exception is where that is obvious to a reasonably well-informed, observant and circumspect person, considering the circumstances and use context.

2. Synthetic content generation

Under Article 50(2), providers of systems generating synthetic audio, images, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated.

The technical solutions must be effective, interoperable, robust and reliable as far as technically feasible. The assessment takes account of the content type, technical limitations, implementation costs and the generally acknowledged state of the art.

3. Emotion recognition and biometric categorisation

Under Article 50(3), deployers must inform people exposed to these systems. Personal data processing remains subject to the applicable data protection framework.

A transparency notice does not make a prohibited use lawful or remove other legal conditions. Assess the use and the notice separately.

4. Deepfakes and public-interest text

Article 50(4) addresses deployers using systems to generate or manipulate image, audio or video constituting a deepfake, and certain AI-generated or manipulated text published to inform the public on matters of public interest.

These are particular publication situations. They should not be collapsed into a rule that every internal AI summary or every AI-assisted text needs the same disclosure.

Put the interaction notice where the user meets AI

Article 50(5) requires the relevant information to be clear and distinguishable, provided at the latest at first interaction or exposure, and to meet applicable accessibility requirements.

For a chatbot, voicebot or customer-facing agent, assess the actual start of the conversation. Consider an assistant within SaaS, a voice-based complaint process, an agent arranging meetings or a digital adviser. The relevant notice should work in the channel and language the person uses.

A practical first sentence could be:

You are speaking to an AI assistant.

Depending on the process, the business may also explain limitations or offer human escalation. Those additions can be useful service safeguards, but Article 50 should not be described as universally requiring a particular escalation feature.

Test the notice in the real interaction. Is it visible before the person relies on the answer? Can a screen-reader user encounter it? Does it remain present after an interface redesign or a switch to voice?

Is “assistant” enough?

“Assistant” can describe a person as well as software. “Smart Support” does not clearly identify the technology either. Assess whether the artificial nature is actually obvious to the relevant user.

Consider the audience, appearance and length of the exchange, how closely the system imitates a person, the channel and language, and what users do on the basis of the response.

The more the system conducts correspondence or acts for the business in a human-like way, the less persuasive an unsupported assumption that “everyone will work it out” becomes.

Document an obviousness assessment where you rely on it. The exception is contextual, not created simply by giving the product a modern-sounding name.

A visible label and technical marking serve different purposes

A visible notice tells a person about AI. Machine-readable marking enables technical detection of an output’s artificial origin. One does not automatically accomplish the other.

For a generative product, ask:

• What marking method is supported for each content type?
• Are metadata, provenance credentials, watermarks or other signals involved?
• What happens on export, compression, format conversion or external publication?
• How is detectability checked?
• Who documents effectiveness, interoperability, robustness and reliability?
• What limitations arise from upstream model services?

Do not assume that adding “AI-generated” to a preview screen solves an unmarked exported file. Conversely, a technically marked file may still require a deployer’s disclosure in a relevant publication context.

Article 50(2) contains an exception for systems performing an assistive function for standard editing or not substantially altering the input or its semantics. Ordinary spelling correction or formatting should therefore not automatically be equated with generating new material. Review what the feature actually changes.

The Code of Practice on AI-generated content is a voluntary compliance-support instrument. The statutory duty itself is mandatory. Participation in a code and implementation of the actual legal obligation are different questions.

Deepfakes: adapted disclosure is still disclosure

The AI Act’s deepfake definition concerns AI-generated or manipulated image, audio or video resembling existing people, objects, places, entities or events and falsely appearing authentic or truthful.

A deployer using such content must disclose the artificial generation or manipulation. For evidently artistic, creative, satirical, fictional or analogous works, the disclosure can be adapted so it does not hamper display or enjoyment. That is not a complete exemption from disclosure.

Assess the content and publication context rather than assuming that every synthetic image is a deepfake. Where the definition is met, include disclosure in the publication workflow before release.

Public-interest text and meaningful editorial review

The text obligation concerns publication intended to inform the public on matters of public interest. There is an exception where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for publication.

A quick approval click should not automatically be described as meaningful review. Make the process capable of checking substance, facts and sources, and record:

• Who reviewed the material and their role.
• What was checked and which corrections were made.
• Who approved publication and holds editorial responsibility.
• Where the final version and approval history are kept.

The technical provider duty and the deployer’s publication duty remain separate. An editorial exception from one obligation does not by itself decide whether an upstream system must technically mark its outputs.

The Act also contains specific law-enforcement exceptions. Those narrow provisions are not a general commercial exemption for support agents or marketing tools.

A hypothetical case: a SaaS agent handles complaints

A SaaS company provides an AI agent to online shops. It reads the customer’s complaint, checks order information, proposes a remedy, sends a reply and grants a coupon in simple cases.

The interface says only “Smart Support”. The terms mention automation generally. The shop assumes the SaaS provider supplies all notices; the provider assumes the shop, as deployer, will add them.

The parties need to establish:

• Their roles for each function and intended use.
• The content and placement of the interaction notice.
• The operational point at which the agent escalates to a person.
• Responsibility for implementing and maintaining notices after UI changes.
• The evidence that the relevant obligation is met.

This is an illustrative scenario. A provider’s statutory responsibility cannot simply be transferred away by calling the customer a deployer. Contracts should allocate the implementation work while reflecting the actual legal roles.

Our deployer/provider guide explains why role and purpose need function-specific assessment. For the complaint process, the separate AI vendor and GDPR review also matters: transparency about AI does not settle personal data processing or automated decisions.

Put implementation into the supplier contract

“Each party is responsible for its own compliance” provides little operational help when a notice needs UI work, translated copy and information from the model supplier.

Specify intended use and user groups, roles for individual functions, interface requirements, supported marking methods, third-party limitations and responsibilities for copy, localisation, testing and maintenance.

Include a change process for the model, interface or use case. Acceptance evidence should show what was implemented and tested, rather than consist only of a signed general assurance.

Product, UX, marketing, support, security and procurement need the same description of the system. Legal drafting depends on those facts.

A practical review sequence

If the company does not know which systems its teams use, begin with the Shadow AI inventory and governance process.

Article 50 is implemented through the interaction, publication process and technical supply chain. Terms can explain those arrangements; the product must deliver them. Our technology legal services support role allocation, supplier contracts and implementation documentation. Contact us with the relevant feature and use case.

Primary sources

• AI Act, Regulation (EU) 2024/1689, particularly Article 3’s deepfake definition and Article 50.
• Regulation (EU) 2026/1744, including the new Article 111(4) transition.
• European Commission Article 50 guidelines, published 20 July 2026, page updated 31 July 2026.
• European Commission: Transparency obligations under Article 50, explanatory FAQs.
• Code of Practice on AI-generated content, voluntary support for compliance.