EU AI Act Article 50 Checklist for SaaS and AI Agents

Article 50 of the EU AI Act starts applying on 2 August 2026. If your product uses a chatbot, an AI agent, or any feature that generates text, images, audio, or video, you owe users a disclosure and you owe the output a machine-readable AI marking. This is an engineering task, not a policy memo. The Commission published its final guidelines on 20 July 2026, ten days before the deadline. Most of what you will find online is a legal summary of those guidelines. This is the build checklist instead: what to put in the UI, what to write into the output pipeline, what to log, and what evidence to keep.

Two things make Article 50 different from the rest of the AI Act. It reaches limited-risk systems, so a plain SaaS chatbot is in scope even though it is nowhere near "high-risk". And most of the work lands on product and engineering teams, not on legal. Someone has to add the notice, mark the output, label the deepfake, and keep the proof. If you are still budgeting the wider programme, read our EU AI Act cost breakdown for a small startup and, for the overlap with data protection, how GDPR and the AI Act stack for DACH SaaS. This post stays on Article 50 and stays on implementation.

One caveat up front: this is practical guidance from a build team, not legal advice. The obligations below are our reading of the regulation and the July 2026 guidelines. Have counsel confirm scope for your specific product before you rely on it.

The two dates that actually bind you

There is one deadline everyone quotes and one grace window most people miss. Get the second one wrong and you assume you have four extra months you do not have.

Read the second row carefully. The December window applies to one duty (machine-readable marking under Article 50(2)) and only to systems placed on the market before August. It does not defer chatbot disclosure, deepfake labelling, or anything a deployer does. If you launch a new generative feature in September, you mark from day one. Enforcement carries fines up to EUR 15 million or 3 percent of total worldwide annual turnover, whichever is higher.

Step 1: Inventory which features are in scope

Article 50 has four sub-obligations, each pointing at a different actor. Map every AI touchpoint in your product to a row before you build anything. Most SaaS companies discover they are both a provider (for their own chatbot) and a deployer (for a marketing video made with a third-party tool).

Also record, per feature, whether the system was placed on the market before or after 2 August 2026. That single flag decides whether the December grace window applies to your marking work. Keep this inventory. It is the first thing an authority or an enterprise buyer will ask for, and it doubles as the checklist you build against. If enterprise procurement is already sending you questionnaires, our AI vendor security questionnaire guide covers where transparency questions now show up.

Step 2: Chatbot and AI agent disclosure (Article 50(1))

The rule is simple: a person must be informed they are interacting with an AI, at the latest at the first interaction. The failure modes are all in the execution.

Build it into the flow, not the footer. The guidelines explicitly reject a disclosure buried in terms and conditions, a line of technical metadata with no visible notice, or a vague label like "assistant" or "powered by LLMs". The person has to understand, at the moment of contact, that the counterpart is a machine.

A disclosure that passes looks like this:

• Text chat: a plain-language line before or with the first message, for example "You are chatting with an AI assistant." Keep it visible, not a tooltip.
• Voice agent: an audible statement at the start of the call that the caller is speaking to an AI. A visual-only notice does not work for a voice channel.
• Autonomous agent: if your agent acts on a user's behalf and contacts other people or systems, it must disclose its AI nature in every such situation, because you cannot reliably predict who is on the other end.
• Persistent cue: keep a visible indicator through the session, not only at the opening, especially for children or vulnerable audiences where the guidelines demand extra care.

The one exemption is the "obvious" case: disclosure is not required when it is already obvious to a reasonably well-informed, observant, and circumspect member of the target audience that they are talking to a machine. Treat this narrowly. If you rely on it, write down why, because you carry the burden of showing it was obvious. Do not lean on it for a support widget that mimics a human agent.

"Article 50 is not a legal document you file. It is a diff in your product: a line in the chat header, a function in the output pipeline, a column in your logs. Teams that treat it as paperwork will ship the paperwork and fail the audit on the UI."

Step 3: Machine-readable marking of generated output (Article 50(2))

If your system generates synthetic audio, image, video, or text, the output must be marked in a machine-readable format and detectable as artificially generated. This is the hardest engineering item on the list, because the guidelines set the goal without mandating a single technique. The marking must be, in the words of the regulation, "effective, interoperable, robust and reliable as far as technically feasible".

What that means in practice, by modality:

• Images and video: attach provenance metadata using the C2PA standard, which cryptographically signs a manifest describing how the content was produced. Pair it with an embedded watermark as a fallback, because metadata is stripped the moment a file is re-encoded or screenshotted.
• Audio: embed an inaudible watermark and, where the format allows, signed metadata.
• Text: the honest answer is that robust text watermarking is not a solved problem. Statistical watermarks degrade under paraphrase and light editing. Where you cannot mark reliably, document the limitation, apply metadata at the API and file level, and lean on the visible disclosure duties instead.

