--- title: "EU AI Act Article 50 on AWS: Chatbot Disclosure and AI Content Marking" description: "Article 50 is the part of the EU AI Act that did not get delayed. What it requires from chatbots, generative AI and emotion recognition on AWS, and how to have the evidence ready before 2 December 202" doc_version: 1.0.0 last_updated: 2026-10-27 date_published: 2026-10-27 canonical: https://ccx.hu/blog/eu-ai-act-article-50-transparency-aws --- # EU AI Act Article 50 on AWS: Chatbot Disclosure and AI Content Marking > Article 50 is the part of the EU AI Act that did not get delayed. What it requires from chatbots, generative AI and emotion recognition on AWS, and how to have the evidence ready before 2 December 2026. ![EU AI Act Article 50 on AWS: Chatbot Disclosure and AI Content Marking](https://s3.us-east-1.amazonaws.com/ccx.hu/images/16-eu-ai-act-article-50.png) Most of the EU AI Act conversation is about high-risk systems, and since the Digital Omnibus moved those obligations to December 2027, a lot of teams have put the whole topic on next year's roadmap. Article 50 is the exception. It covers far more systems than the high-risk rules, including the customer support chatbot, the marketing copy generator and the product image pipeline, and it is not on the 2027 timeline. This post covers what Article 50 asks for, who it applies to, and how we implement it on AWS. ## When it applies Article 50 has applied since **2 August 2026**. The Digital Omnibus on AI (Regulation (EU) 2026/1744) gave generative AI systems that were already on the market before that date a short transition for the machine-readable marking duty in Article 50(2), ending on **2 December 2026**. If you launched a generative feature after 2 August, there is no transition: the duty applies now. We covered the wider timeline change in [what the May 2026 timeline change means for AWS-hosted AI](https://ccx.hu/blog/what-the-may-2026-eu-ai-act-timeline-change-means-for-aws-hosted-ai-systems). Breaches of Article 50 fall in the middle penalty tier: up to €15 million or 3% of worldwide annual turnover, whichever is higher. ## Who it applies to Article 50 splits its duties between providers and deployers, and most companies building on Amazon Bedrock are both. - If you build a chatbot or a generative feature and offer it under your own name, you are the **provider** of that AI system, even though the underlying model is someone else's. The model vendor has its own obligations as a general-purpose AI model provider. They do not cover yours. - If you use an AI system in your own operations, for example to generate content you publish, you are a **deployer**. It does not matter whether the system is high-risk. A minimal-risk chatbot still has to tell people it is a chatbot. ## The four obligations Reduced to engineering requirements: 1. **Disclose AI interaction (providers, Article 50(1)).** A system that interacts directly with people must be designed so they are informed they are dealing with an AI, unless that is obvious to a reasonably well-informed person from the context. 2. **Mark synthetic output (providers, Article 50(2)).** Systems that generate audio, image, video or text must mark their output in a machine-readable format so it is detectable as artificially generated or manipulated. The technical solution must be effective, interoperable and reliable as far as technically feasible. There are exceptions for assistive editing functions and for output that does not substantially alter the input. 3. **Inform people exposed to emotion recognition or biometric categorisation (deployers, Article 50(3)).** 4. **Label deep fakes and AI-written public-interest text (deployers, Article 50(4)).** Image, audio or video that resembles real people, places or events must be disclosed as generated or manipulated. Text published to inform the public on matters of public interest must be disclosed too, unless it has gone through human review or editorial control and someone holds editorial responsibility for it. Article 50(5) adds that the information must be clear and distinguishable, given at the latest at the first interaction or exposure, and accessible. ## Pattern 1: disclosure in every channel, logged Chatbot disclosure sounds trivial until you count the channels. The web widget has a banner, but the same Bedrock agent also answers in the mobile app, over email, in a WhatsApp integration and through an Amazon Connect voice flow, and nobody added the disclosure there. - **Put the disclosure in the channel layer, not the prompt.** A system prompt telling the model to introduce itself as an AI is not a control. It can be forgotten, overridden or paraphrased away. Render the disclosure in the UI, or for voice, play it as a fixed prompt at the start of the Amazon Connect contact flow before the Lex bot or the agent answers. - **Make it stick.** A disclosure at the start of a chat that scrolls away after twenty messages is weaker than a persistent label next to the bot's name. Do both. - **Handle hand-offs.** When a conversation moves from a human agent to a bot or back, tell the user. - **Log it.** Record that the disclosure was shown, in which channel and with which wording version, alongside the conversation ID. That is your evidence, and it fits in the same pipeline as your [Article 12 traceability logs](https://ccx.hu/blog/article-12-traceability-cloudwatch-s3-glue). ## Pattern 2: marking generated images and video For images and video, the state of the art is two layers: an invisible watermark embedded in the pixels, and signed provenance metadata in the C2PA (Content Credentials) format. They fail in different ways, which is why you want both. Metadata is easy to read and easy to strip; a watermark survives resizing and screenshots better but needs a detector to read. Amazon's own image and video models on Bedrock, the Nova Canvas and Nova Reel family and Titan Image Generator before them, add an invisible watermark by default, and AWS documents C2PA content credentials on the image models. Third-party models on Bedrock vary. Check each model's documentation instead of assuming, and record the result. The common failure is not the model. It is what happens next. A typical pipeline writes the generated image to S3, then a resizing step built on Sharp or a similar library produces thumbnails and web formats, and that step drops all metadata by default. The C2PA manifest is gone before the image reaches a user. - **Find every transform between the model and the user**: resizing, format conversion to WebP or AVIF, compression, CDN image optimisation. - **Preserve or re-sign.** Either configure each step to keep the manifest, or re-sign the derived asset with your own C2PA claim that references the original, using the open-source C2PA libraries in a Lambda function. Keep the signing key in a managed key store, not in the function's environment. - **Test it in CI.** An integration test that generates an image, runs it through the real pipeline and verifies the final asset with `c2patool` catches the regression the day someone adds a new image step. ## Pattern 3: marking generated text Text is the hard case. Text watermarking is still immature, and the Act's "as far as technically feasible" wording reflects that. In practice we mark text at the format and transport level: - **API responses** carry a field or header stating the content was generated, with the model and version. - **Documents** your system produces (PDF, DOCX, email) carry it in their metadata properties. - **Web content** carries it in the HTML, not only in visible copy. - **Provenance is logged**: every generated output has a record of the model invocation that produced it, so you can answer "was this generated?" for any piece of content you shipped. The AI Office's code of practice on transparency of AI-generated content is the reference for what an assessor will consider adequate marking. Read its current version before you choose an approach, and write down why your choice is the feasible one for your system. ## Pattern 4: check for emotion recognition you did not plan Amazon Rekognition's face detection can return estimated emotions for each face. Teams switch on all attributes during a prototype and never switch them off. If that output is used about people, you are running emotion recognition, and Article 50(3) requires telling them. In a workplace or a school, it is worse. Article 5 has prohibited emotion recognition in those settings since February 2025, except for medical or safety reasons. A meeting analytics tool or a proctoring feature that reads emotions from webcam frames is a prohibited practice, not a transparency question. Search your code and infrastructure for face attribute requests, and remove the emotion attributes wherever you do not have a documented reason to use them. ## Pattern 5: label published content at the source The Article 50(4) duties land on marketing, communications and content teams more than engineering. The practical controls: - **Tag generated assets in the content system.** A flag on the asset in your CMS or digital asset store that travels with it, and drives a visible label wherever the asset is published. - **Record editorial responsibility.** For AI-assisted articles, the exception for human review only helps if you can show who reviewed and approved the text. A named approver on each published item is enough. - **Write a short policy** for what gets a label and what does not, with examples. The deep fake definition covers realistic depictions of real people, places and events; a generated illustration of an abstract concept is not the same case as a photorealistic image of a real product launch that never happened. ## Evidence to have ready If an authority or a customer's procurement team asks how you meet Article 50, the answer should be a folder, not a meeting: - An inventory of every system that interacts with people, generates content or processes faces, with its Article 50 role (provider or deployer) and which paragraphs apply. - Disclosure wording and screenshots per channel, and the disclosure logs. - The marking approach per output type, the model documentation you relied on, and the CI test that proves marks survive your pipeline. - The content labelling policy and the editorial approval records. ## What this looks like at ccX Article 50 is part of our [EU AI Act readiness audit](https://ccx.hu/eu-ai-act) for AWS-hosted systems, and for most clients it is the part with the nearest deadline. We inventory the systems in scope, trace generated content from the model to the user to find where marks are lost, check disclosure in every channel, and give your team a remediation list sized to fit before 2 December. If you have generative features in production and are not sure they would pass, [book a 30-minute scoping call](https://ccx.hu/book). ## Where to go from here - [The EU AI Act readiness checklist for AWS](https://ccx.hu/blog/eu-ai-act-aws-checklist) - [Annex III in plain English](https://ccx.hu/blog/eu-ai-act-annex-iii-plain-english) - is your system also high-risk? - [Article 14 on AWS: human oversight](https://ccx.hu/blog/eu-ai-act-article-14-on-aws-human-oversight-that-works-not-a-checkbox) - [Bedrock Guardrails vs custom filters](https://ccx.hu/blog/bedrock-guardrails-vs-custom-filters) - [EU AI Act readiness](https://ccx.hu/eu-ai-act) > *This post is engineering guidance, not legal advice. Article references reflect the AI Act as amended by Regulation (EU) 2026/1744; confirm how they apply to your system with your legal team.* --- ## Sitemap - [Read this post on the web](https://ccx.hu/blog/eu-ai-act-article-50-transparency-aws) - [All blog posts](https://ccx.hu/blog) - [Full site map](https://ccx.hu/sitemap.md) - [Home](https://ccx.hu/) - [Services](https://ccx.hu/services) - [EU AI Act Compliance](https://ccx.hu/eu-ai-act) - [AWS GenAI Production Readiness](https://ccx.hu/aws-genai-review) - [Glossary](https://ccx.hu/glossary) - [Contact](https://ccx.hu/contact)