What a High-Risk AI System's Automatic Log Must Capture

There is exactly one place in the AI Act where the contents of a log are enumerated field by field, and it applies to a single category of system. Everywhere else, Article 12 states a purpose and leaves you to derive the schema. Both halves are implementable; they are not implementable the same way.

Two layers, and only one is a field list

Article 12(1) of Regulation (EU) 2024/1689 requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. Article 12(2) then says what the logging capability has to be good enough to do, in terms of traceability appropriate to the intended purpose. It names three ends: identifying situations that may result in the system presenting a risk within the meaning of Article 79(1) or in a substantial modification; facilitating the post-market monitoring under Article 72; and monitoring the operation of the system as required of deployers by Article 26(5).

Article 12(3) is different in kind. For high-risk systems falling under point 1(a) of Annex III — remote biometric identification systems — it states a minimum set of things the logging capability shall provide. That is a specification. It is the only one in the article.

If you are building a CV-screening system, a credit-scoring system or any of the other Annex III categories, Article 12(3) does not apply to you and copying its four fields will not discharge your obligation. If you are building a biometric identification system, Article 12(3) is a floor rather than a ceiling — the 12(2) purpose test still applies on top.

The four fields Article 12(3) enumerates

As a build spec, in the order the Regulation gives them:

• The period of each use. The text is explicit that this means the start date and time and the end date and time of each use — not a single event timestamp. A log line per query is not what is being asked for; a session with two bounds is. Systems built around request-level telemetry usually have to add a session concept to satisfy this, and that is a schema change rather than a configuration one.
• The reference database against which input data has been checked. An identifier for the gallery the search ran against. In a deployment where the reference set changes — watchlists are added, revoked, re-imported — a bare name is not enough to reconstruct what was searched six months later. A version or snapshot identifier is what makes this field answer the question it exists to answer.
• The input data for which the search has led to a match. Note the scope: the input data for matches, not every probe image ever submitted. That is a deliberately narrower obligation than “log the inputs”, and the narrowing matters, because the input here is biometric data and therefore a special category under Article 9 of the GDPR. Logging every probe because Article 12 was read loosely creates a store of special category data that you then have to justify.
• The identification of the natural persons involved in verifying the results, as referred to in Article 14(5).

The Article 14(5) field nobody expects

The fourth field is the one that surprises people, because it is not about the system at all. Article 14(5) is the human oversight provision that, for the remote biometric identification systems in Annex III point 1(a), requires that no action or decision be taken by the deployer on the basis of the identification unless it has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority — with a carve-out for certain law enforcement, migration, border control and asylum uses where Union or national law considers that requirement disproportionate.

Article 12(3)(d) then requires the log to record who those people were. The consequence for a build is concrete: the verification step has to be inside the system, or at least reported back into it, because a two-person confirmation that happens in an operator’s separate case management tool cannot be written into the AI system’s log. This is the single field most likely to be missed by a team that treats logging as an infrastructure concern rather than a product one. The human oversight requirement and the logging requirement are drafted to reference each other, and they have to be implemented together.

What the other high-risk systems get

For every other high-risk system, the contents question is answered by working backwards from Article 12(2). Each of its three limbs implies fields:

• Identifying a risk situation or a substantial modification. Article 79(1) concerns systems presenting a risk to health, safety or fundamental rights. To identify such a situation from logs you need the inputs or a faithful characterisation of them, the output, and enough about the running configuration — model version, thresholds, ruleset version — to know which system produced it. Version identity is the field teams most often omit and most often need, because without it a log cannot distinguish a bad output from a changed system.
• Facilitating post-market monitoring under Article 72.Post-market monitoring is statistical: it asks how the system performs in the field over time. That implies logs that can be aggregated — consistent event types, consistent outcome encodings, and a way to join a decision to whatever downstream outcome later becomes known.
• Monitoring by the deployer under Article 26(5). The deployer monitors operation on the basis of the instructions for use. That makes the log partly an interface obligation: whatever you tell deployers to watch for in the Article 13 instructions has to be visible in something the deployer can see.

The last point is the one that changes an architecture. If the instructions for use tell a deployer to monitor for a drift in accepted rates across a protected characteristic, and the log does not carry the fields that would let anyone compute it, the two documents contradict each other — and the instructions are themselves a regulated deliverable.

Where the missing detail is supposed to come from

The Regulation does not fill this gap by itself, and it is honest to say so. The intended mechanism is harmonised standards: CEN-CENELEC JTC 21 is developing standards in support of the AI Act, and conformity with a harmonised standard whose reference is published in the Official Journal gives a presumption of conformity with the corresponding requirement under Article 40. Until the relevant references are published, there is no authoritative field list for non-biometric high-risk systems, and anyone who tells you there is has invented it.

The practical answer in the interim is to make the derivation explicit. Record, in the technical documentation under Article 11 and Annex IV, which log fields exist and which limb of Article 12(2) each serves. A documented derivation from the statutory purpose is defensible even if a later standard names different fields; an undocumented schema is not defensible either way. Progress on the standards side is tracked in the JTC 21 work programme.

A build spec that survives either reading

Four properties tend to hold up regardless of how the standards land. Log an immutable event per decision with a stable identifier, so that a later record can reference it. Carry version identity for every component that can change the output — model, prompt, threshold, reference data — because Article 12(2)(a) explicitly contemplates detecting a substantial modification, and you cannot detect a change you did not record. Keep the payload minimal and typed rather than a free-text blob, since the log inherits the sensitivity of whatever you put in it. And separate the log from the application database, because the retention rule that applies to it is not the retention rule that applies to your product data — the six-month floor and its exceptions are a different obligation with different arithmetic.

One timing note. Chapter III, where Article 12 sits, applies from 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for Annex I product-embedded ones, following the amendments made by Regulation (EU) 2026/1744 in July 2026. That is later than the original text provided, and it is enough time to build this properly; it is not enough time to retrofit a session concept and a version identifier into a system that never had them.