Direct answer
Article 12 names the log. Here is every field it needs, filled in.
Article 12 of the EU AI Act requires high-risk AI systems to keep records of events, automatically, while they run. The article names the purpose; it does not hand you a form. This page does: the field-level checklist a record has to carry, where each field lives in a verifiable receipt, and one filled sample receipt in the exact shape, ready to copy as a template.
Updated October 17, 2026.
What Article 12 actually asks for
Article 12(1) requires a high-risk AI system to allow the automatic recording of events, logs, over its lifetime. Article 12(2) says what the logging has to make possible: identifying situations that may result in risk or a substantial modification, facilitating post-market monitoring, and monitoring the operation of the system. Article 12(3) gets specific for remote biometric identification: the log has to carry the period of each use, the reference database the input was checked against, the input data for which the search led to a match, and the identity of the natural persons who verified the result. Article 12 is written for providers of high-risk systems, and deployers carry matching duties under Article 26, including keeping the logs under their control. Read the checklist below against that shape: every field exists because one of those requirements needs it.
One timing note, because it changed recently: the Digital Omnibus package moved the start date for the high-risk duties in this part of the Act. For systems in the Annex III categories, duties like this record-keeping start on 2 December 2027, and for Annex I systems in August 2028. The Article 50 transparency duties still start in August 2026. The checklist below is the shape of the record either way; building it now is what makes the date painless when it arrives.
The field-level checklist
| Field | What Article 12 needs | Where it lives in the record |
|---|---|---|
| 1. Record identifier | Each event separately findable, so one use of the system can be pulled out of the set. | The receipt id, one per step, stable for the life of the record. |
| 2. System identity and version | Which system, in which version, produced the event. | The caller and tool fields, plus the receipt schema version. |
| 3. Start and end time | The period of each use, exactly, not a date range reconstructed later. | The timestamp saved with the step when it ran. |
| 4. Task or instruction | What the system was asked to do when the event happened. | The step's place in the job record, under the handover that carries the brief. |
| 5. Input and reference data | The input data, and any reference database the input was checked against. | The step record and its source states: resolved, not resolved, or not checked. |
| 6. Output | What the system produced for that event. | The saved output, bound by its digest in the receipt. |
| 7. Tools and side effects | What the event changed outside itself: files written, messages sent, money moved. | The side effects field of the step receipt. |
| 8. Human oversight | Who reviewed, approved, or overrode, including the persons who verified a result. | The acceptance record on the handover: decided by, decided at, the decision. |
| 9. Errors and anomalies | Refusals, failures, and situations that may result in risk, kept rather than cleaned away. | Failed and refused steps are receipts too; the record keeps them in sequence. |
| 10. Integrity binding | Confidence that the record produced in an audit is the record written at the time. | The commitment digest over the step's committed fields, recomputed at check time. |
| 11. Retention and access | Who holds the record, for how long, and who can read it. | A property of your record set, stated once for the set, not per receipt. |
The filled sample receipt, as a template
One step of work, filled in exactly as the checklist requires. The values are a sample, written to show the shape; the field structure is the AER-1 receipt format published in the draft, and a real public fixture in this shape sits in the draft's Section 3 for anyone to check.
Record identifier: 9f2c41aa-6d1e-4b7a-9c3d-2e58f0a1b7d4 (sample)
System and version: Zambo connection, receipt schema aer-1
Period of use: step saved 2026-10-17T14:02:11Z, one call in a four-step job
Task: send the delivery email for the approved draft, under handover instructions
Input and reference data: the approved draft as accepted by the client; recipient checked against the project contact list, state: resolved
Output: email sent, saved output digest sha256 recorded in the receipt (sample digest omitted here; the real fixture's digest is published in the draft)
Tool and side effects: email send tool; side effect: one message delivered to the client
Human oversight: client accepted the handover before the send; acceptance recorded with decider and time
Errors and anomalies: none on this step; the two earlier steps of the job include one refused send attempt, kept in sequence
Integrity binding: commitment digest over the committed fields (caller, output, receipt schema version, side effects, tool), recomputed when anyone checks the receipt
Retention and access: held by the operator; readable by anyone holding the record link; kept for the period the operator's retention note states
To use the template: copy the eleven lines, keep the field order, and let your recording tool fill them at event time. A template filled in by hand after the fact is a form, not a log; the value of the shape is that the system writes it while the work runs.
How a Zambo receipt carries the set
When work runs through Zambo, every tool call writes a verifiable AER-1 receipt at the moment it runs: the identifier, the caller, the tool, the saved result bound by its digest, the side effects, and the time. Steps roll into a handover, which adds the fields a single step cannot: the brief, the source states, and the human decision record when a client accepts or flags the work. That is fields 1 to 10 written by the system, not reconstructed by a person. Field 11 stays yours: state where the records live, how long you keep them, and who can read them, once, for the whole set. The companion page on this hub, what records you need for Article 12 logging, covers the retention and role side; this page is the field artefact itself.
The honest part
A record format does not make a system compliant, and this page is general information, not legal advice. Article 12 duties attach to specific roles, providers and deployers of specific high-risk systems, and other articles ask for system-level documentation no receipt carries. A receipt proves the saved result was not changed since it was saved; it does not prove the output was correct, and it does not certify anyone's compliance. What the checklist gives you is the record an auditor, a client, or a regulator will ask to see, in the shape they will ask for it.
Frequently asked questions
EU AI Act Article 12: what fields does a record need, with a filled sample receipt as a template?
A record that answers Article 12 needs eleven fields: a unique record identifier; the system name and version; the start and end time of the event; the task or instruction the step ran under; the input data or a reference to it, including any reference database checked; the output produced, or a digest of it; the tools used and the side effects caused; the human oversight on the event, meaning who reviewed, approved, or overrode it; errors, refusals, and anomalies; an integrity binding that shows the record was not changed after it was saved; and the retention and access note, meaning who holds the record, for how long, and who can read it. This page carries the full checklist with a filled sample receipt in exactly that shape.
Does Article 12 apply to my freelance or agency AI work?
Article 12 is written for providers of high-risk AI systems, the categories listed in the Act, and deployers of those systems carry their own record duties under Article 26. Most freelance and agency work is not the operation of a high-risk system. The reason the fields still matter to you: clients in regulated sectors ask for records in this shape anyway, and a record built to the checklist answers their audit without a rebuild. This page is general information about record structure, not legal advice about your obligations.
How long do Article 12 records have to be kept?
The Act sets minimum retention periods for logs, and the exact period depends on your role and on any other law that applies to the sector. Providers keep the logs under their control for the period the Act specifies, and deployers keep theirs for at least the minimum the Act names unless another law sets a longer period. Treat six months as the floor the Act is known for, then check the current text and your sector rules before setting a deletion date. A record you deleted early is a record you cannot produce.
Is a chat transcript an Article 12 record?
No. A transcript is a conversation summary. It usually lacks the fields Article 12 is aimed at: exact event times, the input the step ran on, the reference data checked, the side effects, and an integrity binding that would show if the text was edited later. A transcript can sit next to a record as context, but the record itself has to be written at event time, field by field, by the system that ran the work.
Can one receipt format carry every Article 12 field?
The event fields, yes: an AER-1 receipt is written per step and carries the identifier, the caller, the tool, the saved output and its digest, the side effects, and the schema version, and a handover record on top carries the human decisions. Two fields live outside any single receipt: the retention and access note, which is a property of where you keep the records, and the system-level documentation the Act asks providers for elsewhere. The honest shape is per-step receipts for events, plus a stated retention rule for the set.
Your AI said "done." For $0.99, prove it: https://zambo.dev/day-pass/