The EU AI Act requires providers of high-risk AI systems to keep automatically generated logs. This guide explains what that obligation actually demands in practice — and how tamper-evident logging maps to it. Note: this is engineering guidance, not legal advice; confirm your obligations with qualified counsel.
What the Act requires (in plain terms)
For high-risk AI systems, the EU AI Act requires logging capabilities that enable traceability: automatic recording of operations, with logs kept for an appropriate period. The underlying idea is simple and old — the same reason financial regulation requires audit trails: when an automated system makes consequential decisions, there must be a record that lets someone reconstruct what happened, after the fact, in a way the operator cannot quietly rewrite.
In practice, regulators and auditors evaluating your logging will ask:
- Are logs generated automatically, or does someone choose what to record?
- Do they cover the full operation — inputs, decisions, tool actions, outputs?
- Are they protected against tampering, or can they be edited after the fact?
- Can they be verified independently — by someone who doesn't trust your infrastructure?
- Are they retained long enough to matter?
Why ordinary application logs fall short
Most teams' first instinct is "we already log to our database / ELK / CloudWatch." An auditor's response: who can modify those logs, and how would you know? Standard application logs fail the third question above — they're mutable by anyone with database or console access, and their integrity rests on access controls that the incident itself may have compromised. That doesn't make them useless, but it makes them assertions, not evidence.
Mapping tamper-evident logging to the obligation
A hash-chained, append-only action ledger addresses each auditor question directly:
- Automatic: log at the tool-execution layer — every tool call, decision point, and output is posted to the ledger by the infrastructure, not by the agent's own discretionary code. The agent cannot choose to skip its worst action.
- Full operation: record agent_id, action type, tool name, input/output summaries, and metadata. The schema should be designed around the reconstruction question: "what did the system know, decide, and do, in order?"
- Tamper-protected: each record's SHA-256 hash commits to all previous records; the ledger is append-only. One-click verification recomputes the chain and reports the exact break point if anything was altered.
- Independently verifiable: signed Tamper-Seal certificates and public verification endpoints let an auditor check integrity without trusting your dashboard — or your word.
- Retained: exports (self-verifying CSVs where each row's prev_hash matches the previous row's hash) give you portable, long-lived copies independent of the live system.
What to log: a practical schema
For each agent action, capture at minimum:
- When: UTC timestamp, immutable once written.
- Who: agent identifier (and, in multi-agent systems, the causal parent — which action caused this one).
- What: action type (tool_call, decision, message), tool name, and concise input/output summaries.
- Chain data: sequence number, previous hash, record hash.
Avoid logging raw PII, credentials, or full document contents into the ledger — summaries and references are enough for reconstruction, and they keep the evidence artifact shareable with auditors without creating a second data-protection problem.
Retention and the "appropriate period"
The Act speaks of an appropriate retention period rather than a fixed number — which means you need a reasoned policy, not just a default. Document yours: e.g., "action ledgers retained for 24 months, certificates indefinitely, exports archived quarterly." Whatever you choose, the retention policy itself becomes part of what an auditor reviews. A tamper-evident ledger with a documented retention policy reads very differently from logs that expire on a 30-day rotation nobody chose deliberately.
Getting started without boiling the ocean
- Identify which of your agents are plausibly high-risk (consequential decisions, personal data, financial or legal effects).
- Instrument those agents first — one API call per action at the tool layer.
- Verify the chain weekly (automate it; alert on FAIL).
- Mint a certificate monthly and archive the export.
- Write the one-page logging policy: what you log, why, how long you keep it, who can verify it.
That one page, backed by a real tamper-evident ledger, is worth more in a compliance review than a hundred pages of logging architecture diagrams.