Runtime Logs as EU AI Act Evidence: Beyond Record-Keeping

What the EU AI Act says about logs

Regulation (EU) 2024/1689 states that high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. Recital 71 explains the purpose: comprehensible information on how these systems were developed and how they perform throughout their lifetime is essential for traceability, verifying compliance, monitoring operations and post-market monitoring.

Providers must keep the automatically generated logs to the extent they are under the provider's control. The retention period must be appropriate to the intended purpose of the system and at least six months, unless Union or national law provides otherwise, in particular Union law on personal data protection. On a reasoned request, a provider must give a competent authority the information and documentation needed to demonstrate conformity, including access to those logs. Technical documentation must also describe, where relevant, the mechanisms that allow deployers to properly collect, store and interpret the logs.

That last point matters for compliance leaders. The regulatory frame covers whether logs can be interpreted, not only whether they exist. The Act also requires a risk management system that is established, implemented, documented and maintained, which raises the question of how its policies connect to what the system actually did.

On timing, the Commission's Digital Omnibus proposal of 19 November 2025 would set fixed application dates for high-risk rules of 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in products. A provisional agreement on the broader package was reached on 7 May 2026. As of November 2026, audit-readiness timelines should be set with the final text in mind.

Record versus evidence

The distinction below is editorial analysis, not language from the Regulation. The Act requires automatic recording and does not prescribe log fields. Even so, the purposes it names for logs, such as verifying compliance and monitoring operations, imply that someone must be able to read a log and reach a conclusion.

A conventional application or model-output log typically records an input, an output, an identifier and a time. That shows an event happened. It rarely shows what the system was permitted to do, which policy governed that interaction, whether a control fired, or whether a person was asked to approve anything. An auditor testing a risk management claim such as "sensitive data is not sent to external tools" would need to infer the answer from outputs.

Evidence closes that gap by linking a policy to observed behavior. If each record states the policy that applied and the decision taken, the auditor can sample interactions and check that the stated control matches the recorded outcome. If the record is reconstructed afterward from application logs, that link is an assumption, and an assumption is weaker than a test result.

Runtime data elements that make logs testable

The elements below form a practical framework for evaluating logs. They are not legally prescribed fields. Each one answers a question an auditor is likely to ask about a specific interaction or tool call.

• Policy in force: Identifies the rule and version that applied. Supports testing whether documented risk controls were the ones actually operating.
• Enforcement decision: States whether the action was allowed, redacted, blocked, rate limited or escalated. Shows a control was applied, not merely available.
• Action taken: Records what the system did as a result, such as a tool call executed or a field removed. Connects the decision to observed behavior.
• Escalation outcome: Records whether human approval was triggered and what the reviewer decided. Gives evidence for any human oversight design that relies on approval.
• Timestamp: Orders events and ties them to the policy version active at that moment, which matters when policies change over time.
• Scope of interaction or tool call: Defines exactly which interaction, tool or model the decision covered, so sampling and reconciliation are possible.

How enforcement in the execution path produces evidence

Where a control sits determines how trustworthy its record is. A review tool that reads logs after the fact can only describe what happened. A control placed in the execution path makes the decision before the action completes, so the decision and the record come from the same event. The evidence is a by-product of enforcement rather than a separate reconstruction exercise.

Trussed works this way. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, applying allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. That enforcement generates continuous audit-ready evidence mapped to the EU AI Act and other frameworks. The approach has run for more than 18 months in continuous production at a regulated enterprise, and the platform generates over 30 GB of audit evidence per day.

The scope is deliberate. Evidence at the level of individual interactions and tool calls is what an auditor can sample and test. Mapping that evidence to specific obligations remains the compliance team's task, and it still requires judgment about which obligations apply to each system.

Retention, control boundary and data residency

The statutory floor is at least six months, appropriate to the intended purpose and subject to other Union or national law. Retention is therefore a design decision. Document the intended purpose of each high-risk system, set the period from that purpose, and reconcile it with data protection law. Longer retention improves the audit trail but increases the personal data held, so minimizing sensitive content before it is recorded, for example through redaction at runtime, reduces that tension.

The provider's duty to keep logs and give authorities access applies to the extent logs are under its control. If logs sit in the customer's environment, responsibility and accessibility between provider and deployer should be assigned explicitly and written down. A reasoned request from a competent authority is not the moment to decide who can produce the records.

The Act text does not address tamper resistance, access control, data residency or deployment location, so treat these as evidence-integrity criteria rather than legal requirements. Evidence that anyone can edit, or that sits where it cannot lawfully be produced, is hard to defend. Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency, which keeps evidence inside the boundary the organization already controls.