What Article 12 actually requires (the logging limb, in plain language)
Article 12 is titled Record-keeping. Strip the legalese and it makes one core demand of high-risk AI systems:
- Automatic recording of events. The system must technically allow events to be recorded automatically while it is operating. Not manual exports. Not after-the-fact reconstructions. Automatic, as it runs.
- Traceability appropriate to the purpose. The logging must give a level of traceability of how the system functioned throughout its lifecycle that fits what the system is used for.
- Events that let someone reconstruct what happened. The text points at the period of each use, the reference data consulted, the input data that led to a result, and the persons involved in checking results.
The implicit fourth requirement is the one auditors actually test: the records must survive distrust. A log that the audited party can silently rewrite is not evidence. It is testimony. Article 12's record-keeping is only useful to an auditor if the auditor can verify the records without trusting the operator who produced them.
What "tamper-evident" means, technically
Tamper-evident does not mean tamper-proof. It means tampering leaves a detectable mark. Here is the mechanism, in three layers:
- Hash commitment per record. At execution time, the exact bytes of the record are reduced to a canonical form and hashed with SHA-256. The hash is stored as the record's commitment. Anyone can later recompute the hash from the bytes and compare. Change one byte and the hashes no longer match. Verification is mechanical: fetch, parse, compare.
- Hash chaining across steps. Each receipt references the hash of the previous step. Removing or altering a step in the middle breaks the chain at exactly that point, which makes deletions and reorderings visible, not just edits.
- A Merkle root sealing the run. All steps roll up into one root hash. Hand an auditor the root and the step receipts, and they can confirm the whole run is exactly what the root committed to, without re-running anything.
None of this requires trusting the party that minted the records. The verifier needs only the bytes, the hash function, and the open procedure. The public verifier at zambo.dev/verify performs this check with no account and no signup.
How AER-1 receipts map to each Article 12 requirement
AER-1 is the open IETF Internet-Draft for verifiable execution receipts (draft-zambo-aer1, authored by Brennan Zambo). Each receipt records one tool execution: what ran, what went in, what came out, and when, bound by the hash commitment described above.
| Article 12 requirement | How the receipt answers it |
|---|---|
| Automatic recording of events | Receipts are captured at execution, one per tool call, with no manual step. Framework collectors hook into the agent run so recording is the default, not a chore. |
| Period of use | Each receipt carries a timestamp; the hash chain orders the full sequence of a run from first to last step. |
| Reference and input data | The canonical bytes preserve exactly what went in and what came back. The hash commits to those bytes, so the inputs behind any result are checkable. |
| Traceability throughout the lifecycle | The chained sequence plus the Merkle root give a complete, ordered, sealed trail of everything the agent did. |
| Verification without trusting the operator | Any third party recomputes the hashes from the bytes. The format is an open draft, so evidence never depends on one vendor's dashboard or survival. |
The mapping is direct because Article 12's record-keeping limb is fundamentally an integrity requirement, and receipts are an integrity mechanism. The Act asks for records an auditor can rely on; receipts are records an auditor can re-verify.
What receipts do NOT cover: the honest limits
The scope, stated plainly
A verifiable receipt proves the saved result was not changed. It does not prove the model was right, the decision was fair, the data was lawful, or the risk management was adequate. Saying otherwise would be the exact kind of overclaiming this page argues against.
- Not the full Act. Receipts address the logging and record-keeping limb. They do not replace the risk management system, the data governance duties, human oversight, accuracy and robustness obligations, or any other high-risk requirement.
- Not correctness. A receipt locks in exactly what the agent produced. Whether that output was correct, appropriate, or lawful is a separate judgment on top of the evidence.
- Not legal advice. This page explains the technical mapping. Whether your system is high-risk, which obligations apply to your deployment, and how your auditor will assess them are questions for your counsel.
- Not a certification. AER-1 is an open draft, not a conformity stamp. It gives auditors a public, checkable procedure; it does not declare anyone compliant.
The honest pitch to a compliance officer: receipts are the strongest available answer to the specific question Article 12's record-keeping asks, which is whether the trail can be trusted. Everything above that question still needs your governance program.
The implementation path
No new infrastructure. The collector packages emit receipts from your existing agent framework:
pip install aer1kit # the core kit pip install aer1-smolagents # smolagents pip install aer1-crewai # CrewAI pip install aer1-langgraph # LangGraph
With the core kit, emitting receipts is a few lines:
from aer1kit import ReceiptEmitter
emitter = ReceiptEmitter(goal="the workflow under review")
# after every action your agent takes:
emitter.record("web_search", {"query": "...", "results": [...]})
emitter.record("send_email", {"to": "...", "subject": "..."})
# at the end of the run:
url = emitter.mint() # sealed, hash-chained receipt setBefore you show anyone, verify a receipt yourself: zambo.dev/verify takes a receipt and reports whether the bytes match the commitment, with no signup. Then hold one in your hands with zero setup: the 30-second live demo issues a real receipt from a free anonymous call, and you can tamper with it and watch verification fail.
One afternoon of integration gives you the logging layer, the verification procedure, and the answer to the only question that matters to an auditor: can someone check this without our help? When the answer is yes, the Article 12 logging limb is the strongest part of your packet.
Questions, answered
What records do I need for EU AI Act Article 12 logging?
Article 12 requires high-risk AI systems to record events automatically over the system's lifetime, at a level of traceability appropriate to its intended purpose. The record set that answers it is: the period of each use, what the system was given and what it returned, the reference data it checked, and the natural persons involved in verifying the results, produced automatically and kept so the trail can be examined later. A log the operator can quietly edit is weak evidence for that set, because the auditor's whole question is whether the trail survived the operator. Verifiable execution receipts produce exactly this record set: one receipt per tool call, captured at execution, carrying the inputs, the output, and the timestamp, bound by a hash commitment a third party can recompute without trusting you. That covers the record-keeping limb of Article 12. It is not, on its own, compliance with the Act.
Do verifiable execution receipts satisfy EU AI Act Article 12?
Verifiable execution receipts address the core of Article 12: the automatic, tamper-evident recording of events. They do not equal full Article 12 compliance on their own, because Article 12 sits inside a wider set of record-keeping, data governance, and risk management duties. Receipts give you the tamper-evident logging layer that an auditor can verify without trusting the operator.
What does EU AI Act Article 12 actually require for logging?
Article 12, titled Record-keeping, requires high-risk AI systems to technically allow the automatic recording of events, called logs, while the system is operating. The logging must ensure a level of traceability of the system's functioning throughout its lifecycle that is appropriate to its intended purpose. The text points to events such as the period of each use, the reference data used, the input data that led to a match, and the persons involved in verifying results.
What makes an AI log tamper-evident for an auditor?
A log is tamper-evident when any change to a past record is detectable by someone who does not trust the operator. In AER-1 receipts this comes from a SHA-256 hash commitment computed over the canonical bytes of the record: change one byte and the recomputed hash no longer matches the commitment. Hash-chained steps and a Merkle root over the run make deletions and reorderings visible too.
What do verifiable receipts not cover under the EU AI Act?
Receipts prove the record was not changed; they do not prove the model was right, the decision was fair, or the risk management was adequate. They do not replace the risk management system, data governance duties, human oversight, or the rest of the Act's high-risk requirements. They cover the integrity of the logging layer, which is exactly what Article 12's record-keeping limb is about.
How quickly can a team start generating tamper-evident logs with AER-1?
Framework collector packages emit receipts with no new infrastructure: pip install aer1kit or a framework collector such as aer1-smolagents, aer1-crewai, or aer1-langgraph. Receipts are captured automatically at execution and can be verified by a third party through the public verifier at zambo.dev/verify with no account.