EU AI Act Record-Keeping and Logging: Article 12 for High-Risk AI

Record-keeping under the EU AI Act is not a filing-cabinet duty — it is a technical design requirement. Article 12 of Regulation (EU) 2024/1689 says a high-risk AI system must, by its own design, automatically record events ("logs") over the lifetime of the system. The point is traceability: if something goes wrong, there must be a machine-generated trail that lets you reconstruct what the system did and when. Two parties carry the obligation in different ways — the provider builds the logging in, and the deployer keeps the logs it controls for at least six months. Get that split right and most of the confusion around "AI audit logs" disappears.

This page covers what Article 12 requires, what to log, who keeps what, and how it connects to the rest of the high-risk regime — Article 19, Article 26, Article 72 and Article 73.

---

What Article 12 actually says

Article 12 requires that high-risk systems technically allow the automatic recording of events throughout their lifetime. The logging capability is built into the system; it is not a manual diary someone fills in. The recorded events have to support a level of traceability appropriate to the system's intended purpose — enough to identify situations that may cause the system to present a risk or undergo a substantial modification, to support post-market monitoring (Article 72), and to support the deployer's monitoring under Article 26.

For one category, the Act is more prescriptive. For remote biometric identification systems (Annex III, point 1), Article 12 specifies minimum logging: the period of each use, the reference database checked, the input data that produced a match, and the natural persons involved in verifying results. Most high-risk systems do not have that fixed list — but every one needs logging that delivers genuine traceability.

---

What to log

Article 12 sets the standard ("traceability appropriate to the intended purpose") rather than a universal field list for every system. In practice, a defensible log captures:

• When — timestamps for each significant event across the lifecycle.
• What — the operation performed, the input received, and the output produced.
• State — model version, configuration, and any threshold in force at the time.
• Anomalies — errors, fallbacks, and situations that may indicate the system is presenting a risk.
• Human actions — overrides, interventions, and stops (the Article 14 oversight events).

For remote biometric identification, add the Article 12 minimum list above. Design the logs so they are tamper-evident and queryable — a log you cannot search is not much use during a 15-day incident clock.

---

Who keeps which logs

This is where most teams go wrong, so be precise about it.

So Article 12 is the capability; Articles 19 and 26(6) are the retention. The provider keeps the logs it controls under Article 19; the deployer keeps the logs it controls under Article 26(6) for at least six months. Whoever physically holds and controls a given log set is the party that must retain it.

---

Why six months, and why it matters

The deployer's six-month floor under Article 26(6) exists because the harms Article 12 is meant to help reconstruct — a biased decision, a malfunction, an incident — often surface weeks or months after the event. If logs are rotated out after thirty days, you cannot investigate a complaint about a decision made in spring by the time it lands in autumn. Six months is the minimum; sectoral or national law (financial services, for example) can require longer, and your own intended-purpose analysis may justify more.

---

How logging connects to the rest of the regime

Article 12 is rarely invoked alone. The logs are the evidence layer beneath several other duties:

• Post-market monitoring (Article 72) — the provider's system for collecting and analysing field experience runs on log data.
• Serious-incident reporting (Article 73) — when a serious incident under Article 3(49) occurs, the logs supply the causal analysis and the timeline the provider's report needs.
• Human oversight (Article 14) — override and intervention events should be logged so oversight can be shown, not just asserted.
• Risk management (Article 9) — anomalies in the logs feed back into the living risk-management system.

In other words, weak logging quietly undermines four other obligations. Strong logging makes them auditable.

---

Worked example: a deployer and provider sharing the trail

Ostsee Klinik-IT GmbH, a hospital-IT operator with about 240 employees and roughly €41M turnover, deploys a high-risk clinical-triage support system built by an external provider. The provider designed the system to log every triage recommendation, the input vitals, the model version, and any clinician override — discharging the Article 12 capability requirement and keeping the logs on its own infrastructure under Article 19. Ostsee, as deployer, also receives a copy of the operational logs under its control and retains them for at least six months under Article 26(6) — in fact longer, because health records law requires it. When a clinician flags an anomalous recommendation, the logs let both parties reconstruct exactly what the system saw and did. The same trail would feed an Article 73 report if the anomaly turned out to be a serious incident, and it feeds the provider's Article 72 post-market monitoring either way.

---

How Confir helps

Confir registers each high-risk system with its logging design, the responsible party for each log set, and the retention clock, so the Article 12 capability and the Article 19 / Article 26(6) retention duties are tracked against the right party rather than assumed. It surfaces the six-month deployer floor and links the log record to the Article 72 monitoring and Article 73 incident workflows, so the evidence trail is connected rather than siloed. The engine is deterministic and rule-based.

---

Related guides

• Article 12 record-keeping requirements
• Article 26 deployer obligations
• Deployer obligations under the EU AI Act
• Post-market monitoring (Article 72)
• Article 73 serious-incident reporting
• Annex IV technical documentation