EU AI Act Article 12: what to keep when AI agents change your systems

The word doing the most work in Article 12 of the EU AI Act is “technically”. The article says a high-risk AI system must “technically allow for the automatic recording of events” over its lifetime. It doesn’t say the operator should keep good logs, or that someone should switch logging on before an audit. It says the system itself has to be capable of producing the record, by design, before it’s placed on the market or put into service.

That’s a different requirement from the one most teams think they’re meeting. An agent that could log but currently doesn’t is not compliant. Neither, I’d argue, is a pile of logs that exist somewhere but can’t be put together into an account of what happened.

The obligations for high-risk systems under Article 6(2) and Annex III applied from 2 August 2026. So this is no longer a planning exercise. If you run agents in a regulated setting, the question now is what you can actually produce when someone asks.

Are you in scope?

The Act defines high-risk systems in Article 6 and Annex III. Annex III covers eight areas: biometric identification, critical infrastructure, education and vocational training, employment, essential private and public services (which expressly includes creditworthiness assessment and life and health insurance risk classification), law enforcement, migration and asylum, and the administration of justice.

For most regulated organisations, the areas that bite are employment and essential services. An AML screening agent that feeds a decision about whether to keep a customer relationship is very likely in scope. So is a claims agent that influences an approval, or a casework agent in a public benefits service.

Article 6(3) lets a provider document that a system in an Annex III area falls outside the high-risk category because it poses only limited risk to health, safety or fundamental rights. The bar is high and the reasoning has to be written down. If you’re unsure, I’d assume you’re in scope.

What Article 12 asks for, in plain language

Read the article itself on EUR-Lex (Regulation (EU) 2024/1689). Summaries, including this one, compress it. Broadly, the logs have to make a few things possible.

They have to help identify situations where the system may present a risk. That means recording enough about inputs, outputs and behaviour that you could spot the system drifting toward a harmful or wrong result.

They have to capture substantial modifications across the system’s lifetime, from first use to decommissioning. A new model version is the obvious example. A change to training data is another. So, I’d argue, is a change to the prompts or rules that shape how the system behaves in scope. This is the part that gets interesting once AI agents are the ones making changes. If an agent can alter a prompt template, a rule set or the code around a high-risk system, then the history of those changes is part of the evidence, and it needs to say who or what made each one.

They have to support post-market monitoring under Article 72, which means enough operational detail to notice drift, unexpected outputs and new failure modes once the system is live.

And they have to cover normal operation in enough detail to understand what the system did and on what basis.

The Act also describes logs that identify the period of use, the reference database the input was checked against, and the input data that led to an output. That last one is the hard one. A regulator wants to know what the system knew when it decided, which is not the same as what it knows today. If your memory or retrieval store only holds the current state, that question has no answer.

For most high-risk systems the baseline retention period is six months, and sector rules can push it longer. Financial firms, for example, also have record-keeping duties under DORA.

The Act doesn’t use the phrase “tamper-evident”. In practice I think the requirement amounts to the same thing. A log that can be quietly edited after the fact can’t reliably show a risk situation or support an investigation. The harmonised standards being developed with CEN-CENELEC should make the expectation more precise.

On penalties, Article 99 sets a tiered structure. Prohibited practices under Article 5 carry fines of up to EUR 35 million or 7% of global annual turnover, whichever is higher. Breaches of the high-risk obligations, Article 12 included, sit in the middle tier at up to EUR 15 million or 3%. Supplying incorrect information to a notified body or authority can reach EUR 7.5 million or 1%. These are maximums, and actual penalties depend on the case and on national enforcement.

When I first wrote this, there were Commission proposals under the Digital Omnibus heading that would have delayed some SME obligations and adjusted certain Annex III criteria. They weren’t law at the time. Check the current consolidated text before relying on any change, and either way I wouldn’t build a compliance plan around a hoped-for delay.

Why most agent stacks struggle

The practical test is simple. Can you answer a regulator’s reconstruction question from the system itself? “Show me everything the system knew and did on this transaction, at this time.” To do that you need a record of which agent acted and at which version, what input it received, what it produced, when, under which rule, and whether a person was involved. And nobody should be able to edit it afterwards.

Now picture a typical stack. An orchestration framework, a database or vector store for memory, a hosted model API, and a logging table added later. Anyone with database access can change the logging table. The memory store overwrites old state, so what the agent knew last month is gone. The model version probably isn’t recorded per call. The prompt template that shaped the output isn’t captured. The policy that governed the decision doesn’t exist anywhere as an artefact at all.

None of these tools is bad. They just weren’t designed to produce regulatory evidence, and it’s hard to add that later without rebuilding the parts that matter.

Take an AML screening workflow as an illustration. Transactions come in through a pipeline, get screened against sanctions lists and internal rules, are scored for risk, and exceptions go to an analyst who may file a suspicious activity report. In a stitched-together setup, the ingest step may or may not record which pipeline version ran. The screening result lands in a decisions table. The risk score probably lacks the model version. The analyst’s review is a ticket in a separate tool. The filed report has no reliable link back to the evidence behind it.

Ask that organisation for the Article 12 record for one transaction on one date and they’ll have to reconstruct it from five systems that were never meant to agree. The data exists, mostly. It just can’t be produced as an automatic, trustworthy record.

What to check in your own systems

If you’re responsible for a high-risk workflow, the useful first step is an honest map, not a new tool. Pick one workflow that’s live or close to it. List each step and, for each one, ask whether your systems produce an automatic, unalterable record of it today. In my experience at least a few steps will come back as no, or as “we have something that wouldn’t survive scrutiny.”

Then ask the questions a regulator would:

• For a specific decision, can you show which agent or model acted, at which version, under which rule?
• Can you reconstruct what the system knew at that moment, rather than what it knows now?
• If an agent or a person changed a prompt, rule or piece of code around this system, is that change recorded, attributed and dated?
• Is the human review captured in the same record as the system’s actions, or in a separate tool?
• If someone altered an old entry, would you be able to tell?
• Where do the logs live, and could they stay inside your own infrastructure if a supervisor asked?

Article 11 also requires technical documentation for high-risk systems, and your logging design belongs in it. If you can’t write that section clearly, it’s usually a sign the design isn’t there yet.

Where this is heading

More and more of the changes to these systems will be made by AI agents rather than people. That’s what we’re working on at Deep Thinking. In Kizuna, every change an agent makes to your software leaves one record: who asked for it, which agent did it, what checked it, who approved it and under which rule. It’s the kind of record Article 12 points toward, produced as part of the work itself. We’re still in development, so treat that as direction rather than a compliance claim.

Whatever you use, I’d hold onto the principle in that word “technically”. A system that can be configured to log depends on someone keeping the configuration right. A system that can’t act without leaving a record makes the question of whether it’s logging the same as the question of whether it’s running.

If you’re mapping a high-risk workflow and want to compare notes, we’d like to hear from you. For more on what the record should answer, see deterministic replay as the audit trail, and for the human side of oversight, approvals that keep up with your agents.

This article cites the EU AI Act (Regulation (EU) 2024/1689) as published on EUR-Lex. The 2 August 2026 date refers to the obligations for high-risk AI systems under Article 6(2) and Annex III. Penalty figures are statutory maximums under Article 99. This is not legal advice; check the current consolidated text and your national supervisory authority’s guidance.