EU AI Act Article 12: Logging Requirements for High-Risk AI Systems
Article 12 requires high-risk AI to log events automatically. Art 12(3) biometrics rules, provider vs deployer retention, and the 2 Dec 2027 deadline.
Every high-risk AI system under Regulation (EU) 2024/1689 must be built with the capacity to record what it does, when it does it, and under what conditions. Article 12 is the provision that makes this a design requirement — not an afterthought, not a post-deployment patch. If you are developing or deploying a high-risk AI system, you need to understand what Article 12 demands, how it connects to your retention obligations under Articles 19 and 26, and what the specific rules are for remote biometric identification systems under Article 12(3).
The compliance deadline for Article 12 — as with all high-risk obligations on stand-alone Annex III systems — is 2 December 2027, under the Digital Omnibus agreed in May 2026. That date deferred the original 2 August 2026 deadline. It is not distant. Designing the logging capability takes time; it needs to be specced alongside the system architecture, not retrofitted six months before the deadline.
What Article 12 Actually Requires
Article 12 does one specific thing: it requires that high-risk AI systems be technically capable of automatically recording events — logs — throughout their operational lifetime. This is a design requirement placed on providers. You build it in. The system, by its nature, must generate a reliable audit trail of its own operation.
This is distinct from the question of who keeps those logs, for how long, and under what obligations. Article 12 is the capability requirement. Retention obligations live elsewhere: Article 19 covers logs the provider controls; Article 26 covers the deployer's obligation to retain logs it controls for at least six months. Conflating these three provisions is common — and consequential. They are different obligations on different actors at different points in the system's life.
Article 12(1): Traceability Appropriate to the Intended Purpose
Article 12(1) establishes that logging must enable a level of traceability appropriate to the intended purpose of the system. The framing is deliberately proportionate — a narrow-scope Annex III system used in a well-defined administrative process does not need the same depth of logging as a risk-scoring model processing thousands of decisions daily. What you log must match what matters for that system's risk profile.
Two specific purposes are called out in the text. First, identifying situations where the system may be presenting the kind of risk that would require action under Article 79(1) — situations involving a risk to health, safety, or fundamental rights. Second, supporting the post-market monitoring obligation under Article 72, which sits with the provider. Logs are the evidentiary backbone of post-market monitoring. Without them, a provider cannot fulfil Article 72 in any meaningful way.
A third, implicit purpose follows from Article 12(1)'s reference to traceability: supporting investigation in the event of a serious incident reportable under Article 73. Incident reports to the market surveillance authority must be grounded in facts. Logs are where those facts come from.
Article 12(2): Traceability for Risk Detection and Substantial Modification
Article 12(2) specifies that the automatically generated logs must enable traceability at least to the extent necessary to:
- establish whether the system has presented, or could present, the risk described in Article 79(1); and
- support assessment in cases of substantial modification — the kind of change that, under Article 43, would trigger a new or updated conformity assessment.
In practice, this means your logging architecture needs to capture enough context to reconstruct what the system was doing at the relevant time: what inputs it received, what configuration it was operating under, whether any parameters had changed, and whether a human overseer intervened or overrode an output. A sparse log that records only a timestamp and a top-level output label will not satisfy this. The log needs to support a forensic review, not just confirm that the system ran.
The substantial modification angle is worth particular attention. Article 43 requires that providers assess whether a change to a system triggers re-conformity assessment. That assessment is only credible if you can compare the system's current behaviour with its pre-modification baseline. Logs provide that comparison. A provider who cannot demonstrate what the system was doing before a change, and what it is doing after, has no reliable basis for the substantial modification determination.
Article 12(3): Mandatory Minimum Logging for Remote Biometric Identification
Article 12(3) sets a statutory floor for one specific category: Annex III point 1(a) remote biometric identification systems. These face the highest scrutiny in the Annex III list, and the logging requirements reflect that. For remote biometric identification, the automatically generated logs must record, at a minimum:
- The period of each use — specifically, the start date and time and the end date and time of each operational session.
- The reference database against which the input data was checked.
- The input data that produced a match — the system must log the specific data that led to a positive identification result, not merely that a match occurred.
- The identity of the natural persons involved in verifying results under Article 14(5) — the human reviewers who checked and confirmed the system's output before it was acted upon.
This is not a checklist providers can approximate or "substantially" comply with. It is a statutory minimum. A remote biometric identification system whose logs do not capture all four elements fails Article 12(3) on its face. The fourth element is particularly important: it creates an accountability trail for the human oversight mechanism required under Article 14. If something goes wrong, the record must show who reviewed the result and when.
The requirement to log the identity of the verifying persons also raises a practical question about data minimisation. The reviewer's identity is personal data; the input data leading to a match is almost certainly personal data. Both are required under Article 12(3). That tension is real and is addressed in the GDPR interaction section below.
The Logging Chain: Three Actors, Three Obligations
A clear picture of who is responsible for what prevents the most common compliance failure in this area — providers assuming deployers will sort out the logging, and deployers assuming the provider has covered it.
Provider (Article 12): Designs and builds the logging capability into the system. This is a pre-market requirement — the system must have the technical capacity to generate the required logs automatically before it is placed on the market. The provider cannot offload this design obligation to the deployer. If the system cannot log automatically at the required level of granularity, it is non-compliant before a single deployment occurs.
Provider (Article 19): Keeps the logs that are under the provider's own control. The retention timeframe is not specified in Article 12 itself — it is determined by Article 19, which ties the provider's log retention to its post-market monitoring obligations under Article 72. In practice, providers should retain logs for the active service lifetime of each version of the system, plus a reasonable period after withdrawal from service.
Deployer (Article 26): Keeps the logs generated during the deployer's own use of the system for at least six months, unless other applicable EU or national law requires a longer period. This is a direct legal obligation on the deployer — it is not conditional on the provider instructing them, it cannot be contracted away, and it is not satisfied by the deployer passing logs back to the provider. The deployer must retain the logs it controls.
The practical implication is that both parties need to establish, before the system goes live, which logs each one controls and which retention obligations follow. That clarity belongs in the contractual arrangement between provider and deployer — and both parties must be able to demonstrate their compliance to a market surveillance authority independently of each other.
Why Logs Matter Beyond the Act Itself
The automatic record-keeping obligation in Article 12 has value that extends well beyond strict EU AI Act compliance. Four areas matter in practice:
Audits and inspections. National market surveillance authorities can request access to logs under Article 74. A competent authority investigating a specific incident can require production of logs to reconstruct the sequence of events. A system that cannot produce structured, reliable logs makes the investigation harder and, more practically, gives the authority less reason to approach the operator's account of events with any confidence. Operators with clean log archives tend to fare better in regulatory contact than those without.
Incident investigation. When something goes wrong with a high-risk AI system, the question is always: what happened, and when did it start? Logs are the answer. Without them, root-cause analysis is speculative. Providers with systematic logging can investigate quickly, isolate the anomaly, contain the problem, and report accurately under Article 73. The incident report the Act requires must be grounded in evidence. Logs provide that evidence.
Conformity evidence. Logs feed directly into the post-market monitoring system under Article 72. Providers must establish, document, and actively maintain that system. It requires data — specifically, real-world performance data generated during actual use. Article 12 logs are that data. A provider who claims to run a post-market monitoring programme but cannot show the underlying log data is not, in substance, running one.
Supporting the Article 14 human oversight record. Human oversight of high-risk AI is required under Article 14. That oversight is only demonstrable if it is recorded. Every intervention — a reviewer checking a system's output, an override, a decision to escalate — should appear in the logs. Article 12(3) makes this explicit for biometric systems by requiring the identity of the verifying person to be logged. For other high-risk systems, the same logic applies as a matter of effective compliance practice even where the statute does not specify it as a floor.
Logging and GDPR: A Genuine Tension
For most high-risk AI systems, the logs Article 12 requires will contain personal data. The candidates whose CVs a recruitment-screening system processed, the individuals a remote biometric identification system matched, the users whose queries a public-service eligibility system evaluated — all of these appear, in some form, in compliant Article 12 logs. GDPR and the EU AI Act apply simultaneously, and they pull in opposite directions on this point.
GDPR's data minimisation principle (Article 5(1)(c) GDPR) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." Article 12(3) of the EU AI Act requires logging the input data that produced a match in a biometric identification system — which is by definition personal data, and which must be retained for at least six months under Article 26. That is not data minimisation; it is data that is legally required to exist and to be kept.
The resolution is not to ignore one obligation in favour of the other. It is to document the legal basis carefully. The processing of personal data in Article 12 logs is required by a legal obligation (the EU AI Act itself) — which provides the legal basis under Article 6(1)(c) GDPR. The retention period is determined by Article 26's six-month minimum (or longer if Article 19 requires it for the provider). After the retention obligation expires, the data should be deleted or anonymised — the legal basis for continuing to hold it ceases to exist at that point.
Practical steps: implement access controls on the log store so that personal data in logs is not accessible to personnel who do not need it; apply encryption at rest; document the log data processing in your Record of Processing Activities under Article 30 GDPR; and ensure your data subjects' rights procedures account for the fact that personal data about them may exist in AI operation logs that cannot be deleted during the retention window.
Logging Architecture: What "Automatic" Means in Practice
Article 12 requires that logging be automatic. This is a design constraint, not a workflow suggestion. The system itself must generate the logs — not an operator remembering to press export, not a periodic manual review, not a downstream analytics pull. The event is recorded at the time it occurs, by the system, without requiring human action to trigger it.
For most well-architected systems, this is not technically difficult. The challenge is specifying the right scope at design time:
Granularity. What level of event needs to be captured? For a high-volume system making thousands of decisions daily, logging every individual inference with full input-output detail may generate storage volumes that are impractical to retain for six months. The answer is not to reduce logging — it is to design a tiered logging approach that captures all events at summary level, and full detail for a defensible, documented sample. Whatever the approach, it must be consistent with Article 12(2)'s requirement that logs support risk identification and substantial-modification assessment.
Immutability. Logs intended for regulatory purposes must be tamper-evident. If a log can be altered after the fact — entries deleted, timestamps adjusted, outputs retroactively modified — it has no evidential value. Technical controls should prevent post-write modification. At minimum, log integrity should be verifiable through hashing or similar mechanisms.
Access control. Log access is not universal. Personal data in logs is subject to GDPR access controls. Commercial-in-confidence operational data may be subject to IP protections. Design the log access model at the same time as the log schema — do not treat access control as a deployment-phase concern.
Retention and deletion. Article 26's six-month floor applies to deployer-held logs. Configure retention policies so that logs are automatically archived and deleted at the correct time. Manual deletion workflows are error-prone; automated schedules are more reliable and more defensible.
Exportability. Competent authorities who request logs under Article 74 need to be able to read them. A log stored in a proprietary binary format that requires the provider's own tooling to parse is not, in practice, available to a regulator. Design log output in a structured, documented format — JSON, CSV, or a documented schema — that an external auditor can work with independently.
A Worked Example: HR-Tech Provider, Recruitment Screening
A 60-person HR-technology company builds and sells a CV-screening tool to employers across Germany and the Netherlands. The tool ranks candidates against job requirements and flags those who meet threshold criteria. It falls under Annex III point 4 (employment, workers management, access to self-employment) and is high-risk under Article 6.
The company is the provider. Its Article 12 obligations arise at the design stage, before the product goes to market.
The system must be capable of automatically logging: each deployment session (start and end time), the job-role configuration applied during that session, the candidate data processed, and the ranking outputs generated. The granularity must be sufficient for a post-market monitoring review under Article 72 — if the tool's ranking accuracy degrades over six months, the logs must show when the drift began and under what input conditions. The company also needs to document a substantial modification assessment procedure: if the underlying model is retrained, the threshold parameters changed, or the intended use expanded to new sectors, the logs provide the before-and-after baseline for that assessment.
Each employer using the tool is a deployer. Under Article 26, each employer must retain the logs generated during its own use of the tool for at least six months. A recruitment cycle that closes in March does not give the employer permission to delete the March logs in April. The six-month clock runs from the date of processing, not from the date the vacancy was filled.
If a candidate later challenges the employer's screening decision — whether under GDPR's right to explanation, under national employment discrimination law, or in response to an investigation by a market surveillance authority — those logs are the factual foundation of the defence or the investigation. An employer who cannot produce them is in a weak position regardless of whether their process was, in substance, fair.
How Confir Helps
Confir's AIGM assessment module — Governance and Post-Market Monitoring, covering Articles 9, 72, and 73 — includes record-keeping as a structured control area. When you register a high-risk system, the rule-based assessment maps your system's logging architecture against Article 12's requirements: whether automatic logging is built in, whether the minimum Article 12(3) fields are covered for biometric systems, and whether your deployer-side retention policy meets the Article 26 six-month floor.
The immutable audit log in Confir records every compliance action — assessment completions, documentation updates, oversight sign-offs — with timestamps that cannot be altered. That log is itself evidence of your governance process, and it can be exported if a market surveillance authority requests a demonstration of how your organisation manages its AI Act obligations.
Record-keeping controls appear as a documented item in Confir's Article 11 / Annex IV technical documentation pack. The logging design and the retention policy both end up in the same conformity package, not scattered across separate systems that require manual reconciliation at audit time. Pricing starts at €600/year; no consultants, no implementation project. confir.eu.
Penalties
Non-compliance with Article 12 falls under the general high-risk obligations tier in Article 99(4). The maximum fine is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For companies qualifying as SMEs, Article 99(6) caps the fine at the lower of the two figures — a genuine proportionality protection, but not a reason to treat the logging requirement as optional.
The obligation applies from 2 December 2027 for stand-alone Annex III systems. That is the compliance date, not the design date. If your system needs to complete conformity assessment before going to market in late 2027, the logging capability needs to be designed, implemented, and validated considerably earlier. The Article 43 conformity assessment will look at Article 12. If the logging architecture is absent or inadequate at that point, the assessment fails.
Key Takeaways
Article 12 is a system design obligation, not an administrative one. Build the logging capability in from the start. Know which logs the provider controls (Article 19) and which the deployer controls (Article 26, six-month minimum floor). For remote biometric identification under Annex III point 1(a), the four Article 12(3) minimum fields are non-negotiable. Design logs that are automatic, immutable, exportable, and access-controlled from day one. And treat them as the evidentiary backbone of post-market monitoring under Article 72 and incident response under Article 73 — because that is exactly what they are.
Related guides
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →