EU AI Act Article 12: Logging and Record-Keeping Requirements

Every production AI system already logs something — errors, latency, request volume, the ordinary telemetry any engineering team builds for debugging and uptime monitoring. None of that is what Article 12 is actually checking for, which is exactly why the requirement gets treated as already handled without anyone comparing the real logs against the statute. The question Article 12 asks isn't "do logs exist." It's whether the logging capability was built to support three specific things the Act names — and generic application logs, built for entirely different purposes, frequently miss at least one of them.

What the logs actually have to support

Article 12 requires high-risk AI systems to technically allow for the automatic recording of events over the system's lifetime, with logging capability appropriate to the system's intended purpose. The statute ties that capability to three specific functions, not to logging in the abstract:

Identifying situations that could constitute a risk, or that could trigger a substantial modification. The logs have to be granular enough that a review of them could actually surface a pattern — a systematic error rate on a specific input type, a drift in output distribution — rather than just confirming the system ran.

Facilitating post-market monitoring. Whatever monitoring process the provider is required to run after the system is deployed depends on having the underlying event data to monitor in the first place. A monitoring program with no log data behind it is a plan, not a functioning process.

Supporting the deployer's own monitoring obligation. Deployers have their own duty to monitor the system's operation, and they can only do that with visibility into what the system actually did — which means the logs have to be structured in a way that's usable by the deployer, not locked inside a provider-only internal debugging system.

A logging setup that satisfies one of these three by accident — most commonly, basic uptime/error logging that helps with risk identification — often does nothing for the other two, because nobody designed it with post-market monitoring or deployer visibility in mind.

Article 12 itself doesn't state a retention number — that lives in Article 19, which sets a floor of at least six months, appropriate to the system's intended purpose, and longer where other applicable EU or national law (data protection rules, in particular) requires it. Six months is a floor, not a target: it's materially longer than the short rotation windows most teams default to for debugging logs, which frequently get purged after weeks, not the months a real post-market monitoring cycle or a delayed incident investigation might need to reach back into.

The extra baseline for remote biometric identification systems

Systems in the remote biometric identification category face a more specific, higher floor. At minimum, the logs have to capture: the period — start and end date and time — of each use; the reference database the input data was checked against; the input data for which a search actually produced a match; and identification of the people involved in verifying the results.

This is worth calling out specifically because it's the category where generic logging most reliably falls short. A typical inference log captures input, output, and a timestamp — it doesn't necessarily capture which reference database was queried, and it almost never captures who on the human side reviewed and verified a match, which matters because Article 14 requires two separate people to verify an RBI match, not one. Teams building or deploying an RBI system need to treat this as a distinct logging spec to design for, not an extension of whatever general-purpose logging already exists.

The fraud-detection log, dissected

Take an AI-assisted fraud-detection system flagging suspicious transactions for manual review — a common Annex III-adjacent high-risk use case. Generic logging captures the transaction ID, the model's fraud score, and a timestamp, which is enough for debugging a crashed request but not much else. Article 12-adequate logging captures the same event plus what the model actually weighed in reaching that score, which reviewer (if any) confirmed or overrode the flag and on what basis, and whether that specific transaction pattern had previously triggered a flag that was later found to be a false positive. The difference isn't volume of logging — it's whether the captured fields actually let someone reconstruct, months later, why the system made a specific call and whether a pattern of similar calls points to a systemic problem. A team that only discovers this gap when a regulator or an internal audit asks "show me why the system flagged this specific customer" has already lost the ability to answer well.

Why weak logs undermine everything else in Chapter III

This is the part generic explainers skip, and it's the reason Article 12 deserves more attention than a one-line compliance checkbox: logs are the evidence layer underneath most of the other high-risk obligations. The Article 9 risk management process is only as real as the data feeding it — a risk management system that's supposed to evaluate risks surfaced by post-market monitoring can't do that job if the underlying logs don't actually capture the events monitoring depends on. And when something does go wrong, whether that's an internal review or a regulator asking what happened, the investigation runs on whatever logs existed at the time — there's no retroactive fix for a gap in the record.

Put differently: an organization with a beautifully documented risk management process and thin, generic logs has a process that can't actually demonstrate it's running on real data, which is precisely the "paper process" failure mode risk management is supposed to avoid in the first place.

Where this fits with the rest of the high-risk obligations

Article 12 doesn't stand alone. The logging mechanisms it requires have to be described in the Article 13 instructions for use that ship to deployers, and the data these logs produce is a direct input into the ongoing risk management process. If a system hasn't cleared the Article 5 prohibited-practices screen or been classified high-risk under Article 6, none of this applies yet — but for systems that have, logging isn't a downstream detail to handle after the "real" compliance work is done. It's the record that makes the rest of it checkable.