Updated 8 September 2026: Article 50 transparency obligations apply from 2 August 2026. This page previously described the rule as scheduled. It now reflects the live application date and the narrow legacy deadline described below.[1][2]
Article 50 is no longer a future-date problem. If your team runs an interactive agent, ships synthetic content or publishes AI-generated material for the public, the question is not “have we mentioned AI in the policy?” It is: what does the person see, who owns the signal—and what can the system do next?
A disclosure can make an AI interaction visible. It cannot stop the agent from taking a live action. That is where the policy page ends and the operational work begins.
This is a technical readiness guide, not legal advice, certification, regulator approval or a conclusion that Article 50 applies to a particular system.
What changed — and the date that matters
Article 50 applies from 2 August 2026. The European Commission says providers and deployers of AI systems must comply with the transparency obligations from that date.[1][2]
There is a limited transition date: providers of synthetic-output systems placed on the market before 2 August 2026 have until 2 December 2026 to take the necessary steps for Article 50(2) marking and detection. That is not a general extension for Article 50.[1][2]
Who should map their systems now
Applicability depends on the system, the organisation’s provider or deployer role, how people encounter the output, and the Article’s exceptions. Confirm scope with qualified counsel.
- Directly interactive AI providers: assess whether people are informed that they are interacting with AI, unless that fact is obvious in the circumstances and context.[1]
- Generative AI providers: assess the machine-readable marking and detectability path for covered synthetic audio, image, video, and text outputs.[1]
- Deployers of emotion-recognition or biometric-categorisation systems: assess notice to people exposed to the system and applicable data-protection obligations.[1]
- Deployers of deepfakes or certain AI-generated public-interest text: assess disclosure, timing, accessibility, editorial-responsibility, and other stated exceptions.[1][3]
The operational trap: treating 2 December as a universal delay
The Commission confines the limited grace period to Article 50(2) and pre-2 August synthetic-output systems. Teams should not use it as a reason to defer direct-interaction notice, deployment disclosure analysis, or the responsibility mapping that makes compliance work possible.[1][2]
The use case: the AI tells the customer—then it tries to move money
Consider an illustrative HaltState product scenario, not a reported enforcement case.
Demonstration scope: In an isolated test, the real committed policy engine returned APPROVAL_REQUIRED under an authored demo policy. This was a policy/evidence test, not a payment integration: no payment was executed, no human approval was performed, and human review remains pending. Its evidence was HASH_ONLY, not signed. Nonmatching fixture variants returned default ALLOW, not safety denials. This is not an Article 50 refund rule or a claim about production tenant settings.
An EU-facing support agent opens a customer chat, handles the complaint and then attempts refund.create USD 520.
Two different control problems now exist:
- At first contact: the team must determine whether Article 50 requires the person to be told they are interacting with AI, unless that is obvious in the circumstances.[1]
- Before the refund reaches the payment system: the team must decide whether the agent is allowed to move the money without review.
HaltState addresses the second problem at the live action boundary:
refund.create USD 520reaches the threshold before execution.- Policy, amount, time and role checks run against the action.
- The threshold returns APPROVAL_REQUIRED rather than allowing the refund to pass silently.
- It waits for human review. The decision record retains the timestamp, policy version, decision, evidence identifier and verification result.
That does not “make the system Article 50 compliant.” The customer still owns the legal analysis, the notice and any required output marking. What HaltState closes is the operational gap between saying the AI exists and controlling what that AI is allowed to do next.
A five-step Article 50 readiness check
1. Inventory human-facing surfaces
List direct interactions, synthetic-output paths, public communications, and systems that expose people to relevant biometric categorisation or emotion-recognition functions. Describe the real surface, not just the model or vendor name.
2. Assign the legal role before assigning a task
Record the provider or deployer role for each surface with counsel. Article 50 distributes duties by role; a generic “AI owner” is not a substitute for that analysis.[1][3]
3. Test the first real encounter
For the relevant surface, verify what a person sees at the first interaction or exposure, whether the signal is clear and distinguishable, and whether accessibility requirements are met.[1]
4. Test the marking and disclosure path
Where Article 50(2) or (4) may apply, identify the marking or disclosure mechanism, its owner, the exception relied on if any, and the evidence that the control operated. The Commission guidance explains the role-specific scope and examples; it does not remove the need to analyse the actual system.[3]
5. Keep a bounded evidence trail
Retain the workflow map, role decision, implementation owner, test result, exception rationale, and change record. This supports review when a system, guidance, or user-facing experience changes.
What HaltState fixes—and what it does not
The notice answers: “Who am I talking to?” HaltState answers a different operational question: “What is this system allowed to do now, under which policy, with what evidence?”
A required disclosure remains the customer’s responsibility. HaltState does not determine whether Article 50 applies, provide legal advice or substitute for user-facing notice, output marking, legal scope or retention policy.
Its role is narrower and concrete: place a control in the live action path, return an explicit outcome and preserve a bounded decision record. Any product demonstration must use a clean source commit, masked inputs and an isolated sanitized run; it must not imply customer activity or legal approval.
See the governed action flow or discuss Article 50 readiness.
General information only. This article and video are not legal advice.