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.
What Article 12 does NOT require
Article 12 does not, by itself, require every AI product to publish every prompt, expose private provider payloads, use AER-1, or adopt one universal receipt schema. It does not turn a hash into proof that an event was complete, accurate, authorized, or successful in the outside world. It also does not remove the need to determine whether the system is high-risk, which role has the relevant duty, what events are appropriate to the intended purpose, or how personal data should be handled.
This page is an implementation aid, not a legal conclusion. Read the official EUR-Lex text and obtain advice suited to the system and deployment. A receipt can make one recorded event easier to inspect while leaving system classification, logging completeness, retention, access control, and governance questions open.
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.
An Article 12 evidence pack can include receipts
An Article 12 evidence pack is a practical bundle for review, not a legal artifact defined by the Regulation. For an agent workflow, it can include the system scope and responsible role, an event inventory, automatic-capture tests, selected AER-1 receipts, verifier results, retention and access controls, redaction rules, and links to any real upstream read-back or monitoring evidence.
| Pack item | What an AER-1 receipt may support | What remains separate |
|---|---|---|
| Execution identity | id, created_at, tool metadata, provenance, and public URL help a reviewer locate one recorded call. | Whether that call is part of complete, purpose-appropriate system logging. |
| Integrity check | canonical_bytes and output_hash let a verifier compare the committed representation. | Truth, completeness, authorization, and the legal significance of the recorded event. |
| Observed result | The receipt can preserve the implementation's stored result and status, including failure or unavailable states. | An external outcome unless the relevant system supplied a separate confirmation or read-back. |
| Review handoff | A public receipt and the AER-1 conformance suite can make repeatable checks easier. | Retention, access, privacy, incident response, and other controls required by the deployment. |
AER-1 is an open individual Internet-Draft authored by Brennan Zambo, not a finalized draft spec and not a certification scheme. Review the AER-1 draft, the IETF Datatracker draft -02, and the technical Article 12 field-mapping appendix. These materials can support a structured review, but they do not establish compliance on their own.
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 draft spec. 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.