Art. 12: Record-keeping under the EU AI Act

Art. 12 requires a high-risk AI system to technically allow the automatic recording of events over its lifetime. The logs must give traceability of the functioning of the system appropriate to its intended purpose. The logs must serve risk identification under Art. 79(1), post-market monitoring under Art. 72 and deployer monitoring under Art. 26(5). In this mapping, ten elements are testable, six are documentation and four are process. Regulation (EU) 2026/1744 moved the application date for Annex III systems 2027-12-02Deferred and left the content of the article unchanged.

Where this applies

2027-12-02DeferredAnnex III standalone high-risk obligations
2028-08-02DeferredAnnex I product-embedded high-risk obligations

What the text requires

Art. 12 is a design requirement on the system, not a retention rule. The retention periods sit in Art. 19 for the provider and in Art. 26(6) for the deployer, and the event set depends on the risk management file under Art. 9 and on the log mechanism described in the instructions for use under Art. 13(3)(f).

What the text requires and how each element is verified
Requires	Testable	Documentation	Process
Art. 12(1)A high-risk AI system must technically allow for the automatic recording of events (logs). The recording must cover the lifetime of the system. Art. 12(2)The logging capabilities must enable the recording of events relevant for the three purposes in points (a) to (c). The events must give a level of traceability of the functioning of the system that is appropriate to the intended purpose of the system. Art. 12(2)(a)The logs must record events relevant for identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Art. 79(1). The logs must record events relevant for identifying situations that may result in a substantial modification. Art. 12(2)(b)The logs must record events relevant for facilitating the post-market monitoring referred to in Art. 72. Art. 12(2)(c)The logs must record events relevant for monitoring the operation of the high-risk AI system by the deployer, as referred to in Art. 26(5). Art. 12(3)For high-risk AI systems referred to in Annex III point 1(a), remote biometric identification systems, the logging capabilities must provide at a minimum the four items in points (a) to (d). Art. 12(3)(a)The logs must record the period of each use of the system. The period is the start date and time and the end date and time of each use. Art. 12(3)(b)The logs must record the reference database against which the system has checked the input data. Art. 12(3)(c)The logs must record the input data for which the search has led to a match. Art. 12(3)(d)The logs must record the identification of the natural persons involved in the verification of the results, as referred to in Art. 14(5).	Events are recorded automatically by the system, without an operator action, during normal operation (Art. 12(1)) Logging continues to function, with the same event set and format, after a model, software or configuration update over the lifetime of the system (Art. 12(1)) A sampled decision can be reconstructed from the logs alone: the input, the model version, the configuration in force, the output and the timestamp of the event (Art. 12(2)) Each risk indicator named in the risk management file under Art. 9 has a log event that records it, and the event fires when the indicator condition is met (Art. 12(2)(a)) A model version change, a threshold change or a configuration change after placing on the market produces a log event that identifies it as a candidate substantial modification (Art. 12(2)(a)) Each data point the post-market monitoring plan under Art. 72 consumes is present in the logs with the field definition the plan expects (Art. 12(2)(b)) The logs the deployer needs for monitoring operation under Art. 26(5) are readable and exportable by the deployer through the mechanism described in the instructions for use (Art. 12(2)(c)) For Annex III point 1(a) systems, each use has a logged start date and time and end date and time, and the two timestamps bound the observed session (Art. 12(3)(a)) For Annex III point 1(a) systems, each match records the identifier of the reference database checked and the input data that produced the match (Art. 12(3)(b) and (c)) For Annex III point 1(a) systems, each verified result records the identification of the natural persons who performed the verification under Art. 14(5) (Art. 12(3)(d))	Log schema and event catalogue: the event set, the fields per event, the format and the storage location, in the technical documentation under Annex IV section 3 (Art. 12(1)) Traceability rationale: a statement of the level of traceability appropriate to the intended purpose and how the chosen event set achieves it (Art. 12(2)) Mapping from each risk indicator in the risk management file and each substantial-modification trigger to the log event that captures it (Art. 12(2)(a)) Mapping from each data point in the post-market monitoring plan under Art. 72 to the log event that supplies it (Art. 12(2)(b)) Description in the instructions for use of the mechanisms that allow the deployer to collect, store and interpret the logs (Art. 12(2)(c) and Art. 13(3)(f)) For Annex III point 1(a) systems, the field specification for the period of use, the reference database identifier, the matched input data and the verifier identification (Art. 12(3))	Retention of the logs under the provider's control for the period set in Art. 19, and of the logs under the deployer's control for the period set in Art. 26(6) Change control that re-verifies the logging capability after each substantial modification or version change over the lifetime of the system (Art. 12(1)) Review of the event set whenever the intended purpose, the risk management file under Art. 9 or the post-market monitoring plan under Art. 72 changes (Art. 12(2)) Periodic review of the logs as an input to the post-market monitoring system under Art. 72 (Art. 12(2)(b))

