Guide
Blog
News
21 October 2026

EU AI Act Article 50: who has to label AI, and from when

EU AI Act Article 50: who has to label AI, and from when

Your support team runs a chatbot on the website. Marketing edits product photos with an image model. The newsletter is drafted with AI and polished by a person. And the product team has just shipped a feature that writes text for your customers. None of this feels like high-risk AI, and none of it is. But since 2 August 2026, all four of these need a second look.

That is the day Article 50 of the EU AI Act started to apply: the transparency rules for AI that talks to people and AI that creates content.

Key takeaways

  • Article 50 has applied since 2 August 2026. The AI Omnibus postponed the high-risk rules, but not the transparency duties.
  • There are four duties, split between providers (who build an AI system or put it into service under their own name) and deployers (who use it).
  • One grace period: machine-readable marking of generated content for systems already on the market before 2 August 2026 has to be in place by 2 December 2026. Everything else applies now.
  • Most companies are affected in at least one role, typically through a chatbot, a voice bot or AI-generated marketing content.
  • Fines go up to 15 million euros or 3 percent of worldwide annual turnover. In Germany, the Bundesnetzagentur is the central market surveillance authority.
  • Start with an AI register. You cannot label what you have not listed.

What changed on 2 August 2026

The AI Act, Regulation (EU) 2024/1689, applies in stages. The bans on prohibited practices and the AI literacy duty came first, in February 2025. The rules for general-purpose AI models followed in August 2025. On 2 August 2026, Article 50 joined them.

In the same summer, the EU adopted the AI Omnibus, Regulation (EU) 2026/1744, published on 24 July 2026 and in force since 27 July. It moved the obligations for high-risk AI systems to 2 December 2027 (stand-alone systems under Annex III) and 2 August 2028 (AI in products under Annex I). It did not move Article 50. The only relief concerns the machine-readable marking of generated content: systems placed on the market before 2 August 2026 have until 2 December 2026. Systems placed on the market from 2 August 2026 onwards must comply from day one.

Two more pieces matter in practice. On 10 June 2026 the European Commission published a voluntary Code of Practice on marking and labelling AI-generated content. And in Germany, the national act implementing the AI Act, approved by the Bundesrat on 10 July 2026, makes the Bundesnetzagentur the central market surveillance authority and the point of contact for complaints.

Provider or deployer?

Every duty in Article 50 is addressed to one of two roles, so this is the first question to answer for each AI system you use.

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 brand. A deployer uses an AI system under its own authority in a professional context.

The line is not always where people expect it. If you build a support chatbot on top of a large language model and put it on your website under your brand, you are generally the provider of that chatbot, even though someone else trained the model. If you use a vendor’s finished image tool to edit campaign photos, you are a deployer. Many companies hold both roles at once, for different systems.

The four duties

1. AI that interacts with people (Article 50(1), providers)

Systems that interact directly with people, such as chatbots, voice bots and AI agents that write to customers, must be designed so that people are informed that they are interacting with an AI. The exception: when this is obvious to a reasonably well-informed, observant person from the context. A robot voice reading a weather forecast may be obvious. A friendly support assistant called “Lena” is not.

2. Marking generated content (Article 50(2), providers)

Providers of AI systems that generate synthetic audio, images, video or text must mark the outputs in a machine-readable format so that they can be detected as artificially generated or manipulated. The technical solution has to be effective, interoperable, robust and reliable as far as technically feasible. In practice this means watermarks, metadata or fingerprinting, often in combination. The duty does not apply where the system only performs an assistive function for standard editing or does not substantially alter the input.

3. Emotion recognition and biometric categorisation (Article 50(3), deployers)

If you use a system that recognises emotions or sorts people into categories based on biometric data, you must inform the people exposed to it, and process their data in line with the GDPR. Note that emotion recognition at the workplace and in education is prohibited altogether under Article 5, with narrow exceptions for medical or safety reasons.

4. Deepfakes and AI text on matters of public interest (Article 50(4), deployers)

If you publish image, audio or video content that is a deepfake, you must disclose that it was artificially generated or manipulated. For evidently artistic, creative, satirical or fictional work, the disclosure can be limited so that it does not spoil the work.

If you publish AI-generated or AI-manipulated text to inform the public on matters of public interest, you must disclose that too. The exception: a person has reviewed the text and someone holds editorial responsibility for the publication. This is the clause most relevant for corporate blogs, newsletters and press releases. A documented editorial review is what keeps you out of the labelling duty.

How and when to inform

The information has to be given in a clear and distinguishable manner, at the latest at the time of the first interaction or exposure, and it has to be accessible to people with disabilities. A disclaimer in the privacy policy is not enough. A short line in the chat window, a spoken sentence at the start of a call or a visible label on an image is.

Five common cases

  • Support chatbot under your brand: you are usually the provider. Show a clear notice in the chat window before the first message.
  • Voice bot on the hotline: same duty, different channel. Say it at the start of the call. This is the case most often forgotten.
  • Marketing images edited with AI: you are a deployer. If an image shows real people, places or events in a way that could appear authentic, it is a deepfake and needs a label. A product shot with a new background usually is not.
  • AI-drafted blog posts and newsletters: if a person reviews them and someone holds editorial responsibility, no label is required. Write that review step down.
  • A product feature that generates content for your customers: you are the provider. You need machine-readable marking, by 2 December 2026 at the latest if the feature was live before 2 August 2026.

