
AI · 18 October 2026 ·

Translated with AI. This article was translated by an AI model from an article by Twentynext in another language, and the translation was checked automatically against the original. Verify figures and sources before acting on them. See our disclaimer.
The AI Act follows a risk-based approach: the higher the risk of a system, the stricter the rules. The Autoriteit Persoonsgegevens (the Dutch Data Protection Authority) summarises it as follows: applications with an unacceptable risk are prohibited, high-risk systems must meet stricter requirements and, in addition, transparency rules apply. If you do not deploy a high-risk system, you may get the impression that the file can be closed. That conclusion is premature.
The transparency obligations in Article 50 are not a residual category for everything with a “lower risk”. They apply to specifically defined systems and output, and these appear in everyday applications: chatbots, digital service desks, assistants and AI-generated content. Whether that applies to you depends on your role, the application and the exceptions in the legal text. Below you will read what Article 50 regulates in outline, since when it has applied and how you determine what you need to arrange.
Article 50 brings together various information, marking and disclosure obligations. The common denominator is that people should not encounter AI or AI output without being aware of it. The FAQ on generative AI from the Rijksoverheid (the Dutch central government) describes that Article 50 distinguishes between obligations for providers and deployers, and between four types of AI systems.
Important to know in advance: Article 50 is not a general rule for everything that is not high-risk. The European Commission refers to transparency obligations for providers and deployers of certain AI systems. Which systems and which output these are is delineated in the legal text.
The main points, with the caveat that each obligation has its own conditions and exceptions:
This is a summary, not the legal text. Always have the application to your situation legally assessed against the Regulation itself.
The Vlaamse overheid cites 2 August 2026 as the date from which the transparency rules in Article 50 apply. Digitale Overheid cites the same month for the transparency obligations for certain AI systems, noting that this mainly concerns generative AI systems.
The Commission has initiated guidelines and a code of practice to enable compliance with these obligations. The frequently asked questions on Article 50 refer to that code of practice for generative AI systems. According to the Commission, providers and deployers who do not sign up to it must demonstrate compliance in another way. It is not a general code for everything you do with AI.
Whether transitional provisions apply to your systems, and what exactly the code of practice requires of you, you should check directly in the current version of the Commission FAQ and the guidelines. We deliberately do not repeat those details here; they are too precise to take over second-hand and may change. So before you take decisions, check that you are looking at the most recent version.
The practical significance: if you are reading this, Article 50 is already in force. The question is no longer whether you are preparing, but whether you comply now.
The Regulation distributes obligations across roles. Digitale Overheid summarises this as rules for developers of AI models and systems and for organisations that use those systems. The Dutch translation of the Regulation uses the terms “aanbieder” (provider) and “gebruiksverantwoordelijke” (deployer); in its Dutch FAQ, the Commission uses the term “exploitant” for that second role.
The core of the distinction: a provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses a system under its own responsibility. The exact definitions, including the conditions and exceptions, are set out in the Regulation itself and are decisive.
The marking obligation for generated content is aimed at the provider. The disclosure obligation for deepfakes and public texts is aimed at the deployer. Both are subject to the conditions and exceptions mentioned earlier.
The division of roles may be less clear-cut in your situation than this classification suggests. If you build an application on a purchased language model and offer it to citizens or customers, the questions include whether you offer the system under your own name or trademark and whether you substantially modify it. Which role follows from that, you determine on the basis of the definitions in the Regulation and together with a lawyer.
The FAQ on generative AI and the AI Act on algoritmes.overheid.nl addresses, among other things, the division of roles in generative applications and the transparency obligations. For public-sector organisations it is a useful starting point; for other organisations it also helps in formulating the right questions for your lawyer.
For most decision-makers, this is the most tangible point. If your organisation uses AI in digital service desks, chatbots or assistants, it must be clear to citizens that they are communicating with AI, as the Vlaamse overheid summarises Article 50. The legal text provides an exception for situations that are already obvious from the context to a reasonably well-informed, observant and circumspect person.
The Commission refers to four cumulative criteria from the guidelines. One of these: the system must be designed for a genuine two-way exchange with people, rather than merely collecting data or providing automated responses. A simple selection menu is therefore different from a conversational assistant; where exactly the line lies, you check against the guidelines.
Three points to check:
Where is the notice? According to the Commission FAQ, providers must design and develop the system in such a way that the persons concerned are informed that they are interacting with an AI system. Whether a sentence in general terms and conditions or a privacy statement meets that requirement is something you should have assessed. Do not assume it.
Is the exception interpreted too broadly? “Everyone knows this is a bot” is an assumption. With an assistant that has a human name and a natural conversational tone, that assumption is far from self-evident. Do not rely on the exception without a legal assessment.
Is the handover moment clear? When a conversation passes from AI to an employee, or the other way round, it is sensible for the user to notice. Whether and how Article 50 requires this is something you should have legally assessed together with the rest of your application. Regardless of that, we recommend it as a design choice, because it aligns with the purpose of the transparency obligation.
Do not exclude internal applications in advance. The legal text refers to natural persons; whether an internal assistant falls under the obligation is determined using the same assessment as for external applications.
Here, two obligations overlap that you need to consider separately.
The first is technical and rests primarily on the provider: generated or manipulated text, image, audio or video must be marked and detectable, within the conditions and exceptions of Article 50(2). If you are a deployer, you check this through your choice of supplier and through the way you implement the system. Ask your suppliers specifically how they meet this obligation, whether they are signing up to the code of practice and whether transitional provisions apply to their system.
If your organisation integrates or modifies the system itself, for example by building a language model into its own application, it is not self-evident that you remain only a deployer. Have a lawyer assess whether this also gives you the obligations of a provider, including the marking obligation.
The second obligation is organisational and is aimed at the deployer: disclosing that content has been artificially generated or manipulated in the case of deepfakes and AI-generated text on matters of public interest. According to the Vlaamse overheid, it must be clear “in certain cases” that content has been (partly) generated by AI; which cases these are follows from the legal text.
For text, the exception applies in the case of human or editorial control combined with editorial responsibility of a natural or legal person. Whether and how you must be able to demonstrate that these conditions have been met is something you should have legally assessed. Regardless of that outcome, it is sensible to record who carries out the review and who bears responsibility as soon as you wish to rely on this exception.
In practice, this comes down to a content policy with three questions per publication: has AI been used here, to what extent, and what do we communicate about it? That policy must also apply to departments that are currently working with generative tools on their own initiative.
With transparency obligations, a few risks typically come into play. Whether they apply to you, you will only know after an inventory; that is the reason to look into them.
No overview. AI applications may be embedded in purchased software or set up by teams themselves, often without central visibility. Without an inventory, you do not know where AI communicates with people or generates content, and compliance is guesswork.
No owner. Transparency touches on communications, legal affairs, IT and the process owner. As long as it remains “a bit of everyone’s job”, little happens.
Compliance detached from design. The Commission FAQ links the obligation in Article 50(1) to the design and development of the system. If you treat transparency as a notice added afterwards to an existing chatbot, have it assessed whether that meets this requirement. Apart from that legal question, our recommendation is to include transparency in the design from the outset; how much work that involves depends on your application.
The Autoriteit Persoonsgegevens advises organisations, as provider or user, to identify which AI systems are involved and which risk group they fall into. The regulator emphasises that this check is the responsibility of the organisation itself.
Also bear in mind that the AI Act is not the only framework that may apply. Whether and how the GDPR applies to the data your application processes, and what that means for communication with data subjects, is something to put to your privacy lawyer or data protection officer.
Allow for time. How long an inventory takes depends on the number of applications and on how much purchased software you need to review. Plan it as a project with an owner and an end date rather than as a sideline for one of the departments involved.
Start with a list. Within two weeks, ask every team that handles customer contact, communications or service delivery to answer four questions:
That list is not a compliance document. It is the overview you need in order to determine with a lawyer where you do and do not comply, and to determine with your teams what needs to be changed. Without that list, every conversation about Article 50 remains abstract.

Sixteen questions, seven minutes, and an instant spider chart showing your strongest and weakest dimension. No e-mail address needed to see the result.

AI · 20 October 2026
A model that performs well in testing can deliver less than expected in practice. Learn why trust drives AI value in government and how to measure it.
Read the article →

AI · 18 October 2026
An honest checklist: six questions that determine whether your organisation is ready for AI, and what the next step is if the answer is no.
Read the article →

AI · 18 October 2026
Almost every organisation that gets serious about data faces the same question: who is actually going to do this? Build, hire or outsource?
Read the article →
Work with us
The people who build it also run it afterwards. Eindhoven, since 2014.
We use Google Tag Manager to measure visits and Leadinfo to recognise which company is visiting. Neither loads unless you agree. If you choose essential only, the site works as normal and we measure nothing. Cookie statement · Privacy statement