Transparency notices should be designed with clear wording, prominent placement, and a form suited to the channel, tested with representative users, and recorded in a decision log that shows, for each system, feature or publication, which Article 50 paragraph was considered, what notice was given, where and when, and what testing supported it. Records should be version-controlled, retrievable, and kept current when the system, content or context changes.
How should notice wording be written?
Notice wording should be plain, direct, and specific to the fact being disclosed. For interaction, it should state that the person is interacting with an AI system. For synthetic content, it should state that the content was artificially generated or manipulated. For emotion recognition or biometric categorisation, it should state that the system is in operation and what it does. Wording should avoid jargon, euphemism, and hedging that could be read as a general statement about technology rather than a disclosure about the specific interaction or content. The wording should be drafted, reviewed, and approved as a controlled text, with a version number and date, so that different teams do not use different wordings for the same duty. Translations should be approved in the same way, and should be checked for plainness and accuracy by a competent speaker.
How should placement and timing be designed?
Placement and timing should follow the person's journey and the content's journey. For interaction, the notice should appear at the first interaction, in the flow, before the person relies on the system. For content, the notice should be attached to the content, visible where the content is viewed, and present when the content is shared. For exposure to a system in a space, the notice should be at the point of exposure, before or at the time of exposure. The design should be recorded as a placement map for each channel, showing where the notice appears, when it appears, and how it is repeated or reminded. A placement map that shows only the main channel, while the system or content also appears in other channels, is incomplete, and each channel should have its own entry in the map.
For the broader regulatory framework, see Transparency duties for AI.
How should the decision log be structured?
The decision log should have one entry per system, feature, or publication, stating the Article 50 paragraph considered, the applicability assessment, any exception relied on with its conditions and evidence, the notice wording and version, the placement and timing, the testing carried out, and the owner and review date. The log should be controlled, with version history, so that a change to a notice creates a new entry rather than overwriting the old one. The log should be retrievable by system, feature, or date, so that a question about a specific disclosure can be answered from the log entry for that disclosure. A log that records only that Article 50 was considered, without the paragraph, the notice, and the test, does not evidence that the duty was met for any specific case.
How should evidence of giving a notice be kept?
Evidence that a notice was given should be kept in a form that can be shown to a reviewer. For digital interfaces, that can include screenshots or recordings of the flow, interface version records, and test results. For physical signage, it can include photographs, placement records, and inspection logs. For published content, it can include the published item with its disclosure, the publication record, and the review record. Evidence should be linked to the decision log entry, with the date and version, so that the reviewer can see what was given, when, and in what form. Evidence that is kept only in a team member's personal files, or that is not linked to the log, will be difficult to produce when it is needed, and should be moved into the controlled record system.
How should notices be reviewed and updated?
Notices should be reviewed when the system, the content, the channel, the audience, or the legal guidance changes, and periodically even without a change, to check that they still work. The review should check the wording, placement, timing, accessibility, and testing, and should record the decision to keep, change, or withdraw the notice. Where a notice is changed, the new version should be tested with representative users before it is relied on, and the old version should be retained in the log history. The review owner, cadence, and triggers should be recorded in the transparency file, so that review is a planned activity. A notice that was correct at launch but is left unchanged while the system and audience change will drift from the standard Article 50 requires.
Continue with Testing disclosures with users.
What does this guide not decide?
This guide does not decide whether a particular notice wording, placement, or record meets Article 50, or whether a decision log is sufficient for a specific system or publication. It does not draft a notice or assess a test. Those questions depend on the notice, the channel, the audience, the testing, and the consolidated legal text. A team should design its notices, test them with representative users, keep a controlled decision log, and confirm the position with a competent authority or legal adviser where the notice is borderline or the audience is at particular risk.
Frequently asked questions
Can different teams use different wording for the same duty?
No, in practice. Wording should be drafted, approved and version-controlled as a single text for each duty, with approved translations, so that the same duty is disclosed consistently across teams and channels. Different wordings create confusion and make the record harder to follow.
What evidence proves a notice was given?
Evidence linked to the decision log entry, such as interface screenshots or recordings, signage photographs and inspection logs, or the published item with its disclosure, with the date and version. Evidence should be in the controlled record system, not only in personal files, and should be retrievable by system, feature or date.
When should a notice be updated?
When the system, content, channel, audience or guidance changes, and periodically even without a change. Update as a new version, test the new version with representative users, retain the old version in the log history, and record the review decision, owner and date.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk Article 50 ↗European Commission AI Act overview ↗