If your product uses interactive or generative AI, one or more Article 50 categories may be relevant. The transparency obligations in Article 50 start to apply on 2 August 2026. A limited transition may extend provider-side machine-readable marking to 2 December 2026 for eligible systems placed on the market before the general application date.
This checklist walks through each obligation category, who the text assigns it to, and what an operational review can cover. It is workflow guidance, not a legal determination — consult counsel for your specific case.
First: are you even in scope?
The AI Act can reach providers and deployers outside the EU when their systems are placed on the EU market or their output is used in the EU. EU users or EU-targeted services are therefore facts to assess, not an automatic legal conclusion by this checklist.
Calling a third-party model API does not settle the question. You still need to identify whether you provide the resulting AI system under your name, deploy it under your authority, or do both, and then map the system's actual use to the relevant paragraph.
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.
Operational review: check whether the information is timely, clear, accessible and present at the interaction point. The Act and forthcoming/current guidance, not this checklist, determine whether a particular implementation is sufficient.
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.
Operational review: select a technique appropriate to each output format and current technical standards. Generic HTML, JSON-LD or header signals can be advisory metadata, but they are not signed provenance and should not be treated as sufficient by themselves. Review the current EU Code of Practice and technical guidance.
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.
Operational review: document the notice and obtain a separate GDPR assessment. Do not infer a lawful basis from an Article 50 workflow.
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.
Operational review: document the visible label, placement, timing and any claimed exception for counsel to review.
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 dated readiness statement that documents the recorded systems, indicated duties and unresolved review points.
- [ ] 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 needs a separate role review. Commission guidance says modification does not automatically make you a GPAI provider; significant modifications can still require a separate assessment. 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. If Acme provides that system under its own name, 50(1) is indicated; a deployer-only role would not carry that provider duty. Facts about synthetic output and public-interest publishing need separate answers before excluding 50(2) or 50(4).
- 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 different fact patterns. A company-wide “are we compliant?” question hides those role and system differences. Run the assessment per product and retain the assumptions behind the result.
Frequently asked questions
Does this apply to internal tools? Internal use is not a safe blanket exclusion. Identify the actor role, affected people, use context and any specific exception, then obtain case-specific advice.
We're a tiny startup — is there an exemption? Article 50 does not contain a blanket startup exclusion. The applicable paragraph and exceptions still depend on the system and role.
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: retain the operating record. A dated, hash-chained history can show what the application recorded and when. It is useful for internal review and procurement, but it is not independent proof that every control operated correctly or that the organisation complied with the law.
Where DiscloseKit fits
DiscloseKit turns this checklist into a workflow: a free checker that maps documented answers to indicated categories, an embeddable disclosure widget, an AI-system inventory, versioned readiness statements, advisory marking snippets, installation verification and a hash-chained evidence log. It does not make the legal judgement for you.
Start with the readiness check to identify which facts and Article 50 categories need review for your product.