An AI audit trail is a system’s automatically generated, tamper-resistant log of its own operation — not a general activity log added after the fact. Under the EU AI Act, high-risk AI systems must generate these logs by design (Article 12) and providers must retain them at least six months (Article 19).
“We have logging” is not the same as an audit trail
Most software has some form of logging — error logs, access logs, request logs. An AI audit trail is a narrower, more specific requirement: it has to be built into the system so events are recorded automatically, over the system’s lifetime, specifically to support three things — detecting when the system may present a risk or has undergone an unplanned substantial modification, supporting post-market monitoring obligations, and enabling operational oversight of how the system is actually being used. A generic application log that happens to capture some AI-related events isn’t the same thing as a logging capability designed, from the start, to answer “can we reconstruct what this system did and why.”
What the EU AI Act actually requires — Article 12 and Article 19, not just “keep logs”
Article 12 (Record-keeping) sets the design requirement: high-risk AI systems must “technically allow for the automatic recording of events (logs) over the lifetime of the system.” For a specific category of high-risk systems — those in Annex III category 1(a) — the Act is explicit about minimum content: the period of each use (start and end date/time), which reference databases the system checked during operation, the input data that produced a match, and identification of the humans who verified the results. Other high-risk categories don’t get this exact list spelled out, but the same underlying principle — traceability appropriate to the system’s intended purpose — applies across the board.
Article 19 (Automatically generated logs) sets the retention requirement: providers of high-risk AI systems must keep the logs generated under Article 12, to the extent those logs are “under their control,” for “a period appropriate to the intended purpose” and at minimum six months, unless another applicable law sets a longer period. The “under their control” qualifier matters in practice: if you’re deploying a vendor’s high-risk AI system, the vendor’s Article 19 obligation doesn’t automatically mean you, the deployer, have access to those logs — that has to be established contractually, not assumed.
What this actually means for what you log, practically
Translated into an actual logging specification, a compliant AI audit trail generally needs to capture, at minimum: when the system was used (start/end timestamps), what inputs it processed, what output or decision it produced, whether and how a human reviewed or overrode that output, and any error or anomaly the system itself detected during that run. The point isn’t logging volume for its own sake — it’s reconstructability: given a specific output the system produced six months ago, can you show exactly what led to it, without relying on someone’s memory of how the system usually behaves.
United States and Canada: no equivalent federal mandate, but the exposure is real
Neither the US nor Canada has a direct federal equivalent to Article 12/19’s logging mandate. That doesn’t mean US and Canadian enterprises are exempt from the underlying expectation — three separate pressures push in the same direction:
- Market reach, not incorporation. Any US or Canadian company deploying an AI system into the EU market, or serving EU users, falls under Article 12/19 regardless of where the company is headquartered — the Act applies by market, not by where it’s incorporated.
- State-level recordkeeping laws are already building the same expectation. NYC Local Law 144 requires bias-audit documentation and public disclosure for automated employment tools (a narrower, HR-specific logging requirement, not a general AI audit-trail mandate), and Colorado’s AI Act imposes risk-assessment documentation obligations on developers and deployers of high-risk systems.
- NIST AI RMF is becoming a procurement baseline. Its “Measure” function is voluntary, but it’s increasingly showing up as a baseline in US enterprise contracts — a vendor without demonstrable logging/measurement practices can lose deals even with no legal mandate forcing it.
Practically, the commercial and legal-discovery cost of poor logging — an incident with no reconstructable record is materially harder and more expensive to investigate and defend — is arguably a bigger driver for US/Canadian companies right now than any specific statute.
How audit-trail expectations compare across frameworks
The EU AI Act is the only one of the three with a hard legal minimum and a specific penalty tied to non-compliance; NIST and ISO 42001 both expect logging as part of a functioning AI management system, but leave the specific retention period to the organization — which means an EU AI Act-compliant six-month floor is a reasonable default even for organizations working primarily against NIST or ISO 42001, since it’s unlikely to fall short of either framework’s expectations.
What this looks like in practice, not just on paper
Per a 2026 technical breakdown of Article 12’s practical implications, a logging capability that satisfies “reconstructability” in an audit needs three properties beyond simply writing events somewhere: the logs have to be tamper-resistant (an editable log undermines its own evidentiary value — if anyone with database access can alter a past entry, the log can’t prove what actually happened), they need to be queryable at the level of an individual decision or output (a log that only supports aggregate statistics, not “show me exactly what happened for this specific case,” doesn’t support the traceability purpose Article 12 describes), and they need an owner who’s accountable for the logging pipeline itself not silently failing — a logging system that quietly stops recording for a week because of an unrelated infrastructure change is a gap that often isn’t discovered until an audit or incident response actually needs the missing data.
Retention is a floor, not a target
Six months is the EU AI Act’s stated minimum under Article 19 — not a safe target to build toward. Two things commonly push the real requirement higher: sector-specific law (GDPR-adjacent retention rules apply when logs contain personal data, and financial services and healthcare regulation frequently sets its own, longer retention floors) and the system’s own intended purpose, since the Act ties “appropriate” retention to how long a system is actually expected to operate and be scrutinized. Treating six months as sufficient by default, without checking whether a sector-specific rule or the system’s own risk profile requires longer, is a common and avoidable compliance gap.
Key takeaways
An AI audit trail is a designed-in logging capability tied to specific regulatory purposes (risk detection, post-market monitoring, operational oversight) — not general application logging retrofitted after the fact.
EU AI Act Article 12 sets the design requirement (automatic recording of events over the system’s lifetime); Article 19 sets the retention floor (minimum six months, “under the provider’s control”).
Six months is a floor, not a target — sector-specific rules and the system’s actual intended purpose frequently push the real retention requirement higher.
Next step: if you’re trying to work out whether your current AI systems’ logging actually meets Article 12/19’s design and retention requirements, see how Fruggr approaches audit-ready compliance reporting on the AI compliance reporting overview.
FAQ
Article 19 applies to providers of high-risk AI systems — the entity that develops or places the system on the market. If you’re a deployer using someone else’s high-risk AI system, the provider’s Article 19 obligation doesn’t automatically give you access to those logs; that access needs to be established in your contract with the vendor, not assumed to exist.
It’s the EU AI Act’s stated minimum, not a recommended target. If the logs contain personal data, GDPR-adjacent retention considerations can extend that; sector-specific regulation (financial services, healthcare) frequently sets its own longer floor. Check both before defaulting to six months.
The Act is explicit only for a specific subset of high-risk systems (Annex III category 1(a)): usage period, databases checked, matching input data, and human verifier identity. For other high-risk systems, the requirement is “traceability appropriate to the system’s intended purpose” — less prescriptive, but not optional; when in doubt, log more granular detail rather than less.
Some tools in that category do generate and manage this kind of evidence as one of several functions, but the underlying logging capability has to exist in the AI system itself first — a compliance tool can organize and retain evidence, but it can’t retroactively create a record of events the AI system never captured in the first place.
This article was drafted with AI assistance and reviewed by our editorial team before publishing.