If you are building logging for an AI system that falls under the EU AI Act, you will be told to wait for the standard. This post sets out what the law asks for today, what the two logging standards in progress are expected to settle, and what they leave open. Every point links to its source.
What the law asks for
Article 12 requires high-risk AI systems to "technically allow for the automatic recording of events (logs)" over their lifetime. It names the purposes the logs must serve: identifying situations that may present a risk or a substantial modification, post-market monitoring, and the deployer's monitoring of the system's operation. It names concrete fields for one case only, remote biometric identification, in Article 12(3). Article 19 and Article 26(6) require providers and deployers to keep the logs under their control for at least six months, unless other law, in particular data protection law, says otherwise.
For Annex III high-risk systems these duties apply from 2 December 2027, after Regulation (EU) 2026/1744 moved the date. So the law tells you why to log and how long to keep it. For almost every system it does not tell you which fields to write.
What the standards are expected to settle
Two documents are meant to fill that gap.
- ISO/IEC 24970, "AI system logging". ISO's own page lists it at the final draft stage, with the final ballot opened on 28 August 2026 for eight weeks. Its public abstract describes "common capabilities, requirements and a supporting information model for logging of events in AI systems". The final text is not public, so whether that information model becomes a fixed list of fields is not something anyone outside the committee can tell you yet. ISO/IEC 24970 on iso.org.
- prEN 18229-1, "AI trustworthiness framework, Part 1: Logging". A draft European standard from CEN-CENELEC JTC 21, the committee writing the standards meant to support the AI Act. It is sold as a draft; its text is not public either. The draft as listed by DIN Media.
One legal point matters more than any date. Following a standard gives a presumption of conformity with the AI Act only once it is a harmonised standard cited in the Official Journal (Article 40). A draft gives you a direction, not that presumption.
What is public today: AESIA Guía 12
The Spanish AI supervisory agency, AESIA, has published a full guide on records and automatically generated logs: Guía 12, "Registros y archivos de registro generados automáticamente", version 2.0 of 17 July 2026, adapted to the Digital Omnibus. It is free to read and published under a Creative Commons Attribution 4.0 licence, so anyone can build on it.
Section 4.2 lists nineteen attributes a record of an AI system can commonly contain, labelled a to s. In short: a unique record ID; who or what logged the event; a description, structure and purpose of the record; the actions on it and the date and time of each; the model or algorithm with its version and configuration; the identity, source and type of the input data; the results, quality metrics and performance; security and privacy information; alerts; links to other records; what the record needs to serve as evidence; and what is needed to retrieve it. The guide is explicit that its examples are to be read "como un ejemplo y no como una obligación": as an example, not as an obligation.
What none of them asks for
Read the law, the two public abstracts and AESIA's list side by side, and one field is missing from all of them: which rule decided, and which provision of law that rule applies. AESIA comes closest in one worked example, an AI system for staff promotion, where the record would include the action taken "y la justificación de dichas decisiones", the justification for those decisions. It is an example, not a field.
That gap matters as soon as someone asks why a decision was taken. We set out the explanation duties that make it matter in a separate post.
What to do now
- Design the record from the purposes the law already names (Article 12(2)) and the retention it already sets (Articles 19 and 26(6)), not from a field list you are waiting for.
- Use AESIA's list as the checklist it offers to be. It is public, current and reusable.
- Record the rule and the legal provision for every decision, even though no standard asks for it yet.
- Keep the content out of the log: a keyed hash of the text and a pseudonym for the person show which text and which person a decision was about, without creating a second store of personal data.
- When ISO/IEC 24970 is published, map your fields to it. A record built from the law's purposes should map cleanly.
This is the reasoning behind ADCR, the open Rulebook for AI decision records (version 0.1.0, in development): a field list anyone can use, with the rule and the law on every decision, mapped to the AI Act, to AESIA's list, and to the standards as their text becomes public. The mapping names these standards as targets; none of their authors has reviewed or endorsed it.