EU AI Act logging requirements for AI agents: an engineering read of Article 12

TL;DR. The EU AI Act's high-risk obligations became enforceable on August 2, 2026, and Article 12 requires high-risk AI systems to allow automatic event logging over their lifetime, with logs kept at least six months by providers (Article 19) and deployers (Article 26(6)), under fines of up to 15 million euros or 3 percent of worldwide turnover. The Act says why to log, in three purposes, and almost nothing about what to log, and the technical standards meant to close that gap are still drafts. For AI agents whose actions land on a database, there is a concrete answer available today: a statement-level audit trail, recorded in the data path where the agent cannot suppress it. This post maps the three legal purposes onto that event stream. It is an engineering read of the text, not legal advice.

On August 2, 2026, the largest block of the EU AI Act became enforceable: the high-risk system obligations in Articles 9 through 17 for providers, and Article 26 for deployers, per the timeline in Article 113. Somewhere in the middle of that block sits Article 12, record-keeping, one paragraph of which will decide how auditable your AI agents are: high-risk AI systems must "technically allow for the automatic recording of events" over their lifetime.

That sentence is doing a lot of work, and the Act gives engineers very little help with it. The regulation defines three purposes the logs must serve and then, with one narrow exception for biometric systems, declines to name a single event worth recording. The harmonized technical standards that are supposed to translate purpose into practice are not finished. Teams shipping AI agents into scope have to interpret, now, with fines under Article 99(4) reaching 15 million euros or 3 percent of worldwide annual turnover, whichever is higher.

This post is that interpretation for one specific and increasingly common case: AI agents whose actions are database reads and writes. It turns out the database case has an unusually clean answer.

First: is your agent even in scope?

Article 12 binds high-risk AI systems, and high-risk is a property of the use case, not of the technology. The categories are enumerated in Annex III: biometrics, critical infrastructure, education, employment, access to essential services (including creditworthiness assessment and life and health insurance pricing), law enforcement, migration, and the administration of justice. AI that is a safety component of regulated products follows a separate track with a later deadline in 2027.

So an agent that queries a database is not high-risk because it queries a database. It is high-risk when the queries serve an Annex III purpose. Concretely, that includes an agent that computes or updates the features feeding a credit decision, screens candidates against an HR database, determines eligibility for benefits or public services, or maintains the tables an insurance pricing model reads. An internal copilot that helps your team tune indexes and investigate slow queries is, in almost every reading, not in scope.

Two role distinctions matter because they split the obligations. If you build the agent system, you are a provider: Article 12 is a design duty (the system must be capable of logging), and Article 19 makes you keep the logs under your control for at least six months. If you run someone else's agent, you are a deployer: Article 26(5) makes you monitor its operation and suspend it when risk appears, and Article 26(6) makes you keep the logs under your control, again at least six months. If you are deploying a vendor's agent against your own database, that last clause is a contract question worth settling before the first incident: you need access to logs you can retain, not a dashboard the vendor can retire.

And if your agents are not in scope at all, the rest of this post still describes the audit trail you will wish you had during your first serious agent incident. The regulation is one reason to build it; it was never the best one.

What the text actually requires

The relevant provisions are short, and worth having in one place.

Notice the shape of Article 12(3): when the legislator wanted to name events, it could, and it did so only for biometrics. For everything else, the event list is delegated to the three purposes in 12(2). That is the gap engineering has to fill.

The three purposes, translated to database events

For an agent whose actions are statements against a database, each of the three purposes maps onto a concrete slice of one event stream.

One trail, three legally required views over it.

Purpose (a): identifying situations that may present a risk, or a substantial modification. In database terms, the most valuable events here are the ones that did not execute: statements denied by policy, unbounded UPDATE and DELETE attempts, schema-change attempts, reads against tables outside the agent's declared scope, and every approval or override a human granted, with the identity of the human. Note the second half of the purpose: substantial modification. An agent is modified when its model version, system prompt, or toolset changes, and when its behavior drifts into statement shapes the policy has never classified. Both belong in the log, because both are exactly what an investigator needs to correlate "the incidents started here" with "this is what changed."

Purpose (b): facilitating post-market monitoring. Article 72 requires providers to run a post-market monitoring system fed, among other things, by these logs. That makes completeness the requirement: every statement, with its classification, the policy decision, the outcome, the error if any, and the agent version that produced it. This is also where aggregates earn their keep: a rising deny rate, a new cluster of statement shapes, a table suddenly appearing in an agent's traffic. Monitoring is the purpose that turns the trail from an incident archive into an early-warning instrument.

