EU AI Act · June 7, 2026

How to Produce EU AI Act Article 12 Audit Logs for AI Agents

Article 12 of the EU AI Act puts a record-keeping obligation on high-risk AI systems. If you run an AI agent that falls in scope, you need logs an auditor can actually rely on — not application logs that anyone with shell access could rewrite. Here is what the obligation asks for in plain terms, and how to generate logs that satisfy it.

What Article 12 actually requires

Article 12 ("Record-keeping") requires that high-risk AI systems technically allow for the automatic recording of events ("logs") over the lifetime of the system. The logs must enable the identification of situations that may cause the system to present a risk, support post-market monitoring, and make traceability possible across the system's operation. Related provisions (Article 19 on log retention, Article 26 on deployer obligations) expect those logs to be kept and producible on request.

Two things matter for an AI agent specifically:

• Coverage. You record the events that let someone reconstruct what the agent did — the inputs it received, the tools and external systems it invoked, the decisions or outputs it produced, and the timestamps tying them together.
• Trustworthiness of the record. A log is only evidence if it can be shown not to have been altered after the fact. A plain text file or a database row carries no such guarantee. This is the gap most teams discover late.

Article 12 requires tamper-evident logging. It does not require deterministic replay, and it does not require you to retain raw model weights. A signed, hash-chained log clears a bar that mutable application logs simply do not.

Note on timing: the high-risk obligations have been subject to phased application, and the relevant high-risk deadlines extend into 2027, with general-purpose AI model obligations applying from August 2, 2026. Check the current consolidated text and your own classification with counsel — this article is engineering guidance, not legal advice.

Why ordinary logs fail the bar

The typical agent stack writes events to stdout, a JSON file, or an observability backend. All three share one property: whoever holds the storage can edit history, and nothing in the record reveals that they did. An auditor reviewing such a log has to trust the operator's word that it was not changed. That trust is exactly what a record-keeping regime is designed to remove.

The fix is to make every event integrity-protected and to chain events together so that altering, inserting, or deleting any one of them breaks a verifiable seal.

The shape of a log that holds up

SteelSpine captures each agent event, signs it with an HMAC-SHA256 tag, and links events into a hash chain whose final seal is signed with an Ed25519 key. Concretely:

1. Each event gets a content hash.
2. Each event's record includes the previous event's hash — so the events form a chain.
3. The chain's terminal hash is sealed with an Ed25519 signature.
4. Anyone with the public key can verify the whole chain offline, without access to your systems.

If a single byte of any event is changed, the content hash changes, the chain breaks, and verification fails. That is what "tamper-evident" means in practice: not "impossible to change," but "impossible to change silently."

Generating the logs

Capture a run, then emit the Article 12 audit artifact:

# Capture your agent run (wrap your existing command)
steelspine capture -- python my_agent.py

# Produce a signed, machine- and human-readable audit report
steelspine verify-run --compliance-html > article_12_audit.html

The resulting HTML report lists every recorded event, the chain integrity status, the signing key fingerprint, and a verification verdict. It is the object you hand to a compliance officer or attach to a regulator request. For portable evidence you can ship outside your environment, pack a run into a signed bundle:

steelspine pack-create <run-id> -o decision_0042.spine.tgz
steelspine pack-verify decision_0042.spine.tgz   # → VERIFIED ✓ or TAMPERED !

What this does and does not prove

Being precise here matters, because an auditor will ask:

Property	Status
Events are integrity-protected (HMAC-SHA256)	Yes
Events are chained and the chain is Ed25519-sealed	Yes
A third party can verify the chain offline, without trusting you	Yes
Quantum-resistant cryptography	No — the scheme is classical (HMAC-SHA256 + Ed25519)
Non-repudiation against the operator who holds the signing key	No — see below

The signing key is held by the operator. That means the chain proves no one altered the log after capture without the key, and it lets an independent party verify integrity — but it does not by itself prove the operator could not have produced a different log in the first place. Closing that gap is a key-custody problem (HSM, KMS, or third-party timestamping), not a logging-format problem. We say this plainly because a technical reviewer will find it anyway, and an honest claim is the only one worth making.

A reasonable checklist

• Wrap your agent's entrypoint so every run is captured automatically.
• Generate the signed audit report per run and retain it for your required period.
• Hand auditors the public key and the verify command so they confirm integrity themselves.
• Document your key-custody posture honestly — including its current limits.

This article is engineering guidance about generating audit logs, not legal advice. Whether your system is "high-risk," your exact obligations, and applicable deadlines depend on classification and the current consolidated EU AI Act text — confirm with qualified counsel.