Logs and Traceability in High-Risk AI Systems

What logs are in an AI system

A log is a record of events generated while a system operates. It may capture date, time, user, system, version, operation, input, output, error and human intervention.

Logs create user → input → model → output → human review → decision. Traceability emerges when records can be linked coherently in a high-risk AI system.

What Article 12 of the AI Act requires

Article 12 requires high-risk AI systems to technically allow automatic event recording throughout their lifetime, with traceability appropriate to the intended purpose.

Logging capabilities should record events relevant to risk situations, possible substantial modification, post-market monitoring and oversight of system operation.

Logging is part of design and connects with AI Act technical documentation. It should not be added only after an incident.

What traceability is for

Traceability reconstructs what happened, when, with which version and data, who intervened, what output arose and what decision followed. It supports investigation, error review, bias analysis, control testing, audit, performance monitoring and AI evidence.

Which events should be logged

The AI Act does not prescribe one universal list. Logging should reflect purpose, risk, architecture and context.

Relevant events may include use sessions, users, versions, inputs, outputs, errors, exceptions, controls, decisions, changes and human intervention. The aim is relevant data, not unlimited collection, aligned with AI risk management.

Identity, date, time and version

A record may include a timestamp, system identifier, version, model, configuration, user or role and environment. Without version information, incident reconstruction can be unreliable, especially in frequently changing systems.

Inputs, outputs and decisions

Some systems need to link data received → output generated, but complete inputs and outputs are not always necessary or appropriate.

Purpose, risk, privacy, volume and sensitivity matter. Identifiers, hashes, references, metadata or partial records may support proportionate traceability and data minimisation.

Human oversight and overrides

Logs can show review, approval, rejection, override, escalation, stopping and reasons: output → review → override → final decision.

This demonstrates that human oversight operates in practice and helps analyse recurring reversals.

Errors, exceptions and incidents

Logs help detect errors, failures, anomalies, exceptions, interruptions and degradation. They can reconstruct what preceded an incident, which version ran, who was active and which control failed.

Logs and post-market monitoring

Article 12 expressly links logs to post-market monitoring. They can reveal rising error rates, degradation, behavioural change, unexpected patterns and control failures, providing a structured monitoring data source.

How to design a logging strategy

Step 1. Define purpose

State why logs are needed.

Step 2. Identify risks

Decide what must be reconstructable.

Step 3. Define events

Specify what will be recorded.

Step 4. Define metadata

Include time, system, version and user where relevant.

Step 5. Define access

Decide who may inspect records.

Step 6. Define protection

Prevent alteration, loss and unauthorised access.

Step 7. Define retention

Set an appropriate period.

Step 8. Integrate monitoring

Identify which indicators use log data.

Step 9. Test

Select an operation and ask: can we reconstruct it? Repeat after material changes through AI system change management.

How to use logs to demonstrate traceability

Logs become valuable when linked across system → version → input → output → control → oversight → decision → evidence.

Not every process needs equal granularity, but this connects technical behaviour with governance. A stable practical AI register helps maintain those relationships.

How long logs should be retained

Article 19 creates retention duties for providers of high-risk AI systems for automatically generated logs under their control. The period should suit the intended purpose and, as a general rule, be at least six months.

Deployers must likewise retain automatically generated logs under their control for an appropriate period and generally at least six months.

Other Union or national law may require a different duration, particularly data protection law. Six months is a general minimum, not an absolute rule detached from other legislation.

Logs, privacy and data minimisation

More logging does not automatically mean better governance. Records may contain personal, sensitive or confidential information.

The strategy should address minimisation, purpose, access, security, retention and deletion. Traceability should be sufficient, not unlimited.

How to integrate logs with evidence and audit

Logs may demonstrate actual use, review, intervention, versions, control execution, incidents and escalation. They support audits, investigations, internal reviews and monitoring.

They do not replace policies, assessments, decisions, contracts, technical documentation or training. These sources should remain coherent within an AI governance framework.

Common mistakes

Logging too much

It creates volume without value.

Logging too little

It prevents decisions from being reconstructed.

Failing to record versions

Change investigations become unreliable.

Failing to protect logs

Records require integrity and access controls.

Disconnecting logs from human oversight

Decision traceability is lost.

Retaining logs indefinitely

This may create unnecessary risk.

Never reviewing records

Logs nobody uses provide little value.

Confusing logs with technical documentation

They are connected, but distinct.

Traceability turns a decision into a verifiable story

An organisation should be able to explain what happened, when, with which version and data, what output arose, who intervened and what decision followed.

Logs connect event → system → decision → evidence → accountability. The goal is not to log everything, but to reconstruct what matters.

References

• Regulation (EU) 2024/1689 — Artificial Intelligence Act.
• Article 12 — Record-keeping.
• Article 19 — Automatically generated logs.
• Article 26 — Obligations of deployers of high-risk AI systems.
• Article 72 — Post-market monitoring by providers and post-market monitoring plan.
• Annex IV — Technical documentation.