Metrics and where thresholds come from

Threshold sources, in order of precedence

A harmonised standard cited in the Official Journal (none as of the anchor date)
A JTC 21 draft standard (prEN), with its stage
An ISO/IEC standard or technical report, with its stage
A Commission guideline or code of practice, with its date from the standards data
NIST AI RMF or a sector framework
The state of the art, which the provider justifies and documents

Regulation (EU) 2024/1689 sets no numeric threshold for Art. 12: the article names no retention period, event count, sampling rate, storage limit or clock precision. The one number connected with logs, the minimum retention period, sits outside this article in Art. 19 for providers and Art. 26(6) for deployers, subject to other Union or national law. Art. 12(3) sets a minimum event content for Annex III point 1(a) systems, not a numeric threshold. No harmonised standard is cited in the Official Journal, so hierarchy level 1 is empty. The event set, the fields and the traceability level come today from hierarchy level 2: prEN 18229-1, under enquiry, and prEN ISO/IEC 24970, at approval stage, read against the intended purpose stated in the instructions for use. The provider justifies and documents the event set and the traceability level against the context of use; the scope step of PR-12-LOG records that justification and the reconstruction step tests it.

Metric sources and their stage
Source and stage	Title	What it provides here	Verified on
`prEN 18229-1`Enquiry	AI trustworthiness framework, part 1: logging	the expected event set, log fields, retention requirements and traceability criteria for an Art. 12 log, giving a logging test its expected events and the fields each event carries	Verified on 18 September 2026kla.digital, JTC 21 Standards Tracker (updated 29 June 2026)
`prEN ISO/IEC 24970`Approval	Logging and traceability	a reference information model and common logging capabilities for AI system events, giving a logging test its event model and the field definitions for decision reconstruction	Verified on 18 September 2026ISO project record for ISO/IEC FDIS 24970 (ISRSM mirror of the ISO project database)

Procedures

Each protocol is versioned; its page states the derivation from the standards above. PR-12-LOG v1.0 covers every testable element in the table.

PR-12-LOG v1.0Logging completeness and reconstruction protocolv1.0

What an assessor asks for

Log schema and event catalogue (Annex IV section 3)
Traceability rationale record (Art. 12(2))
Risk indicator to log event mapping (Art. 12(2)(a) and Art. 9)
Post-market monitoring data point to log event mapping (Art. 12(2)(b) and Art. 72)
Log mechanism description in instructions for use (Art. 13(3)(f))
Log completeness and continuity test report (PR-12-LOG output)
Decision reconstruction record (PR-12-LOG output)
Log retention policy (Art. 19 and Art. 26(6))

Common findings

Logs record the output but not the model version and configuration that produced it, so a decision cannot be reconstructed after a retrain.
Application logs exist for debugging, and no event is tied to a risk indicator in the risk management file.
A model swap, a threshold change or a prompt change after placing on the market leaves no log event that marks it as a candidate substantial modification.
Logs sit in the provider's platform, and the deployer has no documented mechanism to read or export them for monitoring under Art. 26(5).
Timestamps use the local server clock without a time zone, so the period of use cannot be bounded across components.
Logging changes format or stops after a software update, and no record shows that the logging capability was re-verified.

Questions

What are the Article 12 logging requirements in the AI Act?

