The EU AI Act Article 50 deadline is 2 August 2026, when transparency obligations for AI systems start to apply. This article turns that date into a practical timeline: what the 2 December 2026 marking transition really covers, what "placed on the market before" means for your existing product, and a month-by-month plan a product team can actually follow. It is an operational guide, not legal advice.
What the EU AI Act Article 50 deadline actually is
Two dates matter, and teams routinely blur them.
The first is 2 August 2026. On that date the Article 50 transparency obligations begin to apply. This is set by the Regulation's application timeline in Article 113. From that day, the four obligation categories are live for systems in scope.
The second is 2 December 2026. A limited transition can extend the provider-side machine-readable marking duty (Art. 50(2)) to this date for eligible systems that were already on the market before the general application date. It is a narrow easing for one specific obligation, not a general grace period for all of Article 50. Do not plan as if everything slides to December.
The four categories, briefly:
- Art. 50(1) — inform people they are interacting with an AI system (chatbots, voice assistants), unless it is obvious to a reasonably observant person.
- Art. 50(2) — providers must mark synthetic audio, image, video, or text output as artificially generated or manipulated, in a machine-readable format.
- Art. 50(3) — deployers of emotion-recognition or biometric-categorisation systems must inform the exposed persons and process personal data in line with the GDPR.
- Art. 50(4) — deployers must disclose deepfakes, and disclose AI-generated or manipulated text published to inform the public on matters of public interest. Narrow exceptions exist for editorial control and artistic or satirical works.
The European Commission's AI Act Service Desk is the reference point for the official reading of these duties.
Why the two dates trip teams up
The split matters because the obligations sit on different roles and different clocks.
Art. 50(1), (3), and (4) do not get the December extension. If your product shows a chatbot, runs emotion recognition, or publishes deepfakes or AI-written public-interest text, the honest planning date is 2 August 2026 for those.
Only the provider-side marking of synthetic output under Art. 50(2) is eligible for the move to 2 December — and only for systems already on the market before 2 August 2026. A system you launch on, say, 15 August 2026 does not get the transition for its marking duty. Neither does a system that changes so much it is effectively new.
So the transition is best treated as breathing room for one hard engineering task (embedding machine-readable marks into generated output at scale) on products that already exist — not as a reason to defer the user-facing disclosures.
What "placed on the market before" means in practice
"Placed on the market" is a concept the EU uses across product law: broadly, the first making available of a specific system on the EU market in the course of a commercial activity. For a SaaS or app team, a few practical readings help.
- Assess per product, not per company. Each AI system inside each product is judged on its own facts. A company can have one product already on the market and another launching after the deadline; only the first is a candidate for the marking transition.
- A live, generally available product before 2 August 2026 is the clearest case of "already on the market."
- A materially changed system may count as new. If you significantly rework what the system does after the deadline, do not assume the pre-existing status carries over. Where this is unclear, it is a question for counsel, not a self-certified call.
- Version bumps and routine updates are a grey zone. Small iterative changes usually will not reset the status; a substantial redesign might. Document what you shipped and when, so the question can be answered from evidence rather than memory.
Scope also reaches beyond the EU. Providers and deployers outside the EU are covered when systems are placed on the EU market or their output is used in the EU. A US-based product with EU users is squarely in view.
One more point that catches teams building on top of foundation models: calling a third-party model API (OpenAI, Anthropic, and others) does not remove the duties attached to the AI system you provide or deploy. Modifying or fine-tuning a general-purpose model does not automatically make you its provider — but a significant modification can trigger a separate general-purpose AI assessment. The Commission's guidance for general-purpose AI providers is the place to check where you stand, and this is an edge case worth raising with counsel.
A month-by-month readiness plan
Here is a plan a product team can follow in the run-up to the EU AI Act Article 50 deadline. Adjust to your own release cadence; the point is to work backwards from 2 August 2026, not to start in July.
Now through Q1 2026 — inventory and classify
- List every AI system inside every product you ship into the EU. One row per system, per product.
- For each, record the role you play: provider (you develop or substantially shape the system) or deployer (you use it under your authority), or both.
- Map each system to the Article 50 categories it touches: user interaction (50(1)), synthetic output (50(2)), emotion/biometric categorisation (50(3)), deepfakes or public-interest text (50(4)).
- Flag which systems are, or will be, on the market before 2 August 2026 — these are your candidates for the marking transition.
Q1–Q2 2026 — design the disclosures
- Draft the user-facing AI notices for Art. 50(1). Aim for clear, early, and hard to miss, without breaking the experience.
- For Art. 50(3) systems, design the notice to exposed persons and confirm your GDPR basis and records with your data protection lead.
- For Art. 50(4), decide how deepfakes and any AI-generated public-interest text will be labelled, and check whether the narrow editorial/artistic exceptions genuinely apply to your case.
- Have counsel review the borderline calls: "obvious to a reasonably observant person," what counts as public-interest text, and any significant-modification questions.
Q2 2026 — build machine-readable marking (Art. 50(2))
- Implement machine-readable marks for synthetic output: for example HTML attributes, JSON-LD, or response/header metadata that a downstream system can read.
- Treat this as advisory metadata, not signed provenance. It is not C2PA certification and should not be treated as sufficient on its own. Consider the voluntary EU Code of Practice on AI-generated content as you decide how far to go.
- If a system is eligible for the 2 December transition, you can sequence this work after August — but only for that system, and only if it was genuinely on the market before the deadline.
July 2026 — verify and rehearse
- Test each disclosure in the real product flow, on the real surfaces users see, across web and mobile.
- Confirm the machine-readable marks are actually present and parseable in production output, not just in a design doc.
- Write down what you did: where each notice appears, how each mark is emitted, and the evidence that a given system was on the market before the deadline.
2 August 2026 — obligations apply
- Art. 50(1), (3), and (4) should be live in production for systems in scope.
- Art. 50(2) marking should be live too, unless a specific system is validly relying on the transition.
August through 2 December 2026 — close the marking transition
- Ship machine-readable marking for any eligible pre-existing systems still relying on the extension.
- Keep the "placed on the market before" evidence with the system record, so the basis for using the transition is documented rather than assumed.
A worked example
Imagine a B2B analytics app with two AI features. Feature A is a support chatbot, live since 2024. Feature B is an AI report-writer that generates client-facing text, launching in September 2026.
- Feature A (chatbot) — deployer duty under Art. 50(1): tell users they are talking to an AI. No December extension applies to 50(1), so this must be in place by 2 August 2026. Because it was on the market well before the deadline, any Art. 50(2) marking it needs for generated snippets could use the transition to 2 December 2026.
- Feature B (report-writer) — launches after the deadline, so it does not qualify for the marking transition. Its synthetic-text marking and any relevant disclosures need to be ready at launch. Because it produces text that a client may publish, the team should check whether Art. 50(4) is engaged and get counsel's read.
Two features, one product, two different timelines and two different roles. That is exactly why the assessment is per system, per product.
Keep it honest
Nothing here makes a product "compliant," and no checklist can. Article 50 and the official guidance — not this article — determine what is sufficient, and the facts of each system decide the answer. This is not legal advice; treat the borderline calls as questions for your counsel. What a good plan does is get the work started early, put the evidence on record, and remove the last-minute scramble.
Next step
If you want a structured way to walk your products through the Article 50 categories and see where the gaps are before 2 August 2026, run the free readiness check and use it as the starting point for a proper review with your counsel. Working backwards from the deadline beats reacting to it.