The Article 50 guidelines are final — what an AI disclosure actually has to look like

Since 2 August 2026, if your software talks to people, you have to tell them it is software. That is the short version of Article 50 of the EU AI Act — the transparency chapter — and on 20 July 2026 the European Commission adopted its final guidelines explaining what actually satisfies the duty.

A note on terms before we go further. The EU AI Act is the European Union’s regulation on artificial intelligence. A provider is the party that develops an AI system and puts it on the market under its own name; a deployer is the organisation using that system in its own operations. Most of what follows turns on which of those two you are, so it is worth holding both definitions in mind.

Why almost everyone read 2026 as a quiet year

The Digital Omnibus on AI — Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July — pushed the Act’s high-risk obligations back: stand-alone high-risk systems to 2 December 2027, high-risk systems embedded in regulated products to 2 August 2028. Those dates are settled law, not a proposal. That was widely reported, and reported accurately.

What travelled less well is that the deferral applied to the high-risk chapter and nothing else. Two things still landed on 2 August 2026: the Article 50 transparency obligations, and the Commission’s enforcement powers over general-purpose AI models. We wrote about the revised timeline in EU AI Act readiness: what actually changed in 2026, and the wider regulatory picture in the 2026 obligation stack. This article is about the piece that reaches ordinary business software.

The four triggers

Article 50 attaches to four situations. None of them is limited to high-risk systems, and a single product can hit more than one.

1. AI systems intended to interact directly with people — chatbots, virtual assistants, conversational agents. The people using them must be informed they are interacting with an AI, at or before the first interaction.
2. Synthetic content generation — systems that produce text, images, audio or video must mark their outputs in a machine-readable format and make them detectable as artificially generated or manipulated.
3. Emotion recognition and biometric categorisation — the people exposed to the system must be informed of its operation.
4. Deepfakes, and AI-generated text published to inform the public on matters of public interest — both must be disclosed as artificially generated.

The exceptions matter as much as the triggers, and they are frequently paraphrased into something broader than the text supports:

• The interaction disclosure is not required where it is “obvious from the point of view of a reasonably well-informed, observant and circumspect natural person” that they are dealing with an AI. There is also a law-enforcement carve-out.
• The marking duty does not bite where a system performs only an assistive function for standard editing — grammar correction is the canonical example — or does not substantially alter the input data or its semantics.
• For public-interest text there is no duty where there has been substantive human review and someone holds editorial responsibility.
• For deepfakes, disclosure is reduced for evidently artistic, creative, satirical or fictional work, and must be made in a manner that does not hamper the display or enjoyment of the work.

Who owes what

This is where most teams get stuck, and the guidelines are unusually clear about it.

The split is tidy on paper and awkward in practice, because it was written with a mental model of a vendor operating a service and a customer consuming it.

Self-hosting complicates that model rather than resolving it. When an organisation installs software on its own infrastructure, configures it, points it at a language model it selected, and publishes the resulting assistant to its own users, the question of who “puts the system into service under their own name” stops being obvious. Depending on how it is set up, the deploying organisation may take on provider-like responsibilities. That is not a gap in the Act so much as an interaction between the Act’s definitions and a deployment shape that is now very common.

We are not going to pretend the answer is settled, and you should be sceptical of any vendor who tells you it is for your case. The factors that actually bear on it are worth naming, because they are what your counsel will ask about: who determines the intended purpose, whose name the deployed system carries, who controls the interface the end user sees, and whether the deploying organisation has substantially modified the system.

Three disclosures that fail

The most useful part of the guidelines is what they rule out. On the interaction duty, the Commission is explicit that the information must be perceivable in the interaction itself.

Two design consequences follow, and they are cheap to implement if you decide early: the notice belongs at or before the first exchange, not in a footer or a settings panel; and it has to survive the ways people actually reach the system — embedded widgets, deep links into a conversation, and screen readers included.

The Code of Practice does not cover the chatbot duty

This is the point most coverage has missed, and it is worth stating plainly.

The voluntary Code of Practice on transparency of AI-generated content is aimed at the marking and labelling duties — machine-readable marking of synthetic content, and the labelling of deepfakes and public-interest text. It does not address the Article 50(1) interaction disclosure at all. If your exposure is primarily the chatbot duty, the Code was never the instrument for it, no matter how much attention its signing window attracted.

Three further facts about the Code, since it generated more noise than it deserved. The window for inclusion in the initial-signatories list closed on 22 July 2026 at 18:00 CEST. Signing remains possible at any time afterwards. And the Commission states plainly that signing is voluntary and not signing does not constitute non-compliance — non-signatories simply document and explain the alternative measures they rely on, and may attract more requests for information from market-surveillance authorities.

Interpretation is not statute

In practice, keep the two apart in your own documentation. “Clear and distinguishable” is the statutory standard. “A line in the footer does not count” is the Commission’s illustration of that standard. When you write your assessment, cite the first as law and the second as guidance, and you will be in a much better position if the reading later shifts.

Four questions to answer internally this week

None of these needs a lawyer to start, and all of them will make the eventual legal conversation shorter.

1. Which of our systems interact directly with people? The list is almost always longer than expected once you include embedded widgets, internal helpdesk bots and anything with a chat interface bolted on.
2. For each one, are we the provider, the deployer, or arguably both? Write down the reasoning, not just the conclusion.
3. Would a first-time user notice the disclosure? Not “is it present” — would they notice it. Ask someone who has never seen the product.
4. Does anything we ship generate content that ends up published? If so, the marking duty is a separate workstream from the interaction duty, with a separate owner.

If it helps to work through the classification questions in a structured way, our free EU AI Act risk classifier walks the decision tree for a system you describe. It stores nothing and requires no sign-up. It is a starting point for a conversation with your counsel, not a substitute for one.

Not legal advice.

Frequently asked questions

← All posts