Art. 12(1) requires a high-risk AI system to technically allow for the automatic recording of events over its lifetime. Art. 12(2) requires the recorded events to give traceability appropriate to the intended purpose. The events must serve three purposes: identifying risk situations under Art. 79(1) or substantial modifications, post-market monitoring under Art. 72, and deployer monitoring under Art. 26(5). Art. 12(3) adds a minimum event content for remote biometric identification systems in Annex III point 1(a). The article names no event list for other systems; the provider derives the event set from the intended purpose and from the draft standards prEN 18229-1 and prEN ISO/IEC 24970.

What does AI Act Article 12 require a provider to build?

Art. 12 requires a logging capability inside the high-risk AI system, not a policy. The capability must record events automatically, without operator action, under Art. 12(1). The events must let a reader trace how the system functioned, to the level the intended purpose needs, under Art. 12(2). The provider describes the capability in the technical documentation under Annex IV section 3 and explains to the deployer how to collect, store and interpret the logs under Art. 13(3)(f). Whether the capability meets Art. 12 is tested by reconstructing a decision from the logs alone, which is the core step of PR-12-LOG.

What does the AI Act mean by record keeping?

In Regulation (EU) 2024/1689 the heading of Art. 12 is Record-keeping, and the article is about automatically generated logs. Art. 12 does not cover the technical documentation, which sits in Art. 11, or the quality management system records, which sit in Art. 17. Art. 12 asks that a high-risk AI system record events by itself over its lifetime and that the events give traceability of its functioning. Keeping the logs after they are generated is a separate duty: Art. 19 for the provider and Art. 26(6) for the deployer. Art. 19 and Art. 26(6) set the retention periods; Art. 12 does not.

What are the EU AI Act logging requirements for a high-risk system in practice?

The text gives three purposes in Art. 12(2) and one minimum event list in Art. 12(3), and nothing else. A logging design therefore starts from the intended purpose in the instructions for use and derives the events needed to trace the functioning of the system. The draft standard prEN 18229-1 gives an expected event set and fields, and prEN ISO/IEC 24970 gives an information model for AI system logging. Neither prEN 18229-1 nor prEN ISO/IEC 24970 is cited in the Official Journal, so neither gives a presumption of conformity. A test of the design records a sample of decisions and checks that each one can be reconstructed from the logs with its input, model version, output and timestamp.

How does EU AI Act Article 12 record keeping differ from the deployer's duty to keep logs?

Art. 12 is a design requirement on the provider: the high-risk AI system must be able to generate the logs. Art. 26(6) is an operational duty on the deployer: keep the logs the system generates, to the extent they are under the deployer's control, for the period that article sets. Art. 19 places the matching retention duty on the provider for the logs under its control. A deployer can only meet Art. 26(6) if the provider's system produces logs the deployer can access, which is why Art. 12(2)(c) ties the event set to deployer monitoring under Art. 26(5) and Art. 13(3)(f) requires the instructions for use to describe the log mechanism.

How does EU AI Act record keeping under Article 12 relate to the QMS?

Art. 12 requires the high-risk AI system itself to generate logs automatically. Art. 17(1)(k) requires the quality management system to hold systems and procedures for record-keeping of all relevant documentation and information. Art. 12 and Art. 17(1)(k) meet at the log retention procedure: the QMS procedure states how the logs generated under Art. 12 are kept for the period in Art. 19 and how they feed the post-market monitoring system under Art. 72. A logging test under PR-12-LOG checks that the logs exist and reconstruct a decision; a QMS review under PR-17-QMS checks that a procedure governs their retention and review.

How we test this

We test against Art. 12 by recording a sample of decisions and reconstructing each one from the logs alone, with its input, model version, configuration, output and timestamp, and by verifying that logging continues unchanged after a version update. We prepare evidence in the form of the log completeness and continuity test report and the decision reconstruction record, within the scope we can take on.

Logging and human-oversight verificationPR-12-LOG, PR-14-OVR
Pre-conformity mock assessmentPR-43-MOCK

What we cannot do

We do not perform conformity assessments where a notified body is required.
We do not issue CE marking or the EU Declaration of Conformity.
We are not a notified body.
We do not give legal opinions on classification or liability.
We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.

Read the full statement