Article 12 of the EU AI Act requires high-risk AI systems to support automatic event logging throughout the system lifetime. The logs must make the system traceable at a level appropriate to its intended purpose and support risk detection, post-market monitoring, and deployer monitoring. Article 19 then assigns providers a retention duty for automatically generated logs under their control. For an AI agent, a defensible implementation connects the run, agent and Release, policy decisions, tool calls, human decisions, outcomes, and integrity evidence. This guide separates the statutory text from the engineering specification used to produce reviewable records. It provides practical orientation and does not provide legal advice.
What Article 12 and Article 19 require
Article 12 sits in Chapter III Section 2, the requirements for high-risk AI systems. Its reach depends on the system classification and intended purpose. A customer-service agent or internal assistant does not enter Article 12 solely because it uses an AI model or can call tools. Start with the EU AI Act requirements baseline and document the classification decision.
Regulation (EU) 2026/1744 changed the application dates for these high-risk provisions. Chapter III Sections 1 to 3 apply from 2 December 2027 for systems classified under Article 6(2) and Annex III, and from 2 August 2028 for product systems classified under Article 6(1) and Annex I. The later dates create implementation time. They leave the Article 12 and Article 19 control design intact.
| Source | Requirement in the regulation | Operational specification | Evidence test |
|---|---|---|---|
| Article 12(1) | The high-risk AI system technically supports automatic event recording over its lifetime. | Emit records from the execution path for every governed run and consequential action. Avoid a design that depends on a person assembling the record after an event. | Run a representative Process and reconcile the execution population to the records created automatically. |
| Article 12(2)(a) | Logs capture events relevant to identifying risk under Article 79(1) or a substantial modification. | Record failures, policy blocks and warnings, anomalous tool access, overrides, Release changes, unexpected outputs, and resulting effects with stable identifiers. | Trigger each defined risk signal and confirm the record identifies the affected run, version, event, time, and outcome. |
| Article 12(2)(b) | Logs facilitate the Article 72 post-market monitoring system. | Use event fields that support population queries, trend analysis, incident correlation, and links to the provider monitoring plan. | Reproduce one monitoring metric from source records and trace an exception into the post-market monitoring plan. |
| Article 12(2)(c) | Logs support deployer monitoring under Article 26(5). | Expose the operational state, instructions-for-use context, risk signal, provider notification reference, suspension event, and serious-incident reference where applicable. | Follow one simulated risk from detection through suspension or disposition and verify the provider and authority notification references. |
| Article 12(3) | For remote biometric identification systems covered by Annex III point 1(a), logs include each use period, the reference database, matched input data, and the people who verified results under Article 14(5). | Create dedicated fields for the minimum biometric record. Apply access controls and data-protection rules to the sensitive data. | Select a use and verify start and end time, database reference, matched input, and verifier identities are present and authorized. |
| Article 19(1) | A provider keeps Article 12 logs under its control for a period appropriate to the intended purpose and at least six months, unless other applicable law provides otherwise. | Assign a retention class, source, purpose, minimum period, legal-hold behavior, access rule, and verified deletion path to each provider-controlled record. | Inspect storage policy, prove covered records remain available throughout the required six-month period, then test hold and authorized deletion after the configured expiry. |
| Article 26(6) | A deployer applies the same minimum six-month rule to automatically generated logs under its control, subject to other applicable law. | Define the provider-deployer handoff: which party controls each record, how the deployer collects and interprets it, and how contracts preserve access. | Trace one production record from generation to the deployer-controlled store and confirm retrieval, retention, and ownership. |
A concrete AI agent audit-trail specification
Article 12 states the purposes of logging and gives a specific minimum field list for the remote biometric identification systems in Article 12(3). For other high-risk systems, the provider defines a field set that makes the system traceable for its intended purpose. The specification below is a defensible starting point for an agent that can retrieve data, make policy-governed decisions, request human review, and call tools.
Capture references or hashes where a full payload would conflict with data minimisation, confidentiality, or security requirements. A useful record keeps the meaning of the event and a controlled route to the underlying evidence.
| Event family | Fields to capture | Control purpose | Acceptance test |
|---|---|---|---|
| Execution identity | Tenant, execution and correlation IDs; agent ID; Release ID, version, and hash; Process ID and version; environment; initiating principal; on-behalf-of subject; start and end timestamps | Define the system, version, authority, and period involved in one run. | Join every event in a sampled run to one identity record without relying on timestamps alone. |
| Input and retrieval | Input reference or protected payload; source and record references; retrieval query or hash; model and prompt-template version; redaction state; event time | Show what information entered the run and which version interpreted it. | Reconstruct the approved input set and prove protected fields remain access-controlled. |
| Tool request | Tool name; call and gate IDs; destination; arguments or argument hash; requested authority; idempotency key; request time | Identify the consequential action proposed by the agent before an external effect occurs. | Match the request to its policy result and prove duplicate delivery cannot create an unexplained second effect. |
| Policy decision | Decision ID; gate type; allow, warn, require_approval, or block outcome; policy ID, version, and pack hash; matched rule IDs; reason codes; decision time | Show which control governed the action and the exact version evaluated. | Re-evaluate a pinned sample with the recorded facts and explain any difference as a version change. |
| Human decision | Decision Request ID; required role; reviewer identity and authority; approve, reject, or escalate outcome; rationale; acknowledgement; request and decision times | Connect material judgment to an accountable person and the action held for review. | Prove the reviewer had authority at decision time and that the tool request stayed paused until resolution. |
| Tool outcome and business effect | Status; result reference or hash; error; output policy decision; before and after state references; downstream transaction ID; completion time | Distinguish a proposal from an action that reached the target system. | Reconcile the record to the downstream system and account for success, failure, block, cancellation, and retry. |
| Monitoring and incident signal | Signal type; severity; affected execution and Release; threshold or detector version; disposition; owner; notification and incident references | Support Article 72 monitoring and the Article 26(5) operating response. | Reproduce the signal from source records and follow it to a documented disposition. |
| Integrity and retention | Record hash; previous-record hash where used; signature and key ID where used; ledger or manifest reference; retention class; expiry; hold state; deletion event | Detect later changes and prove the record stayed available for its approved period. | Change one exported byte and require verification to fail; test retention, hold, and deletion controls separately. |
Retention is a provider and deployer control
Article 19(1) assigns providers the duty to keep automatically generated Article 12 logs under their control. Article 26(6) gives deployers the equivalent duty for logs under their control. Both use the same structure: a period appropriate to the intended purpose, a minimum of six months, and an exception where applicable Union or national law provides another rule. Financial institutions keep these logs within the documentation maintained under the relevant Union financial-services law.
The six-month period is a floor for the logs covered by these provisions. Article 18 separately requires providers to keep specified technical and conformity documentation for ten years. These periods cover different records. Privacy, employment, sector, litigation-hold, and national rules can change the valid period or the data that may be retained.
Build a retention register before choosing a storage TTL. For each evidence class, record its legal or approved business source, purpose, responsible party, system of record, minimum and maximum period, trigger date, access roles, legal-hold rule, deletion method, and test evidence. The audit-log retention policy template provides a working structure.
- Allocate control: name the provider-controlled and deployer-controlled records, including copies created by an observability vendor or runtime operator.
- Align layers: the trace store, evidence ledger, exported bundle, index, backup, and encryption key lifecycle need compatible periods.
- Protect content: minimise personal data, separate sensitive payloads from broadly queryable metadata, and enforce purpose-bound access.
- Test retrieval: a retained record has value when an authorized reviewer can locate, interpret, and export it inside the required service level.
- Test expiry: prove the system honors a legal hold, records authorized deletion, and removes every governed copy when the approved period ends.
Tamper-evidence and replay are assurance controls
Article 12 names automatic recording and traceability. It prescribes no cryptographic mechanism and no replay endpoint. Tamper-evidence and replay are implementation controls that help a provider demonstrate that the record is complete enough to use and has remained unchanged.
Use replay to mean reconstruction of the recorded control path. Re-executing a model or external tool can produce a different output or repeat a side effect. A safe replay reads the stored sequence, versions, policy facts, human decisions, and outcome references. A separate policy simulation may re-evaluate recorded facts against a pinned policy version without dispatching the action.
| Test | Expected result | Failure signal |
|---|---|---|
| Population reconciliation | Every in-scope run and consequential action has a record, including routine allows, blocks, failures, and cancellations. | Execution counts exceed record counts or unmatched records have no source execution. |
| Causal ordering | The policy decision precedes the governed action; a required human decision precedes release; the outcome follows execution. | A side effect has no earlier control record or timestamps cannot establish sequence. |
| Pinned context | The record resolves the Agent and model Release, Process version, policy version, identities, and authority active at the event time. | A reviewer can see the current configuration only or must infer which version ran. |
| Outcome reconciliation | The tool outcome and business effect match the downstream source, including retry and idempotency behavior. | The audit trail says completed while the target has no matching transaction, or duplicate effects lack separate causes. |
| Integrity verification | Hashes, signatures, chain links, ledger proofs, and manifest checks verify where configured; a controlled mutation turns verification red. | An edited artifact still verifies or the verifier cannot identify the affected file or record. |
| Safe reconstruction | A reviewer can read the complete sequence without re-running a consequential side effect. | The only reconstruction path dispatches the original tool call or depends on an unavailable model response. |
How KLA runtime evidence maps to the specification
KLA creates a Lineage Record for a governed run and uses stable execution and tenant identifiers to connect runtime events. Execution spans can carry the Process version and hash, Agent Release identifiers, environment, initiating principal, on-behalf-of subject, and caller client identity recorded for the run. Workflow spans record node outcomes, policy outcomes, policy IDs and rules, Decision Requests, reviewer identities, timestamps, and errors.
The KLA governance gateway evaluates tool-input and tool-output gates through the KLA Policy Engine when operators enable KLA_GOVERNANCE_GATEWAY for an environment. The checked-in production execution-worker configuration does not currently enable this path. Where enabled, a gate result uses the four outcomes allow, warn, require_approval, and block. Decision receipts include the execution, gate, tool, policy version, policy-pack hash, reason codes, Decision Request, trace, and output hash where applicable. The gateway seals the input-gate receipt before it executes the governed tool and seals the output-gate receipt before it returns or holds the result. An evidence-write failure stops the gate from advancing.
| Control need | KLA building block | Evidence produced | Boundary to verify |
|---|---|---|---|
| Stable run identity | Agents, Releases, Processes, and Lineage Records | Execution, tenant, Process version and hash, Agent Release, environment, principal, and correlation identifiers | Confirm every integration propagates the identifiers and that optional identity fields are present for the Process under review. |
| Automatic event sequence | KLA Runtime and OpenTelemetry execution spans | Run, node, policy, approval, error, timing, and outcome events ordered inside one Lineage Record | Reconcile the execution population and confirm the selected tools emit the input, result, and downstream-effect references the intended purpose needs. |
| Policy and tool control | Environment-enabled KLA governance gateway | Gate type, policy version, decision, reasons, Decision Request, argument hash, output hash, and idempotency state; matched rule IDs when the evaluated require_approval decision supplies matched rules | Confirm the gateway is enabled in the environment under review. Test all four outcomes, optional matched-rule evidence, policy-service failure, changed arguments after approval, retries, and cancellation. |
| Human decision | Decision Desk and durable approval records | Required role, reviewer identity, decision, rationale, timestamps, policy context, and correlated execution | Test reviewer authority, maker-checker rules where configured, and the complete pause-to-release sequence. |
| Tamper-evident record | Append-only evidence ledger and governance receipts | Verified ledger writes; Ed25519 signatures and hash-chain links when receipt signing is enabled | Treat signing state as an observed deployment fact. Alert on degraded signing and run a controlled tamper test. |
| Portable review package | Evidence Room and Sealed Evidence Bundles | Selected lineage, policy, approval, and ledger records with a manifest, hashes, Merkle inclusion data, and signatures for offline verification | Confirm the export population, redaction profile, verifier result, key availability, and chain-of-custody record. |
| Retention | Evidence Factory job retention and bundle-storage configuration | Export-job retention metadata, expiry, and configured bundle-storage retention | Reconcile these export controls with the retention of source Lineage Records and ledger records. Set and test the period required for the classified system and sector. Product capability alone does not establish the approved legal period. |
Implementation checklist
Turn the specification into a release gate for each high-risk AI system. Keep the classification record, intended purpose, event schema, retention register, privacy review, tests, and monitoring plan together in the Annex IV documentation set.
- Name the provider, deployer, intended purpose, high-risk basis, system boundary, Agent and model Releases, and each party that controls a copy of the logs.
- Define the in-scope execution population and the consequential actions that need complete tool, policy, human-decision, and outcome records.
- Publish a versioned event schema with required fields, data classifications, redaction rules, identifiers, allowed event order, and failure behavior.
- Make record creation automatic in the execution path and fail closed where a missing control receipt would leave a consequential action ungoverned.
- Reconcile executions to records and test ordinary allows, warnings, required approvals, blocks, errors, retries, cancellations, and policy-service failure.
- Set provider and deployer retention from the approved register, with a minimum six-month test where Article 19 or Article 26(6) applies.
- Run safe reconstruction, outcome reconciliation, access-control, legal-hold, deletion, export, and one-byte tamper tests.
- Feed defined events into the Article 72 monitoring plan and connect signals to owners, dispositions, incidents, and corrective actions.
Frequently Asked Questions
Does EU AI Act Article 12 apply to every AI agent?
Article 12 applies to high-risk AI systems. An agent first needs a documented classification and intended purpose. Organizations can use the same logging controls for lower-risk agents as a governance choice.
What events must an AI agent log under Article 12?
Article 12 requires events relevant to risk detection, substantial modification, post-market monitoring, and deployer monitoring. It gives an explicit minimum field list for the remote biometric identification systems in Article 12(3). Other systems need a purpose-appropriate schema. For a tool-using agent, execution identity, versions, inputs or references, tool requests, policy results, human decisions, outcomes, errors, and timestamps form a defensible baseline.
How long must Article 12 logs be kept?
Article 19(1) requires providers to keep automatically generated logs under their control for a period appropriate to the intended purpose and at least six months, unless applicable Union or national law provides otherwise. Article 26(6) gives deployers the same rule for logs under their control. Separate records and sector rules can carry different periods.
Does Article 12 require tamper-evident logs?
The article requires automatic logging and traceability and names no cryptographic mechanism. Append-only storage, hashes, signatures, and independent verification are assurance controls that help detect changes and support a defensible evidence process.
Does Article 12 require replay?
The article contains no express replay requirement. Safe reconstruction is a useful acceptance test: a reviewer should be able to read the recorded sequence, versions, decisions, and outcomes without re-running a model or repeating a side effect.
Can ordinary application logs satisfy the requirement?
They can contribute when they are automatic, complete for the intended purpose, correlated across the system, interpretable, access-controlled, retained for the approved period, and available for monitoring. Service-specific debug messages often lack policy versions, human authority, business outcomes, and population reconciliation.
How does KLA support an Article 12 logging design?
KLA connects runtime spans, policy outcomes, tool gates, Decision Requests, and execution outcomes in Lineage Records. Evidence Room exports selected records with integrity metadata for offline verification. The provider and deployer still own classification, field sufficiency, retention, privacy, monitoring, and the final compliance assessment.
Key Takeaways
A useful Article 12 implementation starts with classification and intended purpose, then records every in-scope run and consequential action automatically. Article 19 and Article 26(6) turn retention into an owned control. A versioned event schema, stable identities, policy and human-decision context, downstream outcome references, population reconciliation, tamper tests, and safe reconstruction make those logs usable for monitoring and review. Use the AI agent audit-trail guide for the broader evidence architecture, the Annex IV documentation guide for the technical file, and the post-market monitoring plan for the operating loop.