Most of the writing about the EU AI Act and agents describes a problem and stops there. "The EU AI Act's runtime problem." "Agents now have to say who sent them." The obligation is named; the owner of the answer is absent. This post takes the next step: what the obligation actually is, who carries which duty under Article 50, and the named standard for a runtime record of each decision.

The short version: agents that deal with people must disclose their artificial nature and the person on whose behalf they act (Article 50(1) and the Commission's guidelines frame that as a design-and-disclose duty for providers). Deployers have their own Article 50 duties under 50(3) and 50(4). Separately, organisations that want a regulator-readable trail of what the runtime decided need a record. That record problem is what this post is about. What follows is an operational bar for evidence, not a duty invented by Article 50 itself.

What Article 50 actually requires

Article 50(1) of Regulation (EU) 2024/1689 requires providers of AI systems that interact directly with natural persons to ensure those persons are informed they are interacting with an AI system, unless it is obvious. Article 50(3) and 50(4) add deployer duties: notice for emotion recognition and biometric categorisation, and disclosure of deepfakes and AI-generated text of public interest. These transparency obligations begin to bind on 2 August 2026, the same date the Commission's fining powers over general-purpose AI providers (Art. 101) take effect.

One boundary matters and is easy to overstate. The obligation attaches when an AI system deals with a person. So the defensible line is not that the agent economy cannot transact. It is narrower and sharper: an agent that deals with a person has to declare what it is, and on whose behalf it is acting.

The load-bearing text: the Commission's Article 50 guidelines

On 8 May 2026 the Commission published draft guidelines on the implementation of the Article 50 transparency obligations. The Commission adopted the final guidelines on 20 July 2026 (C(2026) 5054). They accompany Article 50 from 2 August 2026, and they are where the agent question is answered directly.

The final guidelines (paragraph 31) say that agents capable of making bookings, managing correspondence, negotiating or concluding contracts, or executing purchases must be designed and developed to disclose both their artificial nature and the person on whose behalf they act. The stated reason is precise, and it is the whole argument: to make the origin of the interaction, the delegation of authority, and accountability for the resulting actions visible. Backend machine-to-machine calls whose outputs are not intended to reach a natural person stay outside Article 50(1).

Read that against how agents are actually being shipped. An agent books a flight, sends an email, agrees to terms, completes a purchase. The counterparty is a person, or a company acting through people. The Act expects that interaction to carry a clear disclosure of artificial nature and delegated authority. That is a transparency design duty, not a free-standing statute that invents a deployer log format. Producing a reviewable runtime trail of what was allowed or blocked is a separate operational problem, and it is the one this post addresses.

The Code of Practice asks for compliance documentation. It does not produce the runtime record.

The Commission published the Article 50 Code of Practice on 10 June 2026. It is voluntary implementation support for Art. 50(2), (4) and (5) (not Art. 50(3)), not a new obligation. Article 50 of the Regulation remains the legal baseline. For deployer signatories, Section 2 Measure 2.1 commits them to an internal compliance process and documentation of how Art. 50(4)/(5) labelling is implemented, not a statutory artefact named an "evidence record."

Here is the gap that matters. The Code assumes you can produce that documentation. It does not supply machinery that writes a decision record at the moment an AI system acts. Browser-side checklists and marking validators around the Code are planning aids, not a compliance determination. Separately, where a deployment is high-risk, Article 26(6) sets a six-month floor for automatically generated logs under the deployer's control. Under Regulation (EU) 2026/1744 that floor binds with the Annex III high-risk package from 2 December 2027. It is not an Article 50 inventing a general record-keeping clause for every deployer.

So the deployer is left with a Code commitment to document disclosure practices, a product need for a defensible runtime trail, and nothing in the free tooling box that actually writes the record when the AI makes the call.

A cited decision record

Call the required record what it is: a cited decision record, the evidence an EU AI Act runtime enforcement audit trail needs, built from artifacts that already ship (the open-source cited Rego rule set, the Article 12 audit export, and the published GPAI benchmark), not from a new product layer.

In a cited decision record, every logged decision carries:

When a phrase rule fires and the decision is a denial, or when the injection check blocks, the record carries an article citation at article, paragraph, and sub-paragraph where the rule states them (the operative legal basis on the decision, not a generic "flagged" label). A wider-review block does not cite an article. Allow-path events keep hash, timestamp, and chain without inventing a citation that was never applied.

ComplyEdge writes this record for every request and answer it checks. When a phrase rule fires and the wider review does not clear it, the record carries the rule and the law it applies, and the request is blocked. Not a probability score, and not a log line that says "flagged" with no article attached. Export fields map to it: text_hash and timestamp on each event, the chain_ fields on every record written since the chain began, and chain_link in the Enterprise export; when a phrase rule fires, violations[].rule_description carries the article citation; /v1/audit/export is the regulator-readable package. ComplyEdge keeps the trail for 184 days, then expires it; Enterprise tenants can set a longer period (a product term; the Article 26(6) six-month floor binds only for high-risk deployments from 2 December 2027).

The enforcement rule set is open source, written in Rego, and each policy carries the operative text of the article it cites. What a policy establishes is not uniform, so we publish the split rather than a count. Every policy decides by matching the evaluated text (the policy itself does not call a model). On a paid plan, after a clean pass, an injection meaning check can still block when the month's model budget covers it. If that budget is used up, the phrase rules decide. For Article 5 prohibited practices, for example, the text is the regulated act: blocking it prevents the act, and the citation on the decision is load-bearing. The Article 50, Annex III, general-purpose AI and high-risk process policies fire on text describing a state the engine cannot verify. No text matcher establishes whether a technical file, a quality management system, a human-oversight assignment or a fundamental rights impact assessment exists, and this one does not claim to. Those policies are triage, not a compliance finding, and their silence is not one either. When one fires, the call is still blocked and recorded with its citation, like any other rule. On the published runtime benchmark, every prompt is a request that describes or asks for a violating deployment and the suite scores whether the live API blocks it. Run with model review turned on (the benchmark's default), the core EU AI Act categories block at 100 percent with zero false positives on the safe-harbour set: 39 of the 60 prompts were decided by the rules alone and 21 by model review. With model review off, only the prompt-security set has been measured (10 of 10). The benchmark code and result JSON are in the repository, dated, and reproducible against the live API with any key. Each rule has a stable ID in the rule set, with its citation and approval status. What the record itself must contain and prove now has its own versioned home: ADCR, the open Rulebook, version 0.1.0, in development.

