What the EU AI Act's Logging Rules Actually Demand of Your AI Agents (and Why Most Logs Fail the Test)

Meta description: Article 12 of the EU AI Act requires automatic, traceable logs from high-risk AI systems. Here's what that means for autonomous agents, and why your app logs won't cut it.

If you run an autonomous agent that touches anything regulated (credit decisions, hiring, medical triage, critical infrastructure), the EU AI Act already has an opinion about your logs. Most teams find out what that opinion is during an audit, which is the worst possible time.

The short version: your existing application logs almost certainly do not satisfy Article 12, and the gap is not about volume. It's about who generated the record, whether it can be trusted, and whether it captures what the agent actually did versus what your app thought it did.

What Article 12 actually says

The text is deceptively simple. High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. Two words are carrying the load: "automatic" and "over the lifetime."

Automatic means the system produces logs on its own. Automatic means the system generates logs on its own, and you can't satisfy this with manual record-keeping. A developer remembering to add a logger.info() call around a tool invocation is not automatic. It's discretionary, and discretionary logging is exactly what fails when someone is under pressure to ship.

"Over the lifetime" means traceability from deployment to decommissioning. Logs must allow full traceability of the system's operation from deployment through decommissioning. Not a rolling 30-day window that ages out. Not whatever survived the last log rotation.

And here is the part buyers keep missing: buying the model or the agent framework from someone else does not move the obligation off your desk. Purchasing a high-risk AI system from an external vendor does not exempt you from any of this. The deployer remains accountable for log retention and accessibility regardless of who built the system.

So if you're deploying a Claude, GPT, or Gemini agent into a high-risk workflow, "Anthropic logs it" is not an answer. You are the deployer. The record is your problem.

Why your current logs quietly fail

Most teams already log agent activity. They still fail the spirit and often the letter of Article 12 for three reasons.

The logs describe intent, not action

Your app logs what your code decided to do. They do not necessarily capture what the model proposed before your code got involved. If an agent tried to run DROP TABLE users and a downstream guardrail caught it, does that attempt appear anywhere? In most stacks, no. The blocked action leaves no trace, which means your audit trail is a record of successes, not a record of decisions. An auditor investigating a near-miss has nothing to look at.

Article 12 is about traceability of the system's functioning, including the moments where it posed a risk. A log that only shows what executed is a log that hides your close calls.

The logs are trivially editable

Application logs live in a file or a log service that your engineers can write to, rotate, and (in principle) alter. That's fine for debugging. It's close to worthless as evidence. If the person being audited can edit the audit trail, the trail proves nothing. An auditor knows this, and a serious one will ask how you'd detect tampering. "We trust our team" is not a control.

The logs are generated inside the thing being governed

If your logging lives in the same application as the agent, then a prompt injection, a bad tool loop, or a compromised process can suppress or corrupt the very records you'd need to reconstruct the incident. The observer and the observed are the same system. That's a structural problem no amount of log volume fixes.

What auditors actually want to see

Strip away the framework language and an auditor is asking four questions:

• Completeness. Every consequential action, including the ones you blocked. Not a sample.
• Attribution. Which agent, which model, which policy decision, when.
• Integrity. Proof the record wasn't altered after the fact.
• Independence. The ability for someone outside your team to verify all of the above without taking your word for it.

The first two are an engineering effort. The last two are where most homegrown solutions collapse, because integrity and independent verifiability are not things you bolt on later. They have to be baked into how the record is created.

What a record that passes actually looks like

This is the gap Atested is built to close, and the design maps almost line for line onto what Article 12 is reaching for.

Atested sits as an HTTP proxy between your agent and the model provider. Every action the model proposes gets classified ALLOW or DENY and recorded before it can touch your systems. That placement matters for compliance: because it's on the API connection rather than inside your app, it captures the model's proposed action independent of whether your app-level code ever ran. The blocked DROP TABLE shows up. The runaway loop shows up. Your "record of decisions" is actually complete, not a highlight reel of what happened to succeed.

Because it's a proxy and not a code-level logger an engineer has to remember to call, the recording is automatic in the sense Article 12 means. It happens on the connection, every time, with zero tokens spent and latency you won't notice. Nobody decides per-call whether to log.

On integrity, this is where cryptography earns its place instead of being buzzword decoration. Each record is Ed25519 signed and hash-chained. Signed means the record is provably from your governance layer and not forged. Hash-chained means each entry commits to the one before it, so removing, editing, or reordering a single record breaks the chain and is detectable. You cannot quietly delete the embarrassing entry. That's tamper-evidence, and it directly answers the auditor's "how would you know if this was altered" question.

And it's independently verifiable. Anyone with the public key can check the signatures and the chain themselves. That's the difference between "trust our logs" and "here is math you can verify without trusting us," which is exactly the posture you want to be in across the table from a regulator.

Setup is one environment variable and roughly five minutes from a GitHub install, across Anthropic, OpenAI, and Gemini agents, so this isn't a six-month compliance program. It's a proxy config change.

The honest limits

Article 12 has domain-specific requirements too, especially for biometric and Annex III systems, where the system should also record details like when it was used, the database it checked data against, the data that matched, and who verified the results. A governance and observability layer gives you the tamper-evident action record and the decision trail. It does not automatically know your reference databases or your human reviewers. You still map those domain fields yourself. What you get is the hard part solved: an automatic, complete, integrity-protected, independently verifiable record of what your agent proposed and what was allowed to run.

The takeaway

The regulation isn't asking for more logs. It's asking for logs that are automatic, complete over the system's life, and trustworthy enough that someone who doesn't trust you can still verify them. App logs are none of those things by default. If you're deploying agents into anything the AI Act calls high-risk, the question isn't whether you're logging. It's whether the thing you're logging with was designed so that the record survives contact with an auditor, an incident, and your own engineers' write access.

See how the governance layer is built at https://www.Atested.com.