The EU AI Act's logging rule moved to December 2027. The logs did not get easier.

Emek Can Doğru — Thu, 17 Sep 2026 22:23:22 +0000

The Digital Omnibus on AI (Regulation (EU) 2026/1744) was published in the Official Journal on 24 July 2026 and entered into force three days later. The obligations for high-risk AI systems, including record-keeping, now apply from 2 December 2027 for the stand-alone systems in Annex III and from 2 August 2028 for AI built into regulated products. If you read a post this summer that said "August 2026", that date is gone. The rule is not.

Article 12 of the Act is short. A high-risk system must technically allow the automatic recording of events over its lifetime, and those records must be good enough to trace a situation that turned risky, to support monitoring after the system is on the market, and to follow how the system operates. That is the whole requirement, and it is a requirement about what the system can record, not about what a dashboard shows.

Why an agent's logs do not pass this today

Most agent stacks log. Almost none of them keep records. The difference is what is missing from the line:

Who asked. A log line names a service account, not the agent, its scopes, or the human who was behind it.
What was asked. The prompt is there, the actual tool call with its arguments often is not, and nothing ties the two together.
Which rule decided. The line says the call ran. It does not say which policy, at which version, allowed it, or why a refused call was refused.
What happened. The result is somewhere else, in another log, with another timestamp.
Whether the line is still the original. A text log can be edited, trimmed, or lost, and afterwards nobody can tell.

And the logs sit in a vendor's cloud. When the question is asked, the answer belongs to someone else.

What a record needs

We ended up with five parts, and each one answers a question an auditor actually asks.

Identity and scope. The agent connects with a token, and the token names what it may do: read, memory, act, pay, approve, audit. No default token; the gate does not open until this is configured.
The request. A hash of the exact call, so the record and the call cannot drift apart.
The decision. Allow, deny, or wait for a human, with the policy hash and a reason code. A refusal is written the same way as an approval; silence is not a record.
The effect. After the call runs, an effect row with the result hash, reconciled against the decision that allowed it. audit.explain reads a decision back with its chain, its signatures and its findings.
A signature and a chain. Each record is signed, each carries the hash of the one before it, and a copy of the ledger is kept beside the original. verax doctor says when the copy and the ledger disagree.

How Verax does it

Verax is an open-source MCP server (Apache-2.0) that sits between an agent and its tools. Every tool call passes a policy gate and leaves a signed decision record before anything runs. Every call that ran leaves an effect row that is reconciled against its record afterwards. A call the policy will not decide alone is held until an operator on that machine approves it, from the panel or the command line. The ledger stays on the machine the body runs on, and the record does not leave it.

A few things we had to build this week to make that hold under load, measured on one laptop with 150 agents over 30 days of synthetic traffic (200,000 decisions), and shipped in 0.1.2: the ledger is cut into pieces of 50,000 rows with a persistent ref index, so a restart reads the open piece and the index rather than every record ever written (1.9 s and 518 MB at 200k with both pieces closed); a day's window costs the day's rows, not the ledger's age; verax doctor compares the evidence copy and the index to the pieces and says when they disagree. The same release closes six faults an outside review reproduced on the earlier code: parallel calls passing a rate limit, one ref running a tool more than once, a daily spend cap passed by parallel requests, one request approved more than once, a tenant's own memory record hidden by another tenant's, and a retry running on an approval after the token had lost its scope. Each has a guard now.

What it does not do

We keep this list on the website and it belongs here too. Today the same system keeps the record and signs it; a separate witness process exists, an independent one does not. There is no tenant boundary. On a single-copy ledger, silence cannot be told from nothing happening. Payloads sit in plaintext. No independent audit has been done. And whether a given deployment meets Article 12 is a conformity question for your assessor, not a claim we make.

Try it

npm install -g @verax-ai/body (0.1.2, published with provenance from the repository), then verax doctor names what the body still needs before it listens (Node 22.6 or newer). The entry in the official MCP Registry is io.github.verax-ai/verax; the code is at https://github.com/verax-ai/verax and the site is https://verax-ai.com. The free tier is the open-source install; the pilot is how companies run it with us. Questions and disagreements welcome in the comments; the record format is Cedulon's, and it is open too.

DEV Community: Emek Can Doğru

The EU AI Act's logging rule moved to December 2027. The logs did not get easier.

Why an agent's logs do not pass this today

What a record needs

How Verax does it

What it does not do

Try it