EU AI Act Article 12: Logging Requirements for Autonomous AI Agents (2026 Guide)

High-risk obligations apply from August 2, 2026. If your AI agents take consequential actions, your logs are about to matter a lot more.

The EU AI Act is the world's first comprehensive AI regulation, and its teeth are arriving. The bulk of the obligations for high-risk AI systems apply from August 2, 2026, and non-compliance carries penalties of up to 7% of global annual turnover. One requirement that quietly affects almost every team running consequential AI agents is Article 12 — record-keeping (logging).

This is a practical guide to what Article 12 asks for and how to build agent logging that satisfies it. (This is general information, not legal advice — confirm your specific obligations with qualified counsel.)

What Article 12 actually requires

Article 12 requires high-risk AI systems to automatically record events ("logs") over the lifetime of the system. The logging has to enable:

• Traceability of the system's functioning, appropriate to its intended purpose.
• Identification of situations that may cause the system to present a risk or undergo a substantial modification.
• Post-market monitoring and the ability to reconstruct what happened.

Retention is generally at least six months (unless other law requires longer), and the logs must be kept under the provider's control and producible to authorities on request. In short: you must be able to show what your system did, when, and in what context — reliably, after the fact.

What that means specifically for AI agents

An autonomous agent isn't a static model serving predictions; it acts. So "traceability" for an agent means capturing, for every consequential decision:

• Which agent acted, and on whose behalf (the delegation chain).
• What action it attempted, against which resource.
• The context at decision time (time, environment, relevant attributes).
• The outcome — allowed, denied, or escalated for approval — and which policy produced it.
• Who approved anything that required human sign-off.

If you can't reconstruct that chain for an incident or an audit, you don't have traceability — you have noise.

Why ordinary application logs don't satisfy it

Most teams assume "we have logs" covers this. Usually it doesn't:

• They're mutable. Standard logs can be edited or deleted. Article 12 is about evidence; a record anyone can alter after the fact proves little.
• They're not decision-centric. App logs capture HTTP requests and stack traces, not "agent X, acting for user Y, was denied action Z by policy P at time T."
• They're scattered. Reconstructing one agent's behavior across services, retries, and sub-agents is painful when the data isn't designed for it.
• They lack the delegation context that makes agent accountability meaningful.

The technical standard: append-only and hash-chained

The control that maps cleanly onto Article 12's traceability and integrity expectations is an append-only, hash-chained audit log. Each event records the decision and its context, plus a cryptographic hash that links it to the previous event (SHA-256 is the de-facto standard). The result:

• Tamper-evidence. Altering or deleting a past record breaks the chain and is detectable on the next integrity check.
• Reconstructability. Every agent decision is a structured, queryable record — you can replay exactly what happened.
• Provability. You can demonstrate to an auditor that the trail is complete and unmodified.

This is also the same control that underpins SOC 2, ISO 27001, and ISO 42001 evidence — so building it once serves multiple frameworks.

How to implement it

1. Centralize the decision. Route consequential agent actions through a single decision point that returns allow / deny / require_approval. That gives you one consistent place to log every action and its outcome.
2. Record the full context. Capture subject (agent + on-behalf user), action, resource, runtime context, outcome, and the policy that matched — not just "request succeeded."
3. Make it append-only and chained. Append each event to a hash-chained log; never update or delete. Run periodic chain-integrity checks.
4. Capture approvals. When a human approves or rejects an action, record who, when, and the note.
5. Set retention and export. Keep at least six months; make the log exportable for regulators and your own audits.

How Kynara maps to Article 12

Kynara is a permission control plane for AI agents, and its audit log is built for exactly this. Every decision the engine makes — for any agent action or MCP tool call — is appended to a SHA-256 hash-chained log that records the subject, on-behalf user, action, resource, context, outcome, and matched policy. Approvals are recorded with the reviewer and rationale. The chain is verifiable, the records are exportable, and the same trail supports SOC 2, ISO 27001, ISO 42001, and EU AI Act conformance.

Practically, that means when August 2, 2026 arrives — or when an incident does — you can answer the only question that matters to a regulator: what did this AI agent do, on whose behalf, and can you prove the record is intact?

Building toward EU AI Act readiness for your agents? See how Kynara's tamper-evident audit log works, or book a demo. This article is general information, not legal advice.