What Art. 12 Specifically Requires
Art. 12(1) AI Act requires that the technology of a high-risk AI system enable the automatic recording of events over the duration of its lifetime — not merely during testing, but continuously throughout live operation. This is not an organisational requirement but a technical one aimed at the system itself: logging capability must be built into the architecture, not bolted on afterwards as a feature.
Art. 12(2) sets out the purpose more precisely: logging must capture events relevant to
- identifying situations that may result in a risk within the meaning of Art. 79(1), or in a substantial modification,
- the post-market monitoring referred to in Art. 72,
- the monitoring of operation referred to in Art. 26(5).
Logging is therefore not an end in itself but the technical backbone for three other obligations: risk detection, post-market monitoring, and ongoing oversight by deployers. Anyone lacking the logs cannot, in practice, fulfil these obligations — the evidence simply isn’t there.
Stricter Requirements for Biometric Systems
For high-risk AI systems under Annex III point 1(a) — covering biometric identification systems — Art. 12(3) goes beyond the general obligation and specifies a minimum scope:
- recording of the period of each use (start date and time, end date and time),
- the reference database against which input data has been checked,
- the input data for which the search has led to a match,
- the identification of the natural persons involved in the verification of results as referred to in Art. 14(5).
This list sets out minimum content, not an exhaustive ceiling. Anyone deploying or providing such a system must therefore be able to show who ran which query when, with what result, and which natural person carried out the human verification. Without structured logging, this is practically impossible to reconstruct.
Why This Often Gets Tackled in the Wrong Place
A typical pattern: existing logging infrastructure is built for operational stability — errors, exceptions, performance metrics. What’s missing is the link to the purposes named in Art. 12(2). Three gaps keep recurring:
Lack of traceability for individual decisions. Logs show that the system ran, but not which input data led to which output. That’s insufficient for post-market monitoring under Art. 72 and operational monitoring under Art. 26(5).
Retention periods that are too short. If logs are rotated out after a few days, a later risk analysis following a reported incident becomes impossible, because the relevant events have already been overwritten.
No link to human oversight. Particularly for systems requiring verification by natural persons, the technical link between the system’s output and the person who checked it is often missing — precisely what Art. 12(3)(d) explicitly requires for biometric systems.
These gaps rarely surface during development; they emerge only when an authority or a deployer demands concrete evidence as part of market surveillance. Retrofitting is then considerably more expensive than building it in from the start.
What Providers and Deployers Should Check Now
For providers, this means logging functionality must be part of the technical specification, not a downstream IT matter. For deployers relying on a provider’s logs, it’s worth reviewing the contracts — does the logging actually serve the purpose set out in Art. 12(2), or does the provider only supply generic system monitoring?
The high-risk obligations under Annex III become binding from 2 August 2026. Anyone deploying or providing an affected system should have reviewed the logging architecture beforehand — not wait until a supervisory authority asks about it.
To find out quickly whether your system falls under Annex III at all, and which obligations actually apply, use our free risk assessment at /einstufung.