Article 12 does not tell you how long to keep logs. It tells you that the system must be built so that logs exist at all, and it defines what they have to be good enough to support.
A capability obligation, not a retention rule
Article 12(1) of Regulation (EU) 2024/1689 requires that high-risk AI systems technically allow for the automatic recording of events — logs — over the lifetime of the system.
Every word of that is about the artefact rather than the operator. “Technically allow” is a property of the software. “Automatic” excludes a manual record. “Over the lifetime of the system” means the capability persists, not that any particular log does. The provider discharges Article 12 by shipping a system that logs; whether logs are then retained is answered by Article 19 for providers and Article 26(6) for deployers.
That split has a practical consequence. A provider cannot satisfy Article 12 by telling deployers to enable logging themselves, and cannot satisfy it by logging in a hosted deployment while shipping an on-premises build that does not. The capability travels with the system.
Not legal advice. Logging obligations under the AI Act sit alongside, and can conflict with, GDPR storage limitation and data minimisation — a log that records input data is very often personal data processing that needs its own lawful basis and retention justification. Resolve that with advice on your facts rather than by defaulting to logging everything.
The three purposes logs must serve
Article 12(2) sets the standard by reference to what the logs have to be capable of. Logging capabilities shall enable the recording of events relevant for three things, in order to ensure a level of traceability appropriate to the system’s intended purpose:
- Identifying situations that may result in the system presenting a risk within the meaning of Article 79(1), or in a substantial modification. Article 79(1) is the market surveillance trigger for a system presenting a risk to health, safety or fundamental rights. So the logs must be good enough to spot the onset of that condition — which is a functional test, not a field list.
- Facilitating the post-market monitoring referred to in Article 72. The monitoring plan and the logging design are therefore the same design problem: a plan that requires data the logs do not carry is not implementable.
- Monitoring the operation of high-risk systems as referred to in Article 26(5). That is the deployer’s duty to monitor operation in accordance with the instructions for use and to inform the provider where they have reason to consider that use may present a risk. The provider’s logs have to make the deployer’s obligation performable.
The third purpose is the one that most often changes a design. It means the logging is not only for the provider’s own diagnostics: it has to be accessible and interpretable by the deployer. Article 13(3)(f) reinforces this by requiring the instructions for use to describe, where relevant, the mechanisms included in the system that allow deployers to properly collect, store and interpret the logs in accordance with Article 12.
The four mandatory fields for biometric ID
Article 12(3) is the only place in the article with a concrete field list, and it applies to one category: high-risk systems referred to in point 1(a) of Annex III, meaning remote biometric identification systems. For those, the logging capabilities shall provide at a minimum:
- Recording of the period of each use — start date and time and end date and time of each use.
- The reference database against which input data has been checked by the system.
- The input data for which the search has led to a match. Note the limitation: input data for matches, not for every query. That is a deliberate minimisation, and a system logging every probe image goes beyond what Article 12(3) requires and needs its own justification under the GDPR.
- The identification of the natural persons involved in the verification of the results, as referred to in Article 14(5). Article 14(5) is the two-person rule for the Annex III point 1(a) systems: no action or decision is taken 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 an exception for certain law enforcement, migration, border control and asylum uses where Union or national law considers the requirement disproportionate.
Read (d) together with Article 14(5) and the logging requirement has a purpose beyond audit: it is the evidence that the two-person verification actually happened. A log without named verifiers cannot demonstrate compliance with the oversight rule it exists to record.
Retention: Article 19, not Article 18
This misattribution is common enough to be worth stating plainly. Three separate retention rules exist and they are frequently swapped.
- Article 19 — providers keep the logs automatically generated by their high-risk systems, to the extent such logs are under their control, for a period appropriate to the intended purpose, of at least six months, unless provided otherwise in applicable Union or national law, in particular data protection law.
- Article 26(6) — deployers keep the logs automatically generated by a high-risk system, to the extent under their control, for a period appropriate to the intended purpose, of at least six months, unless provided otherwise.
- Article 18 — providers keep the technical documentation, quality management system documentation, notified body decisions and the EU declaration of conformity for ten years after placing on the market or putting into service. This is the documentation rule, not the logging rule.
The phrase “to the extent such logs are under their control” appears in both Article 19 and Article 26(6) and does real work in a hosted architecture: a provider who never receives the deployer’s logs does not hold them, and a deployer running a vendor-hosted system may not either. Neither party is relieved of the duty in respect of what they do control, and the contract is where the gap between the two gets allocated. For the retention analysis in detail see the log retention period, and for the contents question see what high-risk logs must contain.
What this means for how you build
Article 12 is thin on prescription for everything except biometric identification, which means the design has to be derived from the three purposes rather than copied from a field list. Three derivations hold for most systems.
First, a log that records only the output is insufficient for purpose (a), because identifying the onset of a risk condition generally requires knowing what the system was given and under what configuration. Second, a log without a stable identifier for the model or system version cannot support post-market monitoring under purpose (b), because a change in behaviour cannot be attributed to a change in the system. Third, a log the deployer cannot read does not serve purpose (c) at all.
The version-attribution point is the one that catches teams whose high-risk system calls a hosted model. If the vendor moves an alias to a new checkpoint, a log recording only the alias cannot distinguish a drift in your data from a change in the model — which is precisely the discrimination Article 12(2)(b) exists to enable. Recording the resolved model version, the provider and the routing decision on every call is what makes that log answer the question. A gateway sits in the right place to capture it; Multigrid records those fields per request, and any equivalent logging layer would serve as well.
Finally, note the interaction with GDPR storage limitation. Article 19 sets a floor of six months and expressly defers to data protection law where that law provides otherwise. A log containing personal data is not exempt from Article 5(1)(e) GDPR because the AI Act asked for it; the two have to be reconciled, usually by minimising what the log contains rather than by shortening how long it is kept.
Top comments (0)