Home / Blog / EU AI Act Article 12
What Article 12 actually requires you to log, and what most agent stacks miss.
The EU AI Act does not say “send application logs to a dashboard.” It requires high-risk AI systems to support automatic event recording across the system lifetime at a level that makes their operation traceable. For an AI agent, that turns into a harder engineering question: can you reconstruct what the system knew, did, and was allowed to use at the moment of a decision?
The legal baseline
Article 12 is a traceability requirement, not a prescribed log schema.
Article 12 applies to high-risk AI systems. It says those systems must technically allow the automatic recording of events over their lifetime. The logging must support traceability appropriate to the system’s purpose and record events relevant to identifying risk or substantial modification, post-market monitoring, and monitoring the system’s operation. The regulation sets more specific minimum fields for certain biometric-identification systems; it does not publish a universal event schema for every agent.
Providers must keep automatically generated Article 12 logs under their control for an appropriate period of at least six months, unless other Union or national law provides otherwise.
Deployers have a parallel at-least-six-month obligation for logs under their control, again subject to other applicable law.
Not every model, workflow, or agent is a high-risk AI system. Classification depends on the system’s purpose and the Act’s categories. Establish scope with qualified counsel before treating any technical checklist as a compliance conclusion.
Current timeline · updated 2026-07-17
The high-risk deadline moved. The architecture problem did not.
On June 29, 2026, the Council gave final approval to the Digital Omnibus amendment. The adopted timetable moves the high-risk rules for standalone systems to December 2, 2027 and the rules for high-risk systems embedded in regulated products to August 2, 2028. The Council said the act would enter into force three days after publication in the Official Journal. Teams should verify the latest consolidated text before relying on a date.
The extra time is valuable only if it is used to make records native to the system. Retrofitting provenance after a model, retrieval layer, policy engine, and tool runner have all shipped independently usually produces a folder of correlated logs, not a reconstructable record.
An implementation interpretation
For an agent, record the decision path, not only the final text.
The following fields are not a verbatim Article 12 checklist. They are an engineering interpretation of what a useful, reviewable agent record needs in order to support the Act’s traceability objective.
Stable event ID; system, tenant, agent, and session IDs; event time; recording time; and a trusted ordering value.
Model and tool versions, system and policy version, retrieval configuration, feature flags, and the deployment or change-set identifier.
Prompt or input reference, retrieved-memory IDs, source lineage, and the validity window for each fact. Sensitive payloads can remain encrypted or off-record while their identifiers and hashes stay in the evidence chain.
Access checks, policy evaluations, blocked or allowed tools, information-barrier scope, human-oversight actions, and the reason codes the control plane produced.
Output reference, tool calls, external actions, errors, retries, overrides, and the link from each effect back to the evidence used to produce it.
Canonical serialization, payload hashes, previous-event hash, key or signature identifier, and export metadata so an evidence package can be verified independently.
The common gap
Observability tells you what ran. Evidence must show what was knowable.
A tracing platform is excellent for latency, failures, and debugging. It does not automatically make an agent’s state reconstructable. If a fact is corrected in November, a March decision record needs to show the version available in March, not today’s version joined onto an old trace. If a user was outside an information barrier, the record needs the access decision that applied at that time, not the current policy.
That is why one timestamp is not enough. The useful model carries both event time, when something was true in the world, and a system-time validity window, when the AI system believed it. Point-in-time reconstruction selects the version valid at the decision timestamp. Without that second timeline, a technically complete log can still tell a historically false story.
A technical shape that survives review
Combine an event ledger, bitemporal state, and subject-level key control.
Write every material inference, memory change, tool action, oversight action, access decision, and system change through one record API.
Hash a deterministic event representation together with the previous record hash. A hash chain does not prevent every attack, but it makes silent alteration or deletion detectable when anchors and keys are controlled properly.
Close the prior system-time validity window when a fact is revised. Reconstruct against an as_of timestamp instead of joining an old decision to current memory.
Keep sensitive content behind narrowly scoped keys, leaving non-identifying integrity metadata in the ledger. Destroying a key can make encrypted content irretrievable while preserving evidence that an event occurred.
Include the selected records, lineage, policy versions, integrity proofs, and verification result. Reviewers should not need access to the production database or screenshots from five tools.
Cryptographic erasure is a technical measure, not an automatic GDPR result. Whether remaining data is anonymous depends on whether a person is no longer identifiable, considering the means reasonably likely to be used. Encryption and pseudonymisation reduce risk but can remain personal data while re-identification remains possible.
The practical test
Ask for one old decision and try to rebuild it.
Choose a production-like agent decision from three months ago. Starting with only its event ID, attempt to recover the exact model and policy versions, the memory records visible at that timestamp, the access decision, the human interventions, the tool effects, and an integrity check. If any step requires today’s database state, an employee’s recollection, or a screenshot, the record layer is not yet doing the work.
A reference implementation
Lians turns the record into infrastructure.
Lians is an open-source system of record for regulated AI: bitemporal memory, point-in-time reconstruction, database-enforced information barriers, a tamper-evident event chain, subject-level encryption, and deterministic evidence exports. It provides technical controls; it is not a certification and cannot determine whether a deployment is legally compliant.
pip install lians-sdk[local]git clone https://github.com/Lians-ai/Lians