One step stays with you, because the record never holds the text. Every check returns an event_id. Store it next to your own copy of the prompt or the answer, and when someone asks, send the pair to POST /v1/audit/verify (or the SDK's verify_input / verifyInput): the answer says whether that record was about exactly that text. Step by step: how audit reconciliation works.

Say what this is, and what it is not

ComplyEdge is the enforcement and evidence layer that writes a decision record at runtime. It records every decision it checks. The rule and the law are named when a phrase rule or the injection check fired. A wider-review block does not cite an article. If that review is on and clears every hit, the request is allowed. On every plan the record set exports with its hash chain, so an edit, a gap or a reordering after it was written shows when a reviewer checks it offline.

It is worth being equally clear about what ComplyEdge is not. It is not an agent identity system, and it does not issue or verify the mandate that authorizes an agent to act. Those are separate problems, and other layers will own them. What ComplyEdge does is check each request and answer against the rules at the point of action and record what was decided, with the rule and the law cited when a phrase rule or the injection check fired. That claim is narrow, and it is verifiable, and it is enough.

Where this sits in the stack

The stack a compliance-conscious AI team is being taught to assemble has a governance and risk layer, a system of record, and an observability layer. Those tell you what happened, after the fact. None of them enforces a regulation at the moment the text is checked, or hands a regulator a cited record of what was checked and blocked.

That is a fourth box: a runtime control plane that checks and records. It is where the article-cited denial and the decision record come from. When an agent acts for a person under Article 50, that fourth box is what turns "we have logs" into "here is the record of each decision, with the article cited when a phrase rule or the injection check fired."

The clock, stated honestly

Two dates, kept straight. 2 August 2026: Article 50 transparency obligations bind, and the Commission's Art. 101 fining powers over general-purpose AI providers take effect. The high-risk regime under Annex III did not move up; Regulation (EU) 2026/1744 (Digital Omnibus) deferred Chapter III Sections 1-3 for Annex III systems to 2 December 2027. This is a readiness argument, not a panic one. The transparency duty binds from that August date; the record-keeping capability is the thing worth having in place before a regulator, a counterparty, or a law firm asks to see it.

You can read the rule set, the Python SDK, and the runtime benchmark, all open source under Apache 2.0:

pip install complyedge

Repository: github.com/ComplyEdge/complyedge
Deployer obligations, mapped to the mechanism: Article 26 one-pager
Quick start: docs/quick-start
The rules and the law behind each one: the ComplyEdge rule set