EU AI Act Article 12: Logging Requirements Explained

What is EU AI Act Article 12?

Article 12 of the EU AI Act is the record-keeping obligation for high-risk AI systems. It sits inside Chapter III, Section 2 — the section that defines the technical requirements a high-risk system must meet before it can be placed on the EU market. In plain terms, Article 12 says a high-risk AI system has to be built so that it keeps an automatic, machine-generated record of what it did, for as long as it is in service, so that its behaviour can be reconstructed and reviewed later.

The obligation only attaches to systems classified as high-risk. Under the EU AI Act, high-risk means either an AI system used as a safety component of a regulated product, or a system that falls into one of the eight categories listed in Annex III. Those categories are biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services (which explicitly includes credit scoring and insurance); law enforcement; migration, asylum, and border control; and the administration of justice and democratic processes. If your system is not high-risk, Article 12 does not bind you — though logging is still sensible engineering.

Enforcement matters here. Article 12 is not guidance; it is a hard requirement backed by the penalty regime in Article 99. The EU AI Act entered into force on 1 August 2024 and applies in stages. Under the EU AI Act as enacted, high-risk (Annex III) obligations apply from 2 August 2026 — though a Digital Omnibus reform provisionally agreed in May 2026 is expected to defer this to 2 December 2027 once formally adopted (not yet adopted as of June 2026). Prohibited practices became enforceable from 2 February 2025, and rules for general-purpose AI, governance, and penalties from 2 August 2025. If you build or deploy a high-risk system, Article 12 is one of the obligations you are building toward now.

What Article 12 actually requires

The article has three operative paragraphs. Read together, they move from a general logging duty to a specific purpose for those logs, and then to extra fields for biometric systems.

Article 12(1) — automatic logging over the lifetime

High-risk AI systems must technically allow for the automatic recording of events (logs) over the lifetime of the system. Two words carry weight. "Automatic" means the recording cannot depend on someone remembering to switch it on — it is a property of the system, designed in. "Lifetime" means logging is not a launch-week formality; it runs for as long as the system operates in the field.

Article 12(2) — what the logs must enable

The logging capability must, at minimum, allow the system to do three things:

• Identify risk situations and substantial modifications — the logs must let you spot situations where the system may present a risk, or where it has been materially changed.
• Support post-market monitoring— the logs feed the provider's ongoing obligation to watch how the system performs once it is live.
• Support deployer monitoring — the logs must let the organisation actually operating the system monitor it during use.

This is the clause that separates Article 12 from generic logging: the logs exist to serve oversight, not just operations.

Article 12(3) — extra fields for biometric systems

High-risk biometric systems carry an additional, explicit list. For those systems the logs must at least record:

• the period of each use — the start date and time and end date and time;
• the reference database against which input data has been checked;
• the input data for which the search led to a match;
• the identity of the natural persons involved in verifying the results.

These four are the only system-specific log fields the article names. Outside biometrics, Article 12 deliberately does not prescribe a fixed schema — it sets the purpose and leaves the exact fields to the provider, scaled to the intended purpose of the system.

Article 19 — how long you keep the logs

Logging is pointless if the records vanish. Article 19 ties the loop closed: providers must keep the logs generated under Article 12 (those under their control) for at least six months, unless other applicable Union or national law requires otherwise. Treat six months as the legal floor; sector rules in finance, healthcare, or public administration routinely demand far longer.

What Article 12 does NOT require

A lot of the confusion around Article 12 comes from reading obligations into it that are not there. Being precise about scope keeps you from over-engineering — and from collecting data you should not.

• It does not require logging every prompt and output verbatim. The standard is logging sufficient to identify risk situations and substantial modifications and to support monitoring — not a complete transcript of all model traffic.
• It does not apply to non-high-risk AI. A general productivity chatbot or a low-stakes recommendation feature is outside Article 12 unless it falls into an Annex III category or is a safety component of a regulated product.
• It does not mandate a specific log format, vendor, or "certification." There is no official "Article 12 certified" stamp. You demonstrate compliance through your own technical documentation, conformity assessment, and the logs themselves.
• It does not override data-protection law.Article 12 must be read together with the GDPR. Logging more personal data than necessary to meet the article's purpose can create a separate legal problem, so data minimisation still applies.
• It does not, by itself, require real-time monitoring or alerting. The article is about recording events so they can be reviewed; live alerting is an operational choice layered on top, not a literal Article 12 demand.

