EU AI Act Article 50: transparency by design

Article 50 of the AI Act has applied since 2 August 2026. It sets out transparency obligations for providers and deployers of certain AI systems, including generative and interactive AI systems and deepfakes (European Commission).

The deadline is behind us, which changes the question. It is no longer whether you will be ready in time. It is whether the platform you are running today already produces the record these obligations ask for — because if it does not, disclosure becomes something you bolt on to a system that was not built to carry it.

Here is what Article 50 asks of providers and deployers, why the practical bar for disclosure sits higher than a clause in your terms, and why transparency is native to a governed platform rather than a compliance layer added afterwards.

Article 50 splits its duties by role — the provider who builds the AI system, and the deployer who puts it in front of people.

Providers must ensure that systems intended to interact directly with people are designed so those people are informed they are dealing with an AI system — unless that is already obvious to a reasonably well-informed, observant and circumspect person in the circumstances. Providers of systems generating synthetic audio, image, video or text must also ensure outputs are marked in a machine-readable format and detectable as artificially generated, so far as technically feasible (Reg (EU) 2024/1689, Art. 50).

For systems that were already on the market before 2 August 2026, providers have until 2 December 2026 to meet the marking obligation specifically (Reg (EU) 2024/1689, Art. 111(4), as inserted by Reg (EU) 2026/1744).

The guidance summarises the deployer duties as informing individuals when they are exposed to emotion-recognition and biometric-categorisation tools, to deepfakes, and to text publications on matters of public interest published without human review or editorial control (European Commission).

The Dutch data-protection authority states the same principle in plain terms: from August 2026, specific transparency obligations apply to systems intended to interact with people or to generate content such as deepfakes — "Mensen moeten weten dat zij te maken hebben met een AI-systeem of door AI gegenereerde content" (people must know that they are dealing with an AI system or AI-generated content) (Autoriteit Persoonsgegevens).

This is the part most teams skip, and it decides which duties land on you.

If you deploy someone else's AI system inside your organisation, you are a deployer, and your duties are largely about telling affected people what they are dealing with.

But if you build an AI system and put it on the market or into service under your own name — including agents your team builds for internal or customer-facing use — you are likely a provider. Which provider duties then apply depends on what the system does: systems intended to interact directly with people must tell those people so, unless that is already obvious to a reasonably well-informed, observant and circumspect person; systems that generate synthetic audio, image, video or text carry the harder one — marking that output in a machine-readable, detectable format, so far as technically feasible.

Many organisations turn out to be both, in different systems, sometimes in the same product. An internal support agent your team assembled and exposed to customers is not obviously the same role as a vendor tool you switched on. Establishing which role applies to which system is the first practical step, and it is a legal assessment rather than a technical one.

The reason it matters for platform choice: the deployer duties are largely satisfied by evidence and disclosure, which a governed platform helps produce. The provider marking duty is an output-layer obligation you implement in the system you build — the platform does not discharge it for you. Knowing which you are tells you which of those two problems you are actually solving.

Where does that leave the practical bar for disclosure? The Regulation is explicit on both timing and manner: the required information must be provided "in a clear and distinguishable manner at the latest at the time of the first interaction or exposure" (Reg (EU) 2024/1689, Art. 50(5)).

A Dutch legal commentary on the Article 50 deadline draws the practical conclusion from that: a general reference to AI use in the general terms and conditions or on a website is in principle insufficient, because a term a user never encounters at first interaction cannot satisfy it (HVG Law).

The same commentary sets out what "visible" looks like in practice: information about the use of AI must be offered clearly, visibly and understandably — for example through labels, banners or badges that remain visible throughout the interaction with the AI system (HVG Law).

The pattern in both the guidance and the commentary is the same: a disclosure a person can actually see, at the moment it matters, plus a durable mark on generated content — not a paragraph buried where nobody reads it.

Read the obligations from an engineering standpoint and a shape appears. Every one of them is about a system being able to say what it is, and to leave a record of what it did — explicit notice at first interaction, a machine-readable mark on generated content, a disclosure a person can see. These are properties of how a system is built and operated, not paperwork you attach afterwards.

That is where a governed, source-available, self-hosted platform starts from an easier position. Not by meeting every duty for you — as above, the marking of generated content is yours to implement — but by making the evidence and control the rest of them need something the platform already produces:

• An audit trail. When interactions and sessions are recorded and exportable, you have a record of what the system did — the raw material an audit needs, in a form you can hand over.
• Access controls your organisation manages. Actions are governed by access controls tied to the user identities and roles your organisation manages.

You run it in your own environment. When the platform runs on infrastructure you control and its source is available for your team to read, you can see exactly how the system behaves — and demonstrate it — rather than trusting a black box to have done it.

None of that makes a deployment compliant on its own — whether a given system meets Article 50 is a legal assessment for your own counsel. The point is narrower and more useful: a transparency obligation is far cheaper to meet when transparency is already how the platform works. Governed-by-design means the record is there because the system was built to produce it.

And with the date now passed, that difference stops being theoretical. Teams whose platform already produces the record are answering questions. Teams whose platform does not are building the record retrospectively, from logs that were never meant to serve as evidence.

Read more on governed, self-hosted deployment in What is sovereign AI?.

Sources: European Commission — Guidelines on transparency obligations for providers and deployers of certain AI systems (announced 20 July 2026; page last updated 6 August 2026; English — the EC primary source); Autoriteit Persoonsgegevens — AI-verordening themed hub (Dutch DPA; current, news items 31 juli / 15 juli 2026); HVG Law — "AI Act implementatie: transparantieverplichtingen vanaf 2 augustus 2026" (Dutch; published 28 juli 2026, modified 31 juli 2026, Emelie Wesselink). Regulatory text cited from Regulation (EU) 2024/1689 (consolidated), Art. 50 and Art. 111(4) as inserted by Regulation (EU) 2026/1744. All sources accessed 13 August 2026. This post is general information, not legal advice.