EU AI Act evidence: where execution records fit.

Article 12, requirement by requirement

Article 12 of the EU AI Act requires high-risk AI systems to technically allow automatic recording of events ("logs") over the system lifetime, with logging capabilities that support traceability, post-market monitoring, and operation monitoring. For certain systems listed in Annex III point 1(a), it names minimum details the logs must carry.

An AER-1 receipt is one record type, not a full logging system. Below is what a receipt can contribute to each Article 12 element, stated narrowly.

Article 12(1): automatic recording over the system lifetime

A receipt is an automatic per-tool-call record: identifier, timestamp, tool, and output commitment, emitted when the execution boundary runs. Workflow receipts extend this to ordered multi-step jobs under one Merkle root. Receipts record invocations as they happen; they do not depend on anyone remembering to write a log entry later.

Article 12(2)(a): traceability to identify situations that may present risk

Receipts preserve the exact canonical bytes and the output commitment for each execution. Failure is a first-class outcome in AER-1: a malformed request, blocked permission, or unavailable provider still produces a receipt that marks the boundary. Failed and blocked executions stay in the record instead of being erased, which is what a risk review needs to find them.

Article 12(2)(b): facilitating post-market monitoring

Each receipt resolves to a stable public URL with an independent verification path. A reviewer can re-check a recorded execution after the fact, without access to the original system or database, by recomputing the commitment from the public bytes.

Article 12(2)(c): monitoring of operation

Whole-job timeline entries form an append-only hash chain with exactly one provenance class per entry, so a reviewer can see what ran, what was observed through a gateway, and what was only reported by another agent. A verified workflow root shows that the listed step commitments and their order agree with the workflow record.

Article 12(3)(a): period of each use

Each receipt carries a creation timestamp. A workflow's ordered entries let a reviewer reconstruct when a multi-step job started, what ran in sequence, and when it ended.

Article 12(3)(b) and (c): reference databases and matching input data

When a tool captures upstream data, evidence fields can identify the source, request parameters, capture time, byte length, and evidence hash. This is captured only when the implementation actually records it; a receipt never invents a source it did not see.

Article 12(3)(d): persons involved in verification of results

Receipts carry caller and session context when included, which can identify which scope or session produced the record. Receipts are machine records of tool calls, not identity records of natural persons; where the Act requires named human verifiers, that belongs in the deployer's own records, and a receipt can point at it without carrying it.

Retention and control

Article 26 keeps automatically generated logs under the deployer's control for an appropriate period. A public receipt page is durable and independently checkable, but it is one record type among the logs a deployer must keep. Plan retention across the full log set, not around receipts alone.

Protection

Receipts redact credentials, private prompts, and secret-bearing response bodies from public projections while keeping the commitment contract honest. System logs still need their own access controls and protection measures; a public receipt is the checkable projection, not the protected store.