How Article 12 differs from standard observability logging

Most engineering teams already log. The trap is assuming that existing observability stack — the one that tracks latency, error rates, and uptime — already satisfies Article 12. It usually does not, because the two kinds of logging answer different questions. Observability logging answers "is the system healthy?". Article 12 logging answers "can we reconstruct and justify what this system decided, and spot when it became risky or changed?". The difference is intent and structure, not raw volume of log lines.

Concretely, observability logs are typically transient (rotated out after days), optimised for engineers, and centred on metrics. Article 12 logs must be retained for a defined period, legible to non-engineers including auditors and regulators, and structured around risk situations and substantial modifications. A 99.9% uptime dashboard tells a regulator nothing about whether a credit-scoring model started behaving differently after a model update. Article 12 logging is built to capture exactly that.

This is the same gap covered in our guide to AI audit trail requirements: raw logs are the input, but the deliverable is an organised, tamper-evident trail a third party can actually follow.

Step-by-step: implementing Article 12-compliant logging

Here is a practical sequence to get from "we have some logs" to logging that maps to Article 12. The order matters — scope and classification first, schema and retention next, verification last.

1. Confirm the system is in scope. Check whether your AI system is high-risk: is it a safety component of a regulated product, or does it fall under one of the eight Annex III categories? If neither, Article 12 does not apply. If you are unsure, work through our guide to high-risk AI systems first.
2. Make logging automatic and lifetime-wide.Move logging out of optional configuration and into the system's default behaviour, so it cannot be silently disabled and so it runs for the whole operational life of the system, not just in testing.
3. Design the log schema around Article 12(2). For each event, capture enough to identify risk situations and substantial modifications and to support post-market and deployer monitoring: a timestamp, the system and model version in effect, the operation performed, the inputs (or a privacy-respecting reference to them), the output or decision, and any human review or override.
4. Add the biometric fields if applicable. If the system is a high-risk biometric system, extend the schema with the four Article 12(3) fields: usage period (start and end), the reference database checked, the matched input data, and the identity of the people verifying results.
5. Set retention to satisfy Article 19. Retain logs for at least six months, and longer where sector law requires it. Define the retention period explicitly and document the legal basis for it.
6. Make the logs tamper-evident. Logs that can be silently edited prove nothing. Use append-only storage, hashing, or signing so that any alteration is detectable — this is what turns a log file into evidence.
7. Apply data minimisation.Cross-check the schema against GDPR: log what the article's purpose requires and no more, pseudonymising or referencing personal data where full capture is not necessary.
8. Wire logs into monitoring and incident response. Connect the logs to your post-market monitoring process so risk situations and substantial modifications are actually reviewed, not just recorded.
9. Test reconstruction. Periodically pick a past decision and try to reconstruct it end-to-end from the logs alone. If you cannot, the logs are incomplete — fix the schema before an auditor does it for you.
10. Document everything in your technical file. Record the logging design, retention policy, and verification approach in the technical documentation that supports your conformity assessment. The logs prove behaviour; the documentation proves you meant to.

Penalties for non-compliance

Article 12 sits within the operational obligations on high-risk AI providers, and those obligations are enforced through the fine bands in Article 99 of the EU AI Act. The fines are tiered by how serious the breach is, and each band is "whichever is higher" of a fixed euro amount or a percentage of global annual turnover. For SMEs and start-ups, the fine is instead the lower of the fixed amount and the percentage.

Because logging is a precondition for several other obligations — post-market monitoring, incident reporting, and cooperation with authorities all depend on having usable logs — a weak Article 12 implementation tends to surface as multiple findings at once, not a single isolated gap. That compounding effect is why teams treat logging as foundational rather than a box to tick late.

Turning Article 12 from a checklist into provable evidence

The hardest part of Article 12 is not writing log lines — it is proving, months or years later, that the logs are complete, unaltered, and actually map to the regulation. That is the gap verifiable-evidence tooling closes: capturing AI work as automatic, retained, tamper-evident records, and structuring them around risk and modification so a reviewer can follow the trail without taking your word for it.

AuditProof maps your workflow to Article 12 in 90 days — turning your existing AI processes into Article 12-oriented logging and audit-ready evidence. If you first need to know whether you are even in scope and what your exposure looks like, start with the EU AI Act self-assessment calculator to classify your system before you build.