The useful question is not whether the EU AI Act is "coming." It is what your agent can prove after someone asks how it works.

On 2 August 2026, Article 50 transparency duties started applying. The European Commission's own FAQ names chatbots, AI agents, and avatars as systems that can fall under the direct-interaction rule. If a person cannot reasonably tell that they are talking to a machine, the provider has to make that clear at the start of the first interaction. If the system creates synthetic audio, images, video, or text, the provider also has to support machine-readable marking and detection, subject to the specific scope and exceptions in the guidance.

That date is easy to misread. It is not a universal "all AI must now pass a high-risk conformity assessment" deadline. The Commission's current AI Act page says many high-risk system obligations begin on 2 December 2027, while the transparency rules in Article 50 apply from 2 August 2026. A team can therefore be late in two different ways: it can miss an immediate disclosure duty, or it can spend weeks building the wrong controls for a high-risk category that does not apply to its product.

Chart comparing the measured EU AI Act enforcement figures

What changes on August 2

Start with the interaction surface, not the model name. A background agent that moves data between internal services is treated differently than an assistant that talks directly to customers. The Commission says machine-to-machine systems without direct contact with people fall outside this particular interaction notice. That does not make them risk-free, but it changes the first release check.

For a customer-facing assistant, put the disclosure in the first visible interaction. Do not hide it in a privacy policy, a help page, or a tooltip that disappears on mobile. Record which text, voice prompt, or UI element delivered the notice, when it was shown, and which version of the agent served the session. The law is about informing people. Your engineering team still needs a way to show that it happened.

The Commission's operative dates are 2 August 2026 and 2 December 2026. Article 50 applies from the first date. The Commission describes a limited grace period for marking and detection for systems already placed on the market before 2 August 2026, with that grace period ending on the second date. It is not a reason to ship a new system without a marking plan.

There are narrower duties for deployers as well. A company using emotion recognition or biometric categorisation must inform exposed people. AI-generated or manipulated text published on matters of public interest without human review or editorial control must be clearly labelled. Deepfakes have their own definition and context tests. A blanket label on every output may be simple, but it is not the same thing as classifying the system and its use correctly.

This is where teams get into trouble. They treat a model card as a product control. It is not. The model provider can document a model, but the deployer owns the customer journey, the logging boundary, the human review path, and the release decision for the system it operates.

The maximum penalty in the Commission's Article 50 FAQ is 15 million euros or 3% of worldwide turnover for the preceding financial year. That is a ceiling, not a forecast. Still, it makes the operational lesson plain: a compliance statement without an event trail is a weak position when a regulator, customer, or internal auditor asks what the system showed and produced.

The evidence your agent must keep

Build a small evidence pack around the things that can change without a model retrain. At minimum, keep the deployed agent version, system prompt or policy version, model identifier, provider, region, enabled tools, disclosure text, marking method, and the timestamp of each release. For a user session, retain a privacy-reviewed record that can answer five questions: who interacted with the system, which version responded, what class of output it produced, whether a disclosure was shown, and whether a human reviewed or overrode the result.

Do not log everything forever by default. Define retention and access rules with the same care you apply to application logs. Redact personal data, separate payloads from metadata where possible, and make the audit record tamper evident. If the agent can call tools, log the tool name, authorization decision, arguments after redaction, result status, and the human or policy decision that allowed the call. A chat transcript alone will not explain why the agent was permitted to send an email, alter a record, or publish content.

Microsoft's open agent-governance-toolkit is useful here because its checklist is unusually blunt about its own limits. It maps 11 AI Act articles. Two are marked fully out of scope and nine are marked partially addressed. The document also says that zero of the 11 are fully covered. That is a better warning than a green compliance badge. A runtime toolkit can generate logs and policy checks while leaving data governance, staff literacy, legal classification, and deployer obligations outside its boundary.

The checklist calls out a concrete logging requirement under Article 12: high-risk systems must technically allow automatic recording of events over the system's lifetime. Its own coverage summary reports 2 of 11 and 9 partially addressed: two mapped articles are fully out of scope, nine are only partially addressed, and zero are fully covered. That is a better warning than a green compliance badge. A runtime toolkit can generate logs and policy checks while leaving data governance, staff literacy, legal classification, and deployer obligations outside its boundary.

A practical release gate looks like this:

  • Verify the intended use against the Commission's risk categories. Do not rely on a keyword classifier alone.
  • Test the first interaction in every supported language and UI path. The disclosure should be visible before the agent asks for sensitive information.
  • Generate each supported output type and inspect whether the mark survives storage, transformation, export, and publication.
  • Exercise tool calls with denied permissions, expired credentials, and a human override. Capture the resulting events.
  • Freeze the evidence pack for the release. Store the exact policy, model, tool manifest, disclosure copy, and test results together.
  • Assign an owner who can explain the system to a regulator or customer without saying that the model "usually" behaves that way.

The existing NestFrontier analysis on why approval prompts miss agent threats covers the human side of this problem. Prompt approval is not a substitute for scoped credentials, logging, or a safe default. The same principle applies here: a notice is not evidence that the rest of the system is under control.

The release decision

If your agent speaks directly to people, add the disclosure test to the release pipeline now. If it publishes synthetic content, add a machine-readable marking test and verify the mark after every transformation step. If it operates only in the background, document why Article 50's direct-interaction notice does not apply and keep the classification decision with the system record. If the agent touches employment, credit, education, critical infrastructure, biometrics, or another Annex III area, treat that as a separate classification project instead of assuming the August transparency work is enough.

The strongest implementation is not the one with the largest policy document. It is the one that can reconstruct a disputed interaction without guessing. August 2 made that a production engineering concern, whether or not the agent itself looks like a legal product.

Sources