EU AI Act Article 12: What Logging It Actually Requires

Article 12 of the EU AI Act is short, three paragraphs, but it drives a lot of engineering work for any team running a high-risk AI system. It requires automatic logging capabilities built into the system, not documentation written after the fact. That distinction, automatic versus manual, is where most existing logging setups fall short and where teams need to start their gap analysis.

What the article actually says

Article 12 requires high-risk AI systems to "technically allow for the automatic recording of events (logs) over the duration of the lifetime of the system." The logging must enable three things specifically: identifying situations that may present a risk to health, safety, or fundamental rights, or that constitute a substantial modification of the system; facilitating post-market monitoring; and monitoring the operation of the system in production.

For remote biometric identification systems, the article adds specific mandatory fields: the period of each use, the reference database checked against, the input data that led to a match, and the identity of the individuals who verified the result. This is the only place Article 12 gets prescriptive about exact fields. For every other high-risk category, the article states the purpose the logs must serve and leaves the specific implementation to the provider, which is both flexible and a trap, because "good enough for our purposes" and "good enough to satisfy a regulator" are not automatically the same standard.

The compliance timeline

High-risk AI system obligations, including Article 12, apply from 2 August 2026 for the systems listed in Annex III, following the AI Act's staggered rollout that began with prohibited-practice bans in early 2025. Systems already in production need their logging retrofitted before that date, not designed after an examiner asks for records that were never being generated.

Who is responsible for what

Article 12 obligations split between two roles that companies often conflate. Providers, the organizations that build and place the high-risk AI system on the market, are required to design the system so that logging capability exists and functions correctly. Deployers, the organizations actually using the system in their operations, are responsible for ensuring that logging is properly implemented, maintained, and used in line with its intended purpose during actual operation. If you buy a high-risk AI system from a vendor, you cannot assume their engineering satisfies your Article 12 obligation as the deployer. You need to verify logging is switched on, correctly configured, and retained for at least the required period in your own environment.

The field most teams forget: logging the logging system itself

Article 12 obligates you to record events that identify risk situations and substantial modifications to the system. Most implementations log the AI system's outputs and forget to log changes to the AI system's own configuration, such as a model version upgrade, a prompt template change, or an adjustment to which tools an agent can access. A "substantial modification" under the AI Act can itself trigger new conformity obligations, and you cannot detect that a substantial modification occurred if you never logged the change that constitutes it. Treat configuration and version changes to the AI system as first-class logged events, not just its runtime decisions.

The second overlooked point is retention scope. Article 12 sets a floor of six months for log retention, but that clock needs to be tracked per log entry from its creation date, not as a blanket "delete everything older than six months" sweep run once a year. A naive retention job that runs monthly and deletes anything older than the last run date can, depending on timing, delete records before they hit the six-month floor. Build retention logic that checks each entry's own age against the requirement, not a batch cutoff.

Practical logging architecture for agentic systems

Agentic AI systems complicate Article 12 because a single user request can trigger many internal steps: tool calls, retrieved documents, intermediate model calls, and a final action. Logging only the final output does not satisfy "monitoring the operation of the system," because the operation includes everything the agent did to get there.

A workable approach:

1. Assign a run ID to every user-triggered agent execution, and tie every downstream log entry (tool call, model response, human approval) to that ID so the full chain reconstructs cleanly.
2. Log configuration and version changes separately from runtime events, with their own retention clock, since these are the events most likely to constitute a substantial modification under the Act.
3. Store logs append-only, so the record cannot be altered after the fact, which is a de facto requirement even though Article 12 does not use that exact word, because a mutable log fails the "reliable evidence" test any regulator will apply.
4. Set per-entry retention, not batch retention, so partial-month sweeps cannot delete records before the six-month floor.
5. Verify logging is active in production, not just in the design spec, especially if you deployed a third-party high-risk AI system where the provider built the capability but you, as deployer, are responsible for it running correctly.

Where this connects to your broader compliance posture

Article 12 does not stand alone. It works alongside Annex III risk classification (which decides whether Article 12 applies to your system at all), GDPR-driven audit trail obligations wherever personal data flows through the system, and human oversight requirements that need their own logged evidence of when and how a person intervened. Building one logging architecture that serves all three, rather than three separate logging efforts bolted together, is the difference between a maintainable compliance posture and a growing pile of disconnected log tables nobody fully trusts.

If you are evaluating or building an agent platform for a high-risk use case, ask the vendor directly whether automatic logging, append-only storage, and configurable retention are built in by default, or whether you would need to build that layer yourself. That answer tells you more about production readiness than almost any other question on the list.