EU AI Act Article 12: Record-Keeping and Automatic Logging Obligations

What Article 12 Covers

Article 12 of Regulation (EU) 2024/1689 addresses traceability. A high-risk AI system must be designed and developed so that it technically allows for the automatic recording of events, commonly called logs, over its lifetime. This is a product design requirement aimed at providers: the capability must be built into the system itself, not bolted on by the deployer afterwards.

The rationale is straightforward. When an AI system contributes to a harmful or contested outcome, regulators, deployers and affected persons need a factual record of what the system did and under what conditions. Without automatic logging, post-incident analysis collapses into reconstruction from memory, and obligations such as serious incident reporting under Article 73 and the right to explanation under Article 86 become difficult to honour in practice.

What the Logging Capability Must Enable

Article 12(2) defines the purposes the logging capability must serve. Logging must enable the recording of events relevant for:

• Identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1), that is, a risk to health, safety or fundamental rights, or in a substantial modification of the system.
• Facilitating the post-market monitoring referred to in Article 72.
• Monitoring the operation of high-risk AI systems by deployers in accordance with Article 26(5).

The regulation deliberately ties log design to these functions rather than prescribing a universal log schema. The provider must therefore work backwards: identify what evidence would be needed to detect emerging risks, feed post-market monitoring and support deployer oversight for this particular system, and ensure those events are captured. The level of logging should be appropriate to the intended purpose of the system.

Special Requirements for Remote Biometric Identification

Article 12(3) sets out minimum mandatory log content for high-risk AI systems referred to in point 1(a) of Annex III, namely remote biometric identification systems. For these systems, the logging capabilities must provide at least:

• Recording of the period of each use of the system, including the start date and time and the 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.
• The identification of the natural persons involved in the verification of the results, as referred to in Article 14(5).

This reflects the heightened fundamental-rights sensitivity of biometric identification and creates an audit trail for each use of the system and each human verification step.

Who Keeps the Logs, and for How Long

Article 12 itself concerns the technical capability. Retention duties appear elsewhere. Under Article 19, providers must keep the logs automatically generated by their high-risk AI systems, to the extent the logs are under their control, for a period appropriate to the intended purpose and at least six months, unless Union or national law, including data protection law, provides otherwise. Under Article 26(6), deployers must keep logs under their control for a similarly defined period of at least six months. Providers should design retention, access controls and deletion in coordination with GDPR obligations, since logs frequently contain personal data.

How to Implement Article 12 in Practice

1. Derive a logging specification from the three Article 12(2) purposes. List concrete events: inputs received or their identifiers, model version used, confidence scores, threshold breaches, fallback activations, human overrides, errors and anomalous conditions.
2. Make logging automatic and tamper-resistant. The requirement is automatic recording; manual notes do not satisfy it. Apply integrity controls so logs are usable as evidence.
3. Synchronise timestamps and include system and model version identifiers in every record, so events can be tied to a specific system state.
4. Design for the deployer. Article 26(5) expects deployers to monitor operation using, among other things, these logs, and Article 13 requires the instructions for use to describe the mechanisms that allow deployers to collect, store and interpret the logs.
5. Plan retention and access: at least six months, with GDPR-aligned minimisation, role-based access and a procedure for handing logs to market surveillance authorities on request.
6. Test the logging path before release, including under failure conditions, since logs that disappear exactly when the system misbehaves defeat the purpose of the article.

A Concrete Example

A provider of an AI system that filters job applications would log, for each scoring run, the model version, the time of processing, the score and decision band produced, whether a human reviewer confirmed or overrode the output, and any error states. If the provider's post-market monitoring under Article 72 later detects a drift in score distributions for a particular group, the logs make it possible to establish when the drift began and which model version introduced it, and whether the situation amounts to a risk that triggers corrective action under Article 20.

How Article 12 Connects to Other Provisions

Article 12 is the evidentiary backbone of several other obligations. Article 9 risk management relies on logged events to validate that risk controls work in the field. Article 14 human oversight produces verification events that biometric systems must record. Article 17 requires the quality management system to include procedures for record-keeping. Articles 19 and 26(6) govern retention by providers and deployers respectively. Article 72 post-market monitoring consumes log data, Article 73 serious incident reports are reconstructed from it, and Article 21 requires providers to give competent authorities access to logs where appropriate on reasoned request.

Actions to Take Before August 2, 2026

Logging architecture is one of the hardest requirements to retrofit, because it touches the core inference pipeline. Providers should finalise a logging specification now, implement it in the current development cycle, and verify that retention and export functions work end to end. Deployers preparing for August 2, 2026 should ask their providers to demonstrate the logging capability and confirm how logs will be made available to them. This article provides general information about Regulation (EU) 2024/1689 and is not advice on any specific implementation.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.