EU AI Act Makes Agent Disclosure a Runtime Decision, Not a UI Label

On 2 August 2026, the EU AI Act’s Article 50 transparency obligations began to apply. For organizations operating interactive or generative AI, this is a live operating requirement rather than a future compliance workstream. The immediate implication is not that every agent needs a new disclaimer. It is that disclosure can no longer be treated as a fixed visual feature of a chatbot or a generic setting on a model.

Article 50 assigns different duties according to an organization’s operational role and the interaction or output at issue. That distinction matters for agent systems. A single agent may converse with a customer, prepare internal material, generate media, route a draft for human review, and publish an output through a separate channel. Those are not one transparency event. They are several events with different facts, destinations and potential duties.

What changed on 2 August

The change is the applicability of Article 50’s transparency obligations. The European Commission published implementation guidelines for providers and deployers ahead of the date. Providers of AI systems designed to interact directly with natural persons must design those systems so affected people are informed that they are interacting with AI, subject to the regulation’s specified exceptions.

Providers of generative AI systems also have obligations concerning generated or manipulated outputs. They must mark such outputs in a machine-readable format and make them detectable as artificial, using solutions that are effective, interoperable, robust and reliable as far as technically feasible. The standard is deliberately qualified. A machine-readable mark is not an infallible proof of authorship, provenance or truth; it is a transparency measure bounded by technical feasibility, content limitations, implementation cost and the state of the art.

Deployers have their own, separate duties. People exposed to emotion-recognition or biometric-categorisation systems must be informed. Deepfakes must be disclosed. AI-generated or manipulated text published to inform the public on matters of public interest generally requires disclosure. The same organization can be a provider in one part of a system and a deployer in another. A practical control design must be able to represent that distinction rather than assume a single legal posture for the whole stack.

What did not change

Article 50 did not make the entire AI Act fully applicable at once. The Commission’s timeline includes later application dates for high-risk systems, including 2 December 2027 and 2 August 2028 for AI embedded in regulated products. Nor did Article 50 establish one universal banner for every AI-enabled interaction. Its obligations distinguish direct interaction, generated-content marking, deepfakes, public-interest text, emotion recognition and biometric categorisation, and they include exceptions.

It also did not turn runtime observability into legal compliance. Logs, policy engines and evidence stores can make a control enforceable and inspectable. They cannot determine, by themselves, whether an organization is a provider or deployer in a particular case, whether an exception applies, or how the final legal text applies to a deployment. Those remain questions of role, purpose, context and legal interpretation.

Why a UI label is the wrong control boundary

A permanent “AI assistant” label is useful product communication, but it is an inadequate control boundary for an autonomous organization. It cannot tell whether the current session is a direct interaction with a natural person; whether the output is generated or manipulated content; whether that output is being kept inside an internal workflow or released publicly; whether a human has substantively reviewed it; or whether the current task falls within a specified exception. A label knows where it is rendered. A governance system must know what is being done.

This is especially clear in multi-step workflows. An agent may draft a public-affairs brief, ask a human reviewer for edits, convert an approved passage into a visual asset, and distribute the asset to a publication channel. Disclosure and marking decisions may differ at each boundary. Hard-coding a notice in the original chat window leaves later transformations and destinations outside the control. Conversely, forcing every output through every notice creates noise, weakens meaningful transparency and ignores the distinctions the regulation makes.

“Transparency is not a property of a model. It is a control applied to a specific action, output and audience.

The runtime decision an agent system needs

The architectural inference is straightforward: evaluate a disclosure policy when an agent is about to interact, emit, transform or publish. The policy decision needs an execution context, not merely an agent name or a model identifier. At a minimum, the context should establish the operator’s role for this function; whether a natural person is directly interacting with AI; the output modality; the intended destination and audience; whether the content is generated or manipulated; and whether a relevant human-review state or exception has been established.

• Role: is the organization acting as provider, deployer, or both across the relevant service boundary?
• Interaction: is a natural person directly interacting with the AI system, and does a specified exception apply?
• Content: is the system emitting generated or manipulated text, image, audio, video or another output modality?
• Destination: will the output remain internal, be sent to an individual, or be published to inform the public on a matter of public interest?
• Condition: does the workflow involve emotion recognition, biometric categorisation or a deepfake, and is human review relevant to the decision?
• Action: should the runtime present a notice, attach a machine-readable mark, require a disclosure before release, route the task for review, or prevent publication pending a decision?

The point is not to encode a legal conclusion in a simplistic rules table. It is to make the facts that support a disclosure decision explicit at the moment they can still affect execution. A release gate can add a required notice before publication. A media-export service can invoke the approved marking mechanism. A conversational channel can present an appropriate notice at the interaction boundary. A workflow whose context is incomplete can stop for classification or escalation rather than silently proceed.

Evidence must describe the control, not just the output

For autonomous operations, the decision must leave an evidence trail. Retaining only the final artifact is insufficient: it may show that a marker or notice exists, but not which rule was evaluated, what facts were available, whether an exception was asserted, or whether the required control executed before release. The relevant record is a disclosure-control event attached to the run and to the release boundary.

That event should identify the applicable policy version, the evaluated role and content context, the decision, the notice or marking action taken, the destination, the time of execution and the relevant approval or escalation reference where one exists. This is not a claim that a record proves compliance. It is the minimum operational structure needed to investigate a release, improve controls and demonstrate that transparency was treated as an executable responsibility rather than a design intention.

The operating consequence

Organizations should now map Article 50-relevant moments through their agent workflows: first contact with a person, generation or manipulation of content, conversion between modalities, handoff to a human, and publication or distribution. They should identify who operates each boundary, which system can apply a notice or mark, and what evidence survives the run. The exercise will expose a common gap: policy is often written at product level while consequential actions occur in services, queues and connectors far from the visible interface.

The durable design is to place disclosure policy beside authorization, routing and release controls in the governed runtime. That does not make a system compliant by architecture alone. It does give an autonomous organization a way to apply distinct transparency controls at the point of action, adapt them to real execution context, and preserve an accountable record of what happened. Article 50 is now applicable. The question is no longer whether transparency belongs in the operating model, but whether the operating model can execute it.