What takes effect on 2 August 2026
The EU AI Act has been in force since 1 August 2024 but becomes applicable in stages. Article 113 makes 2 August 2026 the main date of application: from that day most of the regulation applies, including Chapter IV with the transparency obligations in Article 50 (Regulation (EU) 2024/1689, Art. 113). For website operators this is the first AI Act milestone with immediately visible consequences in the front end. A chat widget in the bottom right corner, a voice assistant behind the phone number on the contact page or an AI-generated header image on the blog become relevant for labelling from that date - right where visitors actually encounter them.
Distinguishing these rules from the high-risk obligations matters. In the first half of 2026 the EU legislator adjusted parts of the regulation and postponed the high-risk deadlines: to 2 December 2027 for Annex III systems and to 2 August 2028 for Annex I systems (European Commission, AI Act Implementation Timeline). Article 50 was left untouched. The transparency obligations form a separate layer that applies regardless of risk class - an ordinary support chatbot is not a high-risk system, yet it falls under the disclosure duty (Regulation (EU) 2024/1689, Art. 50(1)). Anyone who assumed this date would move as well has less lead time than expected.
| Obligation under Article 50 | Who it addresses | From when |
|---|---|---|
| (1) Disclosure of AI interaction | Providers of AI systems interacting directly with people | 2 August 2026 |
| (2) Machine-readable marking of synthetic content | Providers of generative AI systems | 2 August 2026; existing systems by 2 December 2026 |
| (3) Notice for emotion recognition and biometric categorisation | Deployers of such systems | 2 August 2026 |
| (4) Labelling of deepfakes and of text on matters of public interest | Deployers publishing such content | 2 August 2026 |
| (5) Form: clear, distinguishable, at first contact, accessible | Providers and deployers | 2 August 2026 |
There is exactly one timing concession: for generative AI systems placed on the market before 2 August 2026, the machine-readable marking required by paragraph 2 has to be in place by 2 December 2026 (European Commission, FAQ on the transparency obligations under Art. 50). The disclosure duty in chat, by contrast, applies from the main date with no transition. Retroactive labelling of content created before 2 August 2026 is not required on this reading (European Commission, FAQ on Art. 50) - the obligation attaches to what is produced and published from the cut-off date onwards.
The European Commission adopted the final guidelines on implementing the transparency obligations on 20 July 2026, roughly two weeks before they start to apply (European Commission, guidelines on Art. 50 of the AI Act). In addition, the Code of Practice on Transparency of AI-Generated Content was published on 10 June 2026 as a voluntary commitment providing a route to demonstrate compliance with the marking and labelling duties (European Commission). Neither document is legally binding; the regulation itself is. In practice, national market surveillance authorities can be expected to follow the guidelines.
The four obligations translated into website tasks
Article 50 bundles four obligations that attach to very different places on an ordinary company website. Two address providers of AI systems, two address deployers who put such systems to use. In practice both roles often merge as soon as a company embeds a purchased language model into its own website and publishes its outputs. Recitals 132 to 134 justify the obligations by the need to protect natural persons from deception and manipulation (Regulation (EU) 2024/1689, recitals 132 to 134). The benchmark is therefore not the technical architecture but whether a person can tell what they are dealing with.
Chat widgets, voice bots, booking assistants and product advisers must be designed so that users are informed they are talking to an AI system - unless that is obvious from the circumstances (Art. 50(1)).
Outputs of generative systems - image, audio, video and text - must be marked in a machine-readable format and be detectable as artificially generated or manipulated. Solutions should be effective, reliable, robust and interoperable (Art. 50(2)).
Anyone operating emotion recognition or biometric categorisation systems must inform the people exposed to them about the operation of the system - on top of data protection requirements (Art. 50(3)).
Published deepfakes have to be disclosed. AI-generated text on matters of public interest has to be labelled unless the content was subject to human review or editorial control (Art. 50(4)).
For a typical company website this means three or four concrete work items: the chat widget, image editing on the blog, possibly automatically produced text and - far less often - systems that evaluate emotions or biometric features. The obligations therefore sit exactly where the consent banner, the imprint and the privacy policy live: in the delivered front end. That is why checking them belongs in the same routine as the rest of your GDPR and compliance monitoring - not in a one-off checklist shortly before the deadline.
Chatbot and voice bot: the notice at first contact
The practically most important case is paragraph 1: AI systems that interact directly with natural persons must be developed so that those persons are informed they are talking to an AI (Regulation (EU) 2024/1689, Art. 50(1)). Paragraph 5 defines the form: the information has to be provided at the latest at the time of the first interaction or exposure, in a clear and distinguishable manner (Regulation (EU) 2024/1689, Art. 50(5)). For a chat widget that means the notice belongs before or at the very start of the conversation - not at the end and not exclusively in a document users have to go looking for.
The information shall be provided to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction or exposure and shall conform to the applicable accessibility requirements.
— Regulation (EU) 2024/1689, Article 50(5) (paraphrased)
A frequent implementation mistake is to move the notice into the privacy policy. Experience shows this does not meet the clarity and distinguishability requirement, because the information no longer sits at the point of interaction. Equally problematic is a notice that only appears in the very first session and disappears after a page change or when the widget is reopened - the duty attaches to the first interaction, and for the same person that can happen more than once. Anchoring the notice in the widget header keeps it permanently within the user's view.
- Position - notice in the widget header or as the first message, visible without scrolling and without clicking an info icon
- Timing - at the latest when the chat opens; for voice bots as an announcement before the first question
- Wording - a short, unambiguous statement such as 'You are chatting with an AI assistant', not buried in marketing copy
- Persistence - the notice stays recognisable while scrolling through the conversation, for example as a fixed header or a repeated system label
- Channels - the same logic applies to voice assistants on the phone, to form assistants and to automated messages in messenger channels
- Languages - in multilingual sites the notice has to exist in every language version you deliver
Technically the notice is usually a small DOM element inside the widget. That is exactly what makes it fragile: a theme update, a new widget container or a changed CSS class can hide it without producing any error. Anyone who has watched a relaunch swallow the cookie consent banner knows the pattern - except that with the AI notice nobody trips over missing analytics data, so the outage stays unnoticed for longer.
The obviousness exception and its limits
Paragraph 1 contains an exception: the notice is not required where it is obvious to a reasonably well-informed, observant and circumspect person that they are interacting with an AI system (Regulation (EU) 2024/1689, Art. 50(1)). According to the Commission guidelines this exception is interpreted narrowly because it restricts transparency (European Commission, guidelines on Art. 50). The benchmark is an average person, not a technically sophisticated one.
A widget with a human-sounding first name, a photo of a person and answers written in the first person argues against obviousness. Conversely, a label such as 'AI assistant' in the widget title can already be a strong indication. The exception is a question of interpretation in each individual case - and because the burden of proof tends to sit with the operator, an explicit notice is the calmer route. This assessment does not replace legal advice.
The exception becomes practically relevant where the context is unambiguous: a demonstrator on a product page for AI software, or a tool explicitly presented as an AI experiment. As soon as the widget appears in a support context where humans used to answer, the assessment shifts quickly. Anyone working with mixed teams - bot first, human later - should additionally make the handover visible, otherwise the impression arises that the entire conversation was conducted by a person.
Labelling AI images and AI text on the blog
The second work item concerns content. Paragraph 2 obliges providers of generative systems to mark outputs in a machine-readable way and make them detectable as artificially generated; solutions should be effective, interoperable, robust and reliable as far as technically feasible (Regulation (EU) 2024/1689, Art. 50(2)). Paragraph 4 obliges deployers to disclose published deepfakes and to label AI-generated text on matters of public interest unless human review or editorial control took place (Regulation (EU) 2024/1689, Art. 50(4)). For website operators these are two distinct layers: the technical marking inside the file format and the visible label on the page.
| Content on the website | Visible label | Machine-readable marking |
|---|---|---|
| Fully generated image | recommended, mandatory where it qualifies as a deepfake | task of the generating system, keep metadata on export |
| Photo with AI retouching or cut-out | assess depending on the depth of the edit | provenance data should reflect the editing step |
| Blog text without editorial review, on a matter of public interest | mandatory | marking by the generating system |
| Blog text with documented editorial control | usually not required | marking of the draft remains unaffected |
| Product copy, pure advertising without public interest relevance | usually not required | marking by the generating system |
Marking within the meaning of paragraph 2 is not a visible watermark but information machines can read - content provenance metadata inside the image, for instance, or an origin note in the file metadata. The Code of Practice on Transparency of AI-Generated Content does not prescribe a specific technique; it asks for solutions that are effective, interoperable, robust and reliable (European Commission, Code of Practice, 10 June 2026). One practical caveat: many image pipelines strip metadata when scaling or converting to modern formats. If you optimise images automatically, check whether the provenance data survives the build - otherwise the marking disappears in exactly the step meant to make the page fast.
The exception for editorial control is narrower than it sounds. According to the guidelines a spell check is not enough; what is meant is substantive review with responsibility taken for the result (European Commission, guidelines on Art. 50). So if you have a draft generated, review it professionally, correct it and publish it under your own name, you usually fall outside the labelling duty in paragraph 4 - but you should be able to document that process. It is also worth looking at how AI crawlers fetch your content, because labelling and machine reuse are increasingly connected.
The visible label is a front-end element and can be lost in any relaunch. The machine-readable marking sits inside the file and can be lost in any image optimisation. Both layers therefore need their own check - one on the rendered page, one along the delivery path of your media.
Accessibility of the notice
One detail in paragraph 5 is often overlooked: the information has to conform to the applicable accessibility requirements (Regulation (EU) 2024/1689, Art. 50(5)). The AI Act thereby points to the same framework that the German Accessibility Strengthening Act already sets for many digital services. An AI notice that appears only as a coloured graphic without a text alternative, that misses contrast requirements or that screen readers skip does not fulfil its purpose for part of the audience.
- Text alternative - the notice exists as real text in the DOM, not only as an image or a CSS pseudo element
- Contrast - sufficient contrast between notice text and widget background, in dark mode as well
- Focus order - when the widget opens, the notice is reached before the input field in the reading order
- Status message - dynamically injected notices are announced to screen readers through a suitable ARIA role
- Scaling - the notice stays fully readable at 200 percent text zoom and is not cut off
This puts the AI notice into the same test category as the other controls on a page. If you have already implemented the accessibility requirements for websites, you can add the notice to your existing routine - including automated checks that catch WCAG regressions after every deploy. Continuous accessibility monitoring evaluates the rendered page rather than the source draft, which is decisive for widgets that only load via JavaScript.
Who enforces it - and what the fine range means
Enforcement sits with the national market surveillance authorities. In Germany the Bundesnetzagentur becomes the central market surveillance authority under the national AI implementation act wherever no other sectoral authority is competent; the Bundestag adopted the act on 11 June 2026 (German Bundestag). A coordination and competence centre (KoKIVO) is being set up at the Bundesnetzagentur to promote a uniform interpretation of the law (Bundesnetzagentur). The AI service desk acts as the first point of contact for companies, while the authority also receives and examines complaints from natural and legal persons (Bundesnetzagentur, market surveillance).
The sanction range is the reason the topic is getting so much attention. Infringements of the transparency obligations in Article 50 fall under Article 99(4) of the AI Act: up to EUR 15 million or 3 percent of total worldwide annual turnover, whichever is higher (Regulation (EU) 2024/1689, Art. 99(4)). For small and medium-sized enterprises the lower of the two amounts applies, and authorities have to take proportionality and company size into account (Regulation (EU) 2024/1689, Art. 99). The range describes an upper limit for serious cases, not the standard outcome for a missing notice in a chat widget.
A missing AI notice is first of all a defect that gets noticed, reported and fixed. Anyone able to show that the notice was in place, that a fault was spotted promptly and remedied, experience suggests will be in a considerably better position during an inspection than someone with no documentation at all. That is precisely where monitoring turns a compliance topic into an operational one. The same applies to other reporting duties, for example NIS2 registration and management responsibility.
Checking mandatory elements the way you check cookie banners
The AI notice shares one property with the consent banner, the imprint and the link to the privacy policy: it is a mandatory front-end element that nobody actively misses when it disappears. No form breaks, no order fails, no error log fills up. That is exactly why such elements frequently do not survive relaunches - and the outage stays unnoticed for weeks until someone outside points it out (project experience). The consequence: mandatory elements need a check that runs automatically after every change, instead of a visual inspection that gets lost in day-to-day work.
A screenshot of the page with the widget opened serves as the reference state. If the new capture deviates because the notice is missing, covered or moved, you get a before-and-after record.
A check for the expected text fragment in the rendered DOM also catches cases where the notice looks inconspicuous but has technically been removed - for instance by a changed widget version.
Imprint, privacy policy, consent banner and AI notice are captured in the same routine. That makes it obvious when a single deploy affects several mandatory elements at once.
Technically the check has to run in a real browser. Chat widgets are typically loaded via JavaScript, so a plain HTML request does not see the notice at all. The screenshot changelog renders the page in full and places captures side by side so deviations can be traced visually. Content monitoring complements this by detecting changed text blocks - the same principle as detecting unauthorised content changes.
- Capture the reference state - home page, one typical subpage and the contact page with the widget opened, in every language version you deliver
- Check after every deploy - capture screenshot and text fragment again so the control is coupled to the delivery process
- Keep an eye on scripts - if the version of the widget script changes, the notice may have changed too
- Watch the consent chain - tag and consent changes often affect the same containers as the chat widget, see monitoring consent and tag drift
- Attach alerting - a deviation without notification stays without consequence; alerting and notifications with escalation make sure the finding reaches someone
- Think about attack surface too - if you already scan for exposed files such as .env, .git and backups, put this check on the same schedule
Documentation for market surveillance
If a complaint reaches the market surveillance authority, the decisive question is not only whether the notice is present today but since when. This is where a continuous history pays off: anyone able to produce a time-stamped screenshot and a check result for every deploy can evidence the state of the website across months - without having to reconstruct after the fact what a page looked like in May. This chain of evidence has the same value as a change log during security incidents, for instance around the CRA vulnerability reporting obligation from September 2026.
- Timestamp and source - store every capture with date, time, URL and language version
- Reason for the change - note the deploy time or the trigger for the check so deviations stay attributable
- Finding and response - record when a deviation was detected and when it was fixed
- Regular extract - monthly reports and status pages bundle the results into a document you can hand over
- Retention - keep the history for as long as inspections and internal audit require it
The effort involved stays modest because the same check covers several duties at once. A screenshot documenting the AI notice usually also shows the consent banner, the footer with the legal pages and the state of the navigation. Which depth of testing and which cadence make sense depends on how often your website changes - an overview of the packages is available on the pricing and plans page.
Being ready by 2 August 2026
The transparency obligations in Article 50 are no reason for alarm, but a clear reason to get organised. Three steps are enough to begin: first, an inventory of which AI functions are actually visible on the website - chat, search, image generation, automated text. Second, implementing the notices exactly where the interaction begins, in an accessible form and in every language version. Third, an automated control that checks after every deploy whether these elements are still present.
The common denominator of these steps is visibility in two senses: the notice has to be visible to people, and its state has to remain visible to the operator. Both can be achieved with the same routine that already watches cookie banners, legal pages and accessibility. If you want to see what such a check chain looks like in practice, the live demo provides a complete example account, and compliance monitoring shows how the individual checks interlock. Legal assessments in individual cases still belong in expert hands - this article does not constitute legal advice.
This article is based on data and documents from: Regulation (EU) 2024/1689 (EU AI Act), in particular Article 50 (transparency obligations), Article 99 (penalties, EUR 15 million or 3 percent of total worldwide annual turnover) and Article 113 (start of application on 2 August 2026) as well as recitals 132 to 134 (transparency towards natural persons); European Commission - AI Act Implementation Timeline (staggered dates of application, postponed high-risk deadlines of 2 December 2027 and 2 August 2028); European Commission - guidelines on the implementation of the transparency obligations under Article 50, adopted on 20 July 2026 (interpretation of the obviousness exception, editorial control); European Commission - FAQ on the transparency obligations under Article 50 (transition until 2 December 2026 for marking in existing systems, no retroactive labelling); European Commission - Code of Practice on Transparency of AI-Generated Content, published on 10 June 2026 (voluntary route to demonstrate marking and labelling); Bundesnetzagentur - market surveillance under the AI Act and AI service desk (central market surveillance, complaints point, KoKIVO); German Bundestag - national AI implementation act, adopted on 11 June 2026; Eurostat - use of artificial intelligence in enterprises 2025 (19.95 percent of EU enterprises, 55.03 percent of large enterprises, 8.76 percent using natural language generation and speech synthesis). Supplemented by our own project experience from operating website monitoring. Legal assessments do not constitute legal advice.