From August 2026, the obligations for high-risk AI systems under the EU AI Act become enforceable. For financial services, this is not a peripheral concern. Credit scoring, creditworthiness assessment, and risk assessment and pricing in life and health insurance are explicitly classified as high-risk under Annex III of the regulation. Firms deploying AI in these areas will be subject to a specific set of technical obligations, and one of the most consequential is the requirement, set out in Article 12, for automatic logging.
The phrase "automatic logging" sounds like something most engineering teams already do. Applications produce logs. Models emit metrics. Surely the requirement is satisfied. It is not. Article 12 asks for something quite different from operational logging, and the gap between what firms currently capture and what the regulation expects is where the compliance risk sits. This article examines what Article 12 actually requires, how it interacts with Articles 13 and 14, and what a defensible logging capability looks like.
What Article 12 requires#
Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. The purpose is explicit in the text: logging must enable a level of traceability that is appropriate to the intended purpose of the system. The logs are not there to help engineers debug a service. They exist so that the operation of the system can be reconstructed and examined after the fact.
This distinction matters. Operational logs are written for the convenience of the people running the system, are typically retained for short periods, and are routinely rotated, sampled, or discarded once they cease to be useful for troubleshooting. Article 12 logs are written for an external observer who may need to understand a specific decision long after it was made. They must capture the events relevant to identifying situations that may result in the system presenting a risk, and to facilitating post-market monitoring.
Article 19 reinforces the point by requiring providers to keep the logs generated by their high-risk systems, where those logs are under their control, for a period appropriate to the intended purpose and no less than six months unless other law requires otherwise. For financial services firms, other law almost always requires longer. The interaction between the AI Act and sector record-keeping rules means the practical retention horizon is measured in years, not months.
Why operational logs do not satisfy it#
Consider what a regulator or an auditor would need in order to examine a single automated decision. They would need to know the inputs the system received, the output it produced, the version of the model that produced it, and enough surrounding context to understand why that output was reasonable given the circumstances at the time.
Most production systems cannot assemble this record. Inputs are scattered across request logs that may have been truncated for size. Outputs are recorded in one place, model versions in another, and the configuration that governed the decision in a third. The connective tissue that links a specific output to the exact model, inputs, and context that produced it is rarely captured deliberately. It has to be reconstructed, and reconstruction from fragmentary logs is precisely the situation the regulation is designed to prevent.
The honest test for any firm is simple. Take one automated decision from three months ago and attempt to produce a complete, structured account of how it was made. If that exercise requires cross-referencing several systems, querying logs that may already have been rotated, and making inferences about which model version was live at the time, the firm does not have Article 12 traceability. It has operational logs that happen to overlap with what the regulation needs.
How Articles 12, 13, and 14 work together#
Article 12 does not stand alone. It is part of a triad that, read together, describes a complete accountability expectation.
Article 13 requires transparency and the provision of information to deployers. High-risk systems must be designed so that their operation is sufficiently transparent to enable deployers to interpret the output and use it appropriately. A deployer cannot interpret an output they cannot see the basis for.
Article 14 requires human oversight. High-risk systems must be designed so that they can be effectively overseen by natural persons, including the ability to understand the system's capabilities and limitations and to intervene or interrupt its operation. Oversight is meaningful only if the person exercising it has access to the information needed to judge whether a given output should stand.
Logging is the foundation that makes both possible. Transparency under Article 13 and oversight under Article 14 depend on there being a record to be transparent about and to oversee. A firm that treats Article 12 as a box-ticking logging exercise, separate from its transparency and oversight obligations, will find that the three requirements pull against one another. Treated as a single capability, they describe one thing: the ability to capture, retain, and produce a complete account of every decision the system makes.
What good looks like#
A logging capability that satisfies Article 12 in spirit, not merely in letter, has a small number of consistent properties.
It captures decisions at the point they are made, as a single structured record rather than a reconstruction. Each record links the output to its inputs, the model version, and the context that governed the decision. It is written once and not subject to the rotation and sampling that govern operational logs. It is protected against later alteration, because a record that can be edited is a record that cannot be relied upon as evidence. And it is retained for a horizon that satisfies both the AI Act and the sector rules that apply to the firm, with the ability to retrieve any individual decision on demand.
None of this requires firms to abandon their existing observability stack. Operational logging continues to serve its purpose. What the regulation adds is a parallel, deliberate record of decisions, designed for an external observer and a long retention horizon, sitting alongside the logs that engineers use day to day.
The direction is set#
The August 2026 enforcement date for high-risk obligations is not a proposal under consultation. It is a fixed point in a regulation already in force. Firms operating across both UK and EU jurisdictions face a converging picture: the FCA expects evidence of good outcomes through existing frameworks, and the EU AI Act mandates specific technical logging. Both require the same underlying capability, a complete, retrievable, tamper-resistant record of every AI decision.
The firms that will be best placed are those that build this capability deliberately, before a regulator or an auditor asks for a decision they cannot produce. Aegis Trace was built for this requirement. A single integration captures complete decision provenance for every AI output, with tamper-resistant storage, configurable retention, and regulator-ready exports, the evidence infrastructure that Article 12, and the obligations that sit alongside it, point toward.
Prepare for the August 2026 enforcement date.#
Request early access to Aegis Trace and our technical documentation.