Do not strip existing markings. When AI content is fed back into your pipeline as input, preserve any provenance data already attached. Removing markings, or writing a term of service that lets you remove them, works against the obligation.

The exemptions here are narrow. Assistive editing that does not substantially alter the input (grammar and spelling correction) is out of scope, as is content that is not substantially altered, and systems authorised by law for criminal detection. A feature that generates a paragraph or an image is not assistive editing.

Marking is the duty most likely to qualify for the December 2026 grace window, but only if the system was on the market before August. New features mark from launch.

Step 4: Deepfake and synthetic media labels (Article 50(4))

If you publish AI-generated or manipulated image, audio, or video content that resembles real people, objects, or events and would appear authentic, you (as the deployer) must clearly disclose that it is artificial. This is broader than most teams expect.

• A realistic synthetic depiction of a fictitious but natural-looking person is still a deepfake. There does not need to be a real, identifiable individual.
• The label must be clear to the whole audience, including children, older people, and viewers with lower AI literacy, not only to the primary target.
• Clearly fantastical or physically impossible content (dragons, people flying unaided) falls outside the definition.
• Creative, artistic, satirical, or fictional works get a lighter touch: disclosure limited to indicating the existence of the generated content in a way that does not spoil the work.

Practical label patterns by modality: a persistent visible label on images, an opening disclaimer or on-screen marker for video, and an audible notice for audio. The deployer stays responsible even if the upstream tool already applied a machine-readable marking. A hidden watermark is not a substitute for a label the audience can perceive.

Step 5: AI-generated text on matters of public interest (Article 50(4))

If you publish AI-generated or AI-edited text to inform the public on matters of public interest, disclose that it is artificially generated. This targets newsroom-style publishing, not your internal documents or marketing microcopy.

The editorial exemption is real but narrow. Both conditions must hold at once:

1. A person with relevant expertise reviewed the text specifically for its content. Spell-checking or grammar correction alone does not count.
2. An identifiable person or organisation bears editorial responsibility, with a name and contact details publicly accessible.

If a human editor genuinely owns the piece, the disclosure duty falls away, but keep the editorial paper trail. That record is your evidence.

Step 6: Emotion recognition and biometric notices (Article 50(3))

If you deploy a system that recognises emotions or categorises people by biometric data, inform the exposed person at or before the first exposure, in a clear and accessible way. This is separate from the Article 5 prohibitions in workplaces and schools; Article 50(3) applies to the settings that are still allowed. If your product does not touch emotion or biometric data, record that in the inventory and move on.

Step 7: Logging and evidence retention

The guidelines make compliance an evidentiary exercise. Being compliant is not enough; you have to be able to prove it when an authority or a customer asks. Build the record while you build the feature.

Two hard rules for the pipeline: never strip provenance markings when reusing AI content as input, and never write a term of service that permits removing them. Treat provenance data as append-only.

What passes and what fails

The single most useful thing in the July guidelines is the line between adequate and inadequate disclosure. Use it as an acceptance test in code review.

The watermarking reality gap

Be honest with yourself about Article 50(2). The regulation asks for marking that is robust and reliable, and the technology is not there yet, which the Commission acknowledges with the phrase "as far as technically feasible". C2PA metadata is strong but brittle: a screenshot, a re-encode, or a platform that scrubs metadata removes it. Watermarks survive better but can be weakened by cropping, compression, or adversarial editing. Text watermarking barely survives a paraphrase.

The compliant posture is not to wait for perfect technology. It is to apply the best available method per modality, layer metadata and watermark so one covers the other's failure, document what you did and where it breaks, and back it with visible disclosure. A team that can show a reasoned, layered approach is in a far stronger position than one that shipped nothing while waiting for a standard.

Should you sign the Code of Practice?

The AI Office published a voluntary Code of Practice on marking and labelling AI-generated content. Adherence to a Code deemed adequate can be a route to demonstrating compliance with Article 50(2), (4), and (5). Non-signatories can still comply by other means, but the guidelines suggest they may face a heavier evidentiary burden.

For a generative AI provider, signing is worth serious consideration: it gives you a defensible template and a safe-harbour signal. For a pure deployer whose only exposure is a chatbot notice and the occasional labelled video, the Code adds less and your effort is better spent on the disclosures themselves. Decide based on whether you generate content at scale or merely deploy it.

Sources and methodology

This checklist is Wavect's engineering reading of Article 50 of Regulation (EU) 2024/1689 and the European Commission's final guidelines on the transparency obligations, adopted 20 July 2026. Obligations, dates, and exemptions were checked on 23 July 2026 against the Commission's guidance and the consolidated Article 50 text. The pass and fail examples reflect the disclosure adequacy tests set out in those guidelines. This is implementation guidance, not legal advice.