EU AI Act Articles 12 and 19: A Practical Guide to Logging and Record-Keeping for High-Risk AI

When something goes wrong with a high-risk AI system, the first question from a regulator, customer or court is "what did it do, and when?" Articles 12 and 19 of the EU AI Act exist to make sure that question has an answer. This guide explains what they require and how to turn the legal text into an engineering plan.

Article 12: the system must be able to log

Article 12 requires high-risk AI systems to technically allow the automatic recording of events (logs) over the lifetime of the system. The purpose of those logs is traceability: they should make it possible to identify situations where the system may present a risk or has been substantially modified, to support post-market monitoring under Article 72, and to let deployers monitor operation under Article 26. Remote biometric identification systems carry additional, more specific logging content.

The key design point is that logging is a capability of the product, not an afterthought of the customer's IT team. If your system cannot generate usable logs, it does not meet Article 12, whoever runs it.

Article 19: keep what you generate

Article 19 covers retention. According to the text of Article 19:

• Providers must keep the automatically generated logs "to the extent such logs are under their control".
• The retention period must suit the intended purpose of the system and be at least six months^[1], unless other Union or national law, in particular data protection law, provides otherwise.
• Providers that are financial institutions subject to internal governance requirements under Union financial services law keep the logs as part of the documentation already required by that law.

Deployers have a parallel duty in Article 26 to keep the logs under their control for at least six months. See our Article 26 deployer guide.

When does it apply?

Under Article 113 as amended by the Digital Omnibus (Regulation (EU) 2026/1744), these obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Systems must be designed with logging from the start, so engineering work needs to land well before those dates. The wider timeline is in our implementation status post.

What to log

The Act does not give a field-by-field schema, so you decide, guided by the purposes in Article 12. A defensible baseline for most systems:

• Identity and version: which model, configuration and software version produced each output.
• Input reference: a pointer to or hash of the input, not necessarily the raw input.
• Output and confidence: the decision, score or content produced.
• Human oversight events: who reviewed, overrode or approved, and when (links to Article 14).
• Operational events: errors, fallbacks, guardrail triggers, drift alerts and configuration changes.
• Time and sequence: trustworthy timestamps and ordering.

The GDPR tension

Logs often contain personal data, and the AI Act says its retention rule yields to data protection law. That creates a real tension between "keep at least six months" and data minimisation. Practical ways through: log identifiers and hashes rather than raw personal data, separate access-controlled stores for sensitive fields, documented retention schedules per purpose, and deletion once the retention purpose lapses. Our AI Act and GDPR dual compliance guide covers the interplay.

Integrity, access and location

Logs are only useful as evidence if they cannot be quietly rewritten. Use append-only or tamper-evident storage, restrict write access, and record who reads them. Also consider where logs are stored: if they sit with a non-EU cloud provider, foreign-law access to them can conflict with your confidentiality and data protection duties. Decide this deliberately rather than by default.

How logs feed other obligations

• Serious incident reporting under Article 73 depends on being able to reconstruct what happened; see Articles 72 and 73.
• Technical documentation (Annex IV) must describe the logging capability; see Article 11.
• Accuracy and robustness monitoring under Article 15 needs the same telemetry.

Engineer's checklist

1. Define the events that matter for your intended purpose and risk analysis.
2. Build logging into the product, on by default, not as an optional plugin.
3. Set a retention period of at least six months, justified in writing, and reconcile it with GDPR.
4. Make logs tamper-evident and access-controlled.
5. Give deployers a way to export the logs under their control.
6. Test that you can reconstruct a single decision end to end from the logs alone.
7. Document all of it in your technical file.

This article is general information, not legal advice.