Purpose (c): monitoring of operation by the deployer. Article 26(5) is written for a human audience: the deployer must be able to watch the system work, report issues, and suspend it when risk appears. The log view that serves this is session reconstruction: which agent, acting on behalf of whom, ran what, against which data, on whose approval, in what order. This is the operational half of an access policy for AI agents on production databases: the policy says who may run what, and the trail proves what actually ran. A duty to suspend implies something subtler, too: you cannot suspend on a signal your logs do not surface. The suspension evidence has to exist before the decision needs making.

Why the log must live where the agent cannot reach it

Article 12(1) says automatic. An agent that writes its own activity log fails that bar at exactly the moments the log matters most. Prompt injection sits at the top of the OWASP risk list for LLM applications because a model cannot reliably separate trusted instructions from content it reads along the way; a hijacked agent logs what its instructions tell it to log, which by then is the attacker's choice. The argument is the same one we made about guardrails that live inside the agent's context: a record the agent can edit is a record an injected payload can edit.

The structural fix is placement. Generate the events in the data path, between the agent and the engine, at the point where a statement becomes real. A gateway or proxy that classifies and mediates each statement sees everything the agent does, cannot be prompted, and produces the one account of events that does not depend on the agent's honesty. Statement-level capture is the right granularity because it is the ground truth of what happened to the data; application-side logs remain useful as context, but they describe intent, not effect.

Append-only follows from the purposes rather than from the text. Article 12 never says immutable, but all three of its purposes are forensic: risk identification, monitoring, and operational reconstruction each collapse if the writer can rewrite history. The case for an immutable, append-only ledger of agent actions is the same case, made from the engineering side a year before the enforcement date made it topical.

Retention: six months is the floor, and logs are data too

The six-month minimum appears twice, once for providers in Article 19 and once for deployers in Article 26(6), each time with the qualifier that other Union or national law can require more. Treat six months as a floor: post-market monitoring across releases, seasonal traffic patterns, and any incident with legal consequences all argue for longer.

The counterweight is that an audit trail is itself a data store, and data protection law applies to it. The practical design rule: log the statement, not the data. A trail that records the SQL text, the classification, the decision, the approver, the row count, and a result checksum satisfies every purpose in Article 12(2). A trail that records result sets has quietly become a second store of personal data with its own retention, access, and deletion obligations. Keep the trail lean enough that keeping it six months or longer is a policy choice, not a liability.

The standards are drafts; the purposes are not

The technical standards meant to make all of this concrete are close but not done. ISO/IEC 24970, AI system logging, has reached the final draft stage, and its European counterpart prEN 18229-1 is still moving through CEN/CENELEC. When the European standard is published as harmonized and cited in the Official Journal, conforming to it will carry a presumption of conformity with the Act's requirements. That is the moment compliance gets a checklist.

Waiting for the checklist is the wrong move, because the enforcement date has already passed and the purposes are stable even while the standards churn. The defensible position today is a documented mapping: for each of Article 12(2)'s three purposes, the event classes in your trail that serve it. That mapping is also, not coincidentally, a good audit trail design review: any purpose with no events behind it is a gap, and any event class serving no purpose is cost.

Where Datapace fits

Datapace is building the layer this post keeps describing from the compliance side: a policy gate in the data path that classifies every agent statement by risk, gates the dangerous ones behind human approval, and records each proposal, decision, approver, and outcome in an append-only trail, on top of a context layer that knows what the tables mean, so the classification has something real to reason against. We did not design it for Article 12; we designed it because agents were touching production databases without a defensible account of what they did. The overlap with the regulation's three purposes falls out of that, and it is under construction rather than shipped. If your agents are in scope, or you simply want the trail before the incident instead of after it, see what we are building or book a call.

Sources

1. EU AI Act, Article 12: Record-Keeping
2. EU AI Act, Article 19: Automatically Generated Logs
3. EU AI Act, Article 26: Obligations of Deployers of High-Risk AI Systems
4. EU AI Act, Article 99: Penalties
5. EU AI Act, Annex III: High-Risk AI Systems
6. ISO/IEC FDIS 24970, Artificial intelligence: AI system logging
7. AI Standards Hub: ISO/IEC DIS 24970 and prEN ISO/IEC 24970
8. Help Net Security: What the EU AI Act requires for AI agent logging