EU AI Act Article 12: Agent Logging Compliance
What Article 12 asks high-risk AI systems to record, how retention fits, and where execution receipts can help.
Automatic event recording for applicable high-risk systems
Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime. The logging capability should support traceability appropriate to the system's intended purpose and capture events relevant to risk identification, post-market monitoring, and deployer monitoring.
Identify risks
Record events that can help identify situations that may create a risk or indicate a substantial modification.
Support monitoring
Make records useful for post-market monitoring and for monitoring the system's operation.
Cover special cases
Article 12(3) adds minimum event details for the high-risk remote biometric identification systems described in Annex III, point 1(a).
Article 12 is not a blanket logging rule for every AI product. Determine whether the system is high-risk, your role, the intended purpose, and which events must be traceable.
Read the official text of Regulation (EU) 2024/1689, including Articles 12, 19, and 26.
A useful log is traceable, reviewable, and scoped
Article 12 sets an outcome for logging capability, not a universal receipt schema. A practical implementation defines event coverage from the system's purpose and risk, records events automatically, keeps timestamps and context, and makes records accessible to the people responsible for monitoring and review.
- Define the relevant system events and the reason each must be recorded.
- For agent tool calls in scope, record the tool, input and output data or commitments, result, and execution context.
- Use an explicit timestamp format such as RFC 3339 for each recorded event.
- Keep records machine-readable and test that reviewers can parse them independently.
- Protect personal and confidential data through minimization, access controls, and a documented retention policy.
- Use repeatable integrity checks such as SHA-256 verification, while keeping log completeness as a separate control.
- Test that logging works during normal operation, errors, retries, and interrupted workflows.
Use receipts as one layer of the event record
AER-1 can provide a portable, verifiable record for an AI agent tool call: what execution was recorded, when it happened, the tool and caller scope, and the committed output bytes. Its timestamp field uses RFC 3339, and its output commitment uses SHA-256. That can support traceability for agent execution events when the implementation captures the events the system actually needs to monitor.
A receipt format does not decide whether a system is high-risk, define complete event coverage, enable automatic logging across the whole system, satisfy retention duties, or prove that personal data is handled lawfully. A hash can help detect changes to committed bytes; it does not prove the event was complete or truthful. Those obligations depend on the system, role, deployment, and applicable law.
AER-1 revision -02 is an individual Internet-Draft authored by Brennan Zambo. It is a proposed execution-receipt format, not a legal certification or a formally adopted standard. Review the AER-1 Internet-Draft revision -02, the conformance kit, and the guide to execution and decision receipts.
Retention is a separate part of the design
Articles 19 and 26(6) address log retention for providers and deployers. In general, they require automatically generated logs under the relevant party's control to be kept for an appropriate period, at least six months, unless applicable Union or national law provides otherwise. Personal data and other record types may have additional rules.
Set retention, access, deletion, and audit procedures with the system's role and legal basis in view. A verifiable hash does not justify keeping unnecessary personal data or publishing private log contents.
Check the whole logging path
| Check | Evidence to keep |
|---|---|
| Scope and responsibility | System classification, intended purpose, provider or deployer role, and the events in scope. |
| Automatic capture | Tests showing relevant events are recorded during normal, failed, and interrupted operation. |
| Agent execution coverage | Every agent tool call defined as in scope produces an execution receipt, with failure and retry events handled consistently. |
| Time and context | RFC 3339 timestamp, system identity, event type, and enough context for a reviewer to interpret each record. |
| Integrity and access | Repeatable SHA-256 verification, access controls, data minimization, and a documented retention schedule. |
| Independent review | An auditor can independently verify receipt bytes, output commitments, and any linked upstream evidence using documented steps. |
Use the AER-1 conformance kit to test the execution-receipt layer. For the distinction between action evidence and authorization evidence, see Execution Receipts vs Decision Receipts.
Frequently asked questions
Does Article 12 apply to every AI system?
No. Article 12 addresses high-risk AI systems under the Regulation. Scope depends on the system and its use.
Do execution receipts alone make a system compliant?
No. They can support records for agent tool calls, but they do not by themselves establish system classification, complete event coverage, automatic logging, retention, access, or other legal duties.
How long must logs be retained?
Articles 19 and 26(6) generally specify an appropriate period of at least six months for logs under the relevant party's control, subject to other applicable Union or national law. Confirm the requirements for your role and system.