European Union transparency readiness

EU AI Act Article 50 readiness for AI agents

Technical controls and evidence supporting transparency readiness for interactive and generative AI systems.

The Article 50 transparency obligations covered here apply from 2 August 2026. That date is specific to these transparency duties; it does not mean every EU AI Act high-risk-system requirement starts on the same date.

This is a technical readiness guide, not legal advice, certification, regulator approval, or a determination that Article 50 applies to a particular system.

Discuss EU Article 50 readiness Inspect the control catalogue

Official status Scheduled law

Issuer European Commission

Guidance published 20 July 2026

Applies from 2 August 2026

Last verified 27 July 2026

Who should review this now

Likely affected providers and deployers

Applicability depends on the system, the organisation's provider or deployer role, how people encounter the output, and the Article's exceptions. Confirm legal scope with qualified counsel.

Providers of AI systems intended to interact directly with peopleReview how and when the system tells a person that they are interacting with AI.
Providers of generative AI systemsReview machine-readable identification and detection of covered synthetic audio, image, video, and text outputs.
Deployers of emotion recognition or biometric categorisation systemsReview notice to people exposed to those systems and the applicable data-protection basis.
Deployers using deepfakes or AI-generated public-interest textReview disclosure duties, format, timing, and the source's stated exceptions.

Article 50 in operational terms

What the official text requires teams to examine

These summaries are deliberately concise. Use the regulation and Commission guidelines below for the complete wording, exceptions, and role-specific detail.

Article 50(1)

Inform people at the first interaction

Covered direct-interaction systems generally need to make the AI interaction known unless it is obvious from the circumstances and context.

Article 50(2)

Support machine-readable synthetic-output detection

Covered generative systems need technical measures that make synthetic audio, image, video, or text output identifiable and detectable, subject to the Article's exceptions.

Article 50(3)

Notify people exposed to emotion or biometric categorisation

Deployers of covered emotion-recognition and biometric-categorisation systems need to inform exposed people and observe applicable personal-data rules.

Article 50(4)

Disclose deepfakes and certain public-interest text

Deployers need to disclose covered deepfake content and certain AI-generated or manipulated text published to inform the public, with source-specific exceptions.

Article 50(5)

Make disclosures clear, timely and accessible

Required information must be clear and distinguishable no later than the first interaction or exposure and must meet applicable accessibility requirements.

supports evidence

Reviewed HaltState controls that can support the evidence path

Retain declared agent and action labels, best-effort execution reports, and hash-referenced refund evidence relevant to an interaction.

HS-IDENT-001 Native control

Attribute a proposed action to a declared agent

Bind each guard request and evidence record to a stable agent label within the authenticated tenant context.

Enforcement point: Guard request ingestion and decision recording.
Evidence link: /haltstate/docs/guard-pattern
Customer responsibility: Provide a trustworthy agent label and protect the tenant credentials that establish request scope.
Control limitation: The agent label is caller-supplied attribution metadata, not cryptographic workload identity or proof of the human principal.

HS-ACTION-001 Native control

Declare the business action before its side effect

Submit the intended action and bounded context to HaltState before the protected system is changed.

Enforcement point: Immediately before the customer-owned tool or business action executes.
Evidence link: /haltstate/docs/guard-pattern
Customer responsibility: Wrap every protected side effect and remove unguarded execution paths.
Control limitation: The customer must place the guard call before every protected side effect and must not provide an unguarded bypass.

HS-REPORT-001 Native control

Receive and best-effort record an execution report

Accept an authenticated guard report, attempt to update a matching approval context, write an action-log entry, and emit a runtime event.

Enforcement point: After allowed execution succeeds or fails.
Evidence link: /live/
Customer responsibility: Report the final execution result accurately, retain the operation-to-report binding in the customer ledger, and verify durable receipt when that matters.
Control limitation: This is report receipt and best-effort recording, not proof that a guarded action was durably linked. Immediate ALLOW can have no approval row; the endpoint does not check whether its UPDATE matched a row; the idempotency key is not written to the action log; and event emission failures are ignored.

HS-EVID-001 Demonstrated integration

Hash a redacted refund evidence document before proof storage

The refund worker computes SHA-256 over the canonicalized redacted in-memory evidence document and stores that digest beside a logical haltstate:// artifact URI in a Proof Pack.

Enforcement point: After the governed workflow has a final decision and before the demonstrated refund execution is recorded.
Evidence link: /live/
Customer responsibility: Supply accurate redacted evidence, independently verify exported evidence when integrity assurance is required, and retain records according to policy.
Control limitation: The artifact URI is logical and the verifier does not recompute the embedded action-evidence hash. The live page demonstrates Proof Pack integration only, not evidence integrity. This is not a digital signature, external timestamp, immutable store, or legal certification.

Public evidence and implementation detail

Inspect the demonstrated boundary before relying on it

Live governed action feedSee the public, sanitized refund-agent decision and evidence projection. Guard integration patternReview where a customer-owned worker calls HaltState before a protected side effect. Runtime Control CatalogueInspect every control's capability status, evidence links, customer responsibility, and limitation.

Readiness checklist

Prepare the interaction, control, and evidence path

Inventory affected surfaces.List direct-interaction agents and covered generative output paths.
Assign the legal role.Record provider or deployer responsibility and the relevant Article 50 paragraph with counsel.
Name the disclosure owner.Assign user notice, output-marking, accessibility, and exception decisions to accountable teams.
Declare governed actions.Bind stable agent and action labels at the guard boundary before protected side effects.
Retain bounded evidence.Define reporting, evidence, redaction, access, and retention requirements outside the agent's control.
Test the real experience.Verify first-interaction notice, machine-readable marking where applicable, human escalation, and accessible presentation.
Review exceptions and drift.Document source-based exceptions and revalidate the implementation as guidance or system behavior changes.

Responsibility boundary

HaltState supports technical readiness; the customer owns legal scope and disclosure delivery.

The provider or deployer owns user-facing disclosure, synthetic-content marking, legal scope, and retention policy.

Reporting is best-effort and the refund evidence verifier does not recompute the embedded action-evidence hash. HaltState does not display every required disclosure or determine whether Article 50 applies.

HaltState does not determine whether Article 50 applies and does not provide legal advice.
HaltState does not draft or display every required disclosure; notice content, placement, timing, accessibility, and exceptions remain customer responsibilities.
Machine-readable synthetic-output marking requires customer integration with the system that generates or publishes the output.
Execution reporting is best-effort, and the demonstrated refund evidence verifier does not recompute the embedded action-evidence hash.

Deployment review

EU Agent Transparency and Control Readiness Sprint

Map affected agent surfaces, Article 50 responsibilities, guarded actions, customer-owned disclosure work, and evidence gaps into a practical implementation plan.

Discuss the EU readiness sprint

Primary sources

European Commission guidance and the regulation

Last verified 27 July 2026. Official sources can change; confirm the current text before making legal or deployment decisions.