If your product uses AI — a chatbot, a content generator, an assistant — Article 50 of the EU AI Act almost certainly has something to say about it. The transparency obligations in Article 50 start to apply on 2 August 2026, and unlike the high-risk rules that the May 2026 Digital Omnibus agreement pushed to 2027/28, Article 50 was left unchanged. This is the deadline that will land first for most software teams.
This checklist walks through each obligation, who it falls on, and what "done" looks like. It is compliance tooling and documentation, not legal advice — consult counsel for your specific case.
First: are you even in scope?
Article 50 reaches providers and deployers whose AI systems, or the outputs of those systems, are used in the EU — wherever the company is based. If you have EU users, or you target the EU market, assume you are in scope until you've confirmed otherwise. Being based in the US, Canada or Australia does not exempt you.
One common misconception: "we just call the OpenAI/Anthropic API, so the model provider handles this." That is not how it works. When you embed a general-purpose model, you are regulated as a downstream provider or deployer based on the intended purpose of *your* system. The obligation attaches to what your product does, not to the model underneath it.
The four obligations, in plain language
1. Tell users they're interacting with AI — Art. 50(1)
If your system interacts with people — think chatbots, voice assistants, conversational support — you must ensure users are informed they're interacting with an AI, unless it's obvious from the context to a reasonably observant person.
Done looks like: a clear, persistent disclosure at the point of interaction. A one-line notice before or during a chat is enough; it must be genuinely visible, not buried in a privacy policy.
2. Mark AI-generated content as machine-readable — Art. 50(2)
If your system generates synthetic audio, image, video or text, you must mark those outputs as artificially generated or manipulated in a machine-readable format. Systems already on the market get a transition period until 2 December 2026 for the machine-readable marking specifically.
Done looks like: provenance metadata attached to generated assets — for example a set of HTML meta tags, a JSON-LD block, or HTTP headers that a machine can read. This is where a marking helper or API earns its keep.
3. Inform people subject to emotion or biometric systems — Art. 50(3)
Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them, and process personal data in line with the GDPR.
Done looks like: an explicit notice to affected individuals plus a lawful basis under the GDPR. Most SaaS teams won't touch this one — but if you do sentiment analysis on faces or voices, you do.
4. Disclose deepfakes and public-interest AI text — Art. 50(4)
Deployers must disclose when image, audio or video content is a deepfake, and disclose AI-generated or AI-manipulated text published to inform the public on matters of public interest. There are narrow exceptions — editorial control, artistic or satirical works — that a simple yes/no test can't resolve for you.
Done looks like: a visible label on deepfake media and on public-interest text, applied consistently.
The checklist
Work through this per product, not per company. A team with three apps has three of these.
- [ ] Inventory your AI systems. For each one, note the vendor/model, purpose, and whether you're the provider or the deployer.
- [ ] Map each system to its obligations. Use the four categories above. A single system can trigger more than one.
- [ ] Add a disclosure notice wherever an AI system interacts with users (50(1)).
- [ ] Set up machine-readable marking for any generated content (50(2)) — before 2 December 2026.
- [ ] Label deepfakes and public-interest text (50(4)).
- [ ] Handle emotion/biometric notices if applicable (50(3)).
- [ ] Publish a transparency statement that documents your systems and how you meet each duty.
- [ ] Keep an evidence trail. Record when disclosures went live, when statements were published, and when systems changed. If a customer or authority asks, you want dated proof.
- [ ] Re-check on every change. New model, new feature, new content type — re-run the assessment.
What to watch for
- Fine-tuning changes your role. If you substantially fine-tune or materially modify a general-purpose model, you may take on general-purpose AI *provider* obligations of your own, on top of Article 50. That's a conversation for counsel.
- "Obvious from context" is narrow. Don't rely on it. A branded assistant that writes like a person is exactly the case the disclosure rule exists for.
- The Code of Practice is voluntary. There's an EU Code of Practice on the transparency of AI-generated content that helps operationalise Article 50, but it isn't itself a legal requirement.
Scoping by product, with a worked example
The single most useful reframe is to stop thinking "does my company comply?" and start thinking "does each product comply?". Obligations attach to systems, and systems live inside products.
Take a fictional team, Acme, with two apps:
- Acme Chat — a customer-support product with an in-app assistant powered by a third-party model. It interacts with users, so 50(1) applies: a disclosure notice at the point of interaction. It doesn't generate downloadable media or publish public-interest text, so 50(2) and 50(4) don't apply. Acme is the *deployer* here.
- Acme Studio — a design tool that generates marketing images, some of which depict realistic scenes. Because it generates synthetic image content, 50(2) applies (machine-readable marking, with the December runway). Because some outputs can look like real people or places, the deepfake disclosure in 50(4) applies too. Acme is closer to a *provider* of the generating system.
Same company, two very different obligation sets. If Acme had tried to answer "are we compliant?" as one question, it would have missed that Studio needs marking that Chat doesn't. Run the assessment once per product and the answer becomes concrete.
Frequently asked questions
Does this apply to internal tools? The transparency duties are about people interacting with, or being exposed to, AI systems and their outputs. A purely internal tool with no external users is lower-risk, but if employees are the "users" being interacted with, consider whether 50(1) still applies. When in doubt, disclose — it's cheap.
We're a tiny startup — is there an exemption? There is no blanket small-business carve-out for Article 50's transparency duties. The obligations scale with what your system does, not with your headcount. The good news is that meeting them is mostly a matter of shipping a clear notice and keeping a record.
What happens if we don't comply? The AI Act carries significant administrative fines for infringements, enforced by national authorities. The specifics are for counsel, but the practical takeaway is simple: the cost of a disclosure notice and a transparency page is trivial next to the cost of getting it wrong.
How often should we re-check? Treat every material change to a system as a trigger — a new model, a new content type, a new market. A quarterly review plus change-triggered checks keeps you current without turning it into a project.
Keep the evidence
One theme runs through the whole checklist: be able to show your work. Article 50 is about transparency, and the cleanest way to demonstrate transparency is a dated record — when each disclosure went live, when each statement was published, when each system changed. If a customer's procurement team or a supervisory authority ever asks, "how do you meet Article 50?", a link to a live transparency page plus an exportable log of changes is a far stronger answer than a policy document written after the fact.
Where DiscloseKit fits
DiscloseKit turns this checklist into a workflow: a free checker that maps your answers to the exact obligations, an embeddable disclosure widget, an AI-system inventory that derives obligations automatically, generated transparency statements and marking snippets, and an append-only evidence log. It won't make the legal judgement for you — but it removes the busywork between you and a defensible transparency posture.
Start with the two-minute check to see precisely which of these obligations apply to your product.