How to get ready

  1. List every AI system you build or use. Include tools teams adopted on their own. For each one, write down what it does, who uses it and who sees its output.
  2. Assign your role per system: provider, deployer or both.
  3. Check each system against the four duties and mark it done, gap or to review.
  4. Fix the interaction notices first. They are quick to implement and the most visible to customers and authorities.
  5. Sort out marking with your vendors. If you are the provider, ask your model vendor which watermarking or metadata standard they support and build on it.
  6. Document your editorial review for AI-assisted text: who reviews, how, and who is responsible for publication.
  7. Train the people who publish. Since the AI Omnibus, Article 4 asks companies to take measures to support AI literacy. Labelling rules are a good place to start.
  8. Keep evidence. If the Bundesnetzagentur asks, you need to show when and how people were informed.

Where labelling goes wrong

“We only use a ready-made model, so this does not affect us.” Using a third-party model does not make you exempt. The moment you put it in front of customers under your name, you are likely the provider of that system.

Labelling everything. A label on every internal email trains people to ignore labels. The duties are specific. Apply them where they apply.

Forgetting voice and email. Chat is the obvious channel. Phone bots and AI agents that write emails to customers are covered too.

Relying on the vendor for marking. If you are the provider, the duty is yours, even when the technology comes from someone else.

How this fits into the rest of the AI Act

The AI register you build for Article 50 is the same one you need for everything else: classifying systems by risk, checking whether any of them fall under the high-risk rules from December 2027, and, if you go further, building an AI management system under ISO/IEC 42001. If you use AI agents in your own compliance work, our guide on what agents should decide and what stays with humans covers the oversight side.

How GetTeddy handles this

From the first signal to an approved early warning, within 24 hours

GetTeddy links every security event to your product inventory, checks the CRA threshold and the NIS2 and GDPR duties next to it, and drafts the early warning with everything the form asks for. The decision and the submission stay with your named people.

How GetTeddy handles this

A new framework in an afternoon, not a second program

GetTeddy keeps one model of your company and one control set. When a new framework arrives, it reads every requirement against what you already have and labels it full, partial or missing. Only the real gaps become tasks.

How GetTeddy handles this

Agents do the work. You can see every step and stop any of it.

Every result in GetTeddy carries a label: done by an agent, drafted by an agent and approved by a person, or decided by you. Drafts wait for a named approver, connections are read-only unless you allow more, and every action lands in a log your auditor can read.

How GetTeddy handles this

Registration, measures and the 24-hour report in one place

GetTeddy checks NIS2 scope for each legal entity, prepares the registration data, maps the ten areas onto the controls you already have and sets up staged reporting with named people. Your team approves every step.

How GetTeddy handles this

Germany and Austria on one control set

GetTeddy checks each group company under the law that applies to it, prepares the registration data for each authority and maps both laws onto the same controls. The reporting plan covers both countries.

How GetTeddy handles this

Every AI system in one register, every label duty in view

GetTeddy keeps your AI register, classifies each system by role and risk and shows which Article 50 duties apply: chatbot disclosure, machine-readable marking or labelling of deepfakes. Your team approves each decision.

How GetTeddy handles this

A classification for every AI system, with the reasoning written down

GetTeddy records each AI system, checks it against the prohibited practices, Article 6 and Annex III, and drafts the reasoning for your review. The duties that follow are mapped onto the same control set as ISO 42001 and ISO 27001.

How GetTeddy handles this

Your AI management system on the controls you already have

GetTeddy builds the AI inventory, prepares the AI policy, risk and impact assessments and the Statement of Applicability, and maps ISO 42001 onto your ISO 27001 and EU AI Act controls. A compliance engineer helps you prepare for the audit.

How GetTeddy handles this

A Statement of Applicability that stays current

GetTeddy builds the SoA from your company model and risk register, proposes a justification for every Annex A control, links it to evidence from your tech stack and flags when a change makes an entry outdated. Your team approves every decision.

How GetTeddy handles this

Standard changes, checked against your ISMS

GetTeddy tracks changes to the standards you certify against, maps them to your existing controls and shows what, if anything, needs to change. Your team approves the update.

How GetTeddy handles this

Scope checked for every legal entity, with the reasoning on file

GetTeddy reads your company model entity by entity: sector, size, group data and IT independence. It drafts the result and the reasoning for each company and prepares the registration data for those in scope. Your team approves the result.

How GetTeddy handles this

One control set for the certificate and the report

GetTeddy maps your controls to ISO 27001 Annex A and the SOC 2 Trust Services Criteria at once and collects evidence from your tech stack across the whole observation period. A compliance engineer helps you prepare for both audits.

How GetTeddy handles this

The VDA ISA self-assessment, prepared from your ISO 27001 controls

GetTeddy maps the VDA ISA questions onto the controls you already have, proposes a maturity level with evidence for each one and shows what is still missing for your labels. A compliance engineer helps you prepare for the assessment.

How GetTeddy handles this

Every financial customer contract checked against Article 30

The Contract Agent reads each DORA addendum, compares it with Article 30 and with what your security program actually does, and drafts comments where a clause goes further than the regulation. Your legal team decides.

How GetTeddy handles this

Agents prepare the work. Your team decides.

Every result in GetTeddy shows who did what: collected by an agent, drafted by an agent and approved by a person, or decided by you. A compliance engineer helps you prepare for the audit, and an accredited certification body carries it out.

How GetTeddy handles this

The eight criteria, shown on your own company

In a demo, GetTeddy runs the scope check for your group, maps NIS2 onto the controls you already have, walks through an incident from first alert to early warning and checks a supplier contract. Then you decide.