Banks and fintechs now let AI agents approve loans, flag fraud, and screen applicants. When a regulator, a court, or an auditor asks you to prove what the agent decided, and that the record was not changed afterward, most teams have nothing that survives the question. EU AI Act Article 12 is one reason to close that gap. An adverse-action lawsuit, a SOC 2 audit, or an OCC exam is a sooner one. The Article 12 obligations for Annex III systems are deferred to 2 December 2027 under the Digital Omnibus, adopted by the Council on 29 June 2026 and pending publication in the Official Journal. Either way it is runway to do it right, not a reason to wait.
Article 12 requires high-risk AI systems to automatically record events (logs) over the lifetime of the system, for traceability of how the system functions. Article 19 then requires those logs to be kept for at least six months. That is the legal floor. The list below separates what the regulation literally says from what examination-grade evidence actually looks like. A log a regulator, a court, or an auditor cannot trust is not yet evidence.
Article 12(1) requires the system to record events automatically, over its lifetime. Not logs a person exports or assembles after the fact. For an AI agent making consequential decisions, the defensible reading is that a record is generated at the moment of each decision, by the system itself. Many teams already meet this with their existing logging.
Article 12 requires logging but does not, in its words, mandate cryptographic integrity. Yet a record that could have been edited after the fact is weak evidence to a regulator, a court, or an auditor. This is where evidence diverges from logging: the reader has to be able to confirm, independently, that no record changed after it was written. Most logging infrastructure cannot provide that proof.
Article 12(3) explicitly requires input-data logging for remote biometric identification systems (Annex III, point 1(a)). For other high-risk systems the text does not mandate it. But if you cannot show the input a decision was actually based on, you cannot reconstruct or defend the decision. For agents that use retrieval, that means the assembled prompt and every document pulled in.
Article 12(2) frames logging around traceability of the system's functioning. It does not spell out multi-agent chains. The Act predates today's agent architectures. But the principle is clear: if a decision spans several steps or hands off between agents, a single record at the end does not let anyone reconstruct what happened or why.
Retention lives in Article 19, not Article 12: logs must be kept for a period appropriate to the intended purpose, and at least six months, unless other law requires longer. Many teams already meet the retention bar; the harder part is that the records have to be usable: readable without your internal systems, and not dependent on a vendor still being around to interpret them.
Check what your team can demonstrate right now, not what you plan to build. The first item is the Article 12 legal baseline; the rest are what turn a log into evidence that holds up when a decision is challenged.
This is a reality check, not a sales funnel. Several of these you can satisfy with infrastructure you already run. If you can check most of them with your own stack, you do not need a vendor. Only check what you could actually show a regulator, a court, or an auditor today. Fill it out with whoever owns model risk or AI governance and your engineering lead.
We will look at what you have, tell you what would survive a regulator, a court, or an auditor, and where the gaps are. If your existing stack already covers it, we will tell you that. No pitch.
Book 15-minute call →Forward to whoever owns model risk, AI governance, or financial-crime engineering. They will know if this is real for your team.
URL: plainreal.com/article12