EU AI Act Article 12: Logging and Record-Keeping

Article 12 of the EU AI Act requires every high-risk AI system to be technically capable of recording its own events for its whole lifetime, yet many teams read it as "keep some application logs" and only discover at audit time that their logs cannot answer the questions the Act asks. The article is short: three paragraphs that set a design requirement on the system, three purposes the logs must serve, and a minimum record for remote biometric identification. The retention duties sit elsewhere, in Article 19 for providers and Article 26(6) for deployers, and the access duty in Article 21. This guide reads Article 12 together with those provisions and turns them into an event design, a retention and access model, tests and evidence. It is written for providers engineering high-risk systems, deployers operating them, and the security, privacy and audit teams who will hold the logs. For the wider regime start with the EU AI Act High-Risk AI Systems Guide; for agent-specific audit records see the AI Agent Audit Trails for Regulators Guide.

Key takeaways

Article 12 is a capability requirement on the system. Article 12(1) requires high-risk AI systems to technically allow the automatic recording of events (logs) over the lifetime of the system, so logging has to be designed in by the provider, not bolted on by each deployer.
The logs must serve three named purposes. Article 12(2) ties logging to identifying risk situations under Article 79(1) or substantial modifications, to post-market monitoring under Article 72, and to the deployer's operational monitoring under Article 26(5).
Remote biometric identification has a fixed minimum. For Annex III point 1(a) systems, Article 12(3) requires at least the period of each use, the reference database checked, the input data that led to a match, and the people who verified the result under Article 14(5).
Retention is "at least six months", split by control. Providers (Article 19(1)) and deployers (Article 26(6)) each keep the logs under their control for a period appropriate to the intended purpose, at least six months, unless Union or national law, in particular data protection law, provides otherwise.
Logs must be producible and trustworthy. Article 21(2) obliges providers to give a competent authority access to the logs on a reasoned request, so integrity, time accuracy and retrieval need the same engineering as the events themselves.

What Article 12 requires, paragraph by paragraph

The table paraphrases Article 12 of Regulation (EU) 2024/1689 as shown on the European Commission's AI Act Service Desk, checked on 14 November 2026. The Service Desk text is based on the EUR-Lex consolidated version as at 27 July 2026 and marks passages changed by the Digital Omnibus on AI; Article 12, Article 19 and Article 26(5) and (6) carried no such marker when checked. Under Article 113(c) as amended, the high-risk requirements apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Track any further changes in the EU AI Act Implementation Timeline Tracker.

Provision	What it requires	Who acts	Engineering question it raises
Art. 12(1)	The system technically allows automatic recording of events over its lifetime	Provider (design)	Is logging part of the system, on by default, and impossible to silently disable?
Art. 12(2)(a)	Logging records events relevant to identifying situations that may result in a risk within Article 79(1) or a substantial modification	Provider (design), both (use)	Which events show harm to health, safety or fundamental rights, and which show the system has changed?
Art. 12(2)(b)	Events relevant to post-market monitoring under Article 72	Provider	Can performance data be extracted from logs and fed to the monitoring plan?
Art. 12(2)(c)	Events relevant to monitoring operation under Article 26(5)	Deployer (use)	Can the deployer see, in its own environment, enough to spot risks and suspend use?
Art. 12(3)(a) to (d)	For Annex III point 1(a) remote biometric identification: period of each use (start and end date and time), reference database, input data leading to a match, identity of the verifying natural persons under Art. 14(5)	Provider (design), deployer (use)	Are these four fields mandatory in the schema and populated on every use?
Art. 13(3)(f)	Where relevant, instructions for use describe the mechanisms that let deployers collect, store and interpret the logs in line with Article 12	Provider	Do the instructions tell the deployer how to switch on, export and read the logs?
Art. 19(1)	Provider keeps the automatically generated logs under its control for an appropriate period, at least six months	Provider	Which logs flow back to the provider, and where are they stored?
Art. 26(6)	Deployer keeps the logs under its control for an appropriate period, at least six months, unless Union or national law provides otherwise	Deployer	Who owns retention for logs that never leave the deployer's tenancy?
Art. 21(2)	Provider gives a competent authority access to the logs under its control on a reasoned request; Art. 21(3) applies Article 78 confidentiality	Provider	Can a scoped, verifiable extract be produced quickly?

Two points are easy to miss. First, Article 12 itself sets no field list except for remote biometric identification: the provider decides which events satisfy the three purposes and must be able to justify that choice in the technical documentation. Second, the retention duty follows control, not authorship. A cloud-hosted system whose logs sit with the provider puts the burden mostly on the provider; an on-premises deployment puts it on the deployer. The EU AI Act Provider vs Deployer Obligations Guide covers the wider split.

How Article 12 connects to the rest of the Act

Logging is the evidence layer for several other obligations, which is why recital 71 describes traceability over the system's lifetime as the basis for checking compliance, monitoring operations and post-market monitoring.

Article 16(e): lists keeping the Article 19 logs among the provider's obligations, which brings non-compliance within Article 99(4)(a): fines up to EUR 15,000,000 or 3% of total worldwide annual turnover, whichever is higher. Article 99(4)(e) covers deployer obligations under Article 26 at the same level; for SMEs and start-ups Article 99(6) applies whichever amount is lower.
Article 9: the risk management system needs field data to re-evaluate risks; logs are its main source. See the EU AI Act Article 9 Risk Management System Guide.
Article 14: oversight interventions and the two-person verification in Article 14(5) are only provable if logged. See the EU AI Act Article 14 Guide.
Article 72: the post-market monitoring system must gather, record and analyse performance data over the lifetime and, where relevant, interactions with other AI systems; the plan forms part of the Annex IV documentation (point 9). See the EU AI Act Post-Market Monitoring Guide (Article 72).
Article 15: logs reveal manipulation attempts and drift, and the logging pipeline is itself an asset that robustness and cybersecurity controls must protect. See the EU AI Act Article 15 Guide.
Annex IV point 2(g): separately requires dated and signed test logs and reports in the technical documentation. These are development records, not the Article 12 operational logs; keep the two streams distinct.

Designing the event catalogue

Work backwards from the three purposes. For each, ask what a market surveillance authority, the provider's monitoring team or the deployer's operator would need to reconstruct an event, then define the minimum fields. The catalogue below is a practical starting point, not a list taken from the Act.

Event class	Example fields	Article 12(2) purpose served
Session or use period	Start and end timestamp (UTC), deployment ID, deployer tenant, system version	(a), (c); mandatory for RBI under 12(3)(a)
Inference or decision	Request ID, input reference or hash, model and configuration version, output, confidence or score, applied thresholds	(a), (b), (c)
Reference data used	Database or knowledge source identifier and version consulted	(a); mandatory for RBI under 12(3)(b)
Human oversight action	Overseer identity, action (accept, override, disregard, halt), reason code, timestamp	(a), (c); RBI verifier identity under 12(3)(d)
Change event	Model, prompt, threshold or configuration change, approver, before and after version	(a) substantial modification
Anomaly and error	Input out of expected range, fallback triggered, guardrail block, component failure	(a), (b), (c)
Performance signal	Ground-truth feedback, complaint reference, drift metric breach	(b)
Logging health	Logging disabled, buffer overflow, export failure, clock skew alarm	Supports all; shows the capability under 12(1) actually worked

Reference inputs, do not copy them by default: store a hash or pointer to the input in a controlled store, except where Article 12(3)(c) requires the input data that led to a match for remote biometric identification.
Version everything: an output is only explainable against the exact model, configuration and reference data version that produced it.
Use a stable schema: a versioned, documented schema lets deployers parse logs as Article 13(3)(f) expects and lets the provider aggregate them for Article 72.
Log the logger: because Article 12(1) is about technical capability over the lifetime, gaps in logging are themselves events worth recording.

The Secure AI logging guide covers the broader AI security event catalogue; this page stays with what the Act asks for.

Retention, minimisation and access

Articles 19(1) and 26(6) set a floor of six months and a test of appropriateness to the intended purpose, both without prejudice to other Union or national law, in particular data protection law. Financial institutions subject to internal governance rules under Union financial services law keep the logs as part of that documentation (Articles 19(2) and 26(6), second subparagraph). Logs that identify people are personal data, so the GDPR principles of data minimisation and storage limitation in Article 5(1)(c) and (e) still apply.

Decision	Shorter, leaner option	Longer, richer option	When to choose the longer option
Retention period	Six months minimum	Aligned to decision challenge periods or sector rules	Decisions can be contested or reviewed long after they are made (credit, employment, benefits)
Input content	Hash or pointer only	Full input stored under restricted access	RBI matches (required), or where reproduction of the decision is otherwise impossible
Personal identifiers	Pseudonymous subject ID, mapping held separately	Direct identifiers in log	Rarely; prefer pseudonyms with a controlled re-identification path
Location	Deployer tenancy only	Replicated to provider for monitoring	Provider runs Article 72 analytics; document the flow and its legal basis

Write the result into a retention schedule that names the system, the log classes, the period, the legal reason and the owner. The Log Retention Schedule Template and the Privacy in Security Logging and Monitoring Guide cover the mechanics; the EU AI Act vs GDPR guide covers how the two regimes interact.

Integrity, time and producibility

Article 21(2) means logs may be read by an authority that will ask whether they are complete and unaltered. Design for that from the start.

Append-only storage: write logs to storage with object lock or write-once retention so neither application administrators nor the system itself can edit or delete records inside the retention period.
Tamper evidence: chain record hashes or sign batches so a gap or edit is detectable during an export.
Time accuracy: synchronise clocks to an authoritative source and record UTC, so the use periods required by Article 12(3)(a) are defensible.
Separated duties: the team operating the AI system should not also control log deletion.
Scoped export: keep a tested procedure to extract the logs for a system, period or subject, with a manifest and hash, ready for a reasoned request.

Where identity fits

Many Article 12 fields are identity fields: who verified an RBI match, who overrode an output, which service account changed a threshold, which agent or workload called the model. If the system runs under a shared service account, or overseers share a login, the log records an event without an accountable actor. Give each component its own workload identity, give each overseer a named account with role-based rights, and log both the human and the machine identity on every action. Keep the identities that can write or delete logs separate from those that run the system. The AI Agent Audit Trails for Regulators Guide goes deeper on attributing agent actions.

Implementing Article 12 in phases

Scope and assign: list each high-risk system, its Annex III or Annex I basis, whether it is an RBI system, and where its logs sit. Record for each log store whether the provider or deployer controls it.
Design the catalogue: map events to the three Article 12(2) purposes, add the four Article 12(3) fields for RBI systems, and publish a versioned schema.
Build into the product: implement logging as a default-on system function with health events, and describe collection, storage and interpretation in the instructions for use under Article 13(3)(f).
Set retention and protection: agree periods per log class with privacy and legal, configure write-once storage, hash chaining and access roles.
Test before release: replay representative cases and confirm a reviewer can reconstruct each decision, oversight action and change from logs alone. Simulate a logging failure and confirm it alarms.
Rehearse access: run a mock reasoned request: extract a scoped set, verify integrity and time it.
Operate and review: feed log-derived metrics into post-market monitoring, and review the catalogue after every substantial modification. If a schema change breaks parsing, roll back to the prior schema version and keep both readable for the retention period.

Detection and measurement

Logging coverage: percentage of inferences with a complete record (target 100%; investigate any gap).
Logging downtime: minutes per month the logging pipeline was degraded or disabled, with alerts on any disable event.
RBI field completeness: share of RBI uses with all four Article 12(3) fields populated, including two verifier identities where Article 14(5) applies.
Reconstruction success: share of sampled decisions an independent reviewer can fully reconstruct from logs.
Export time: time to produce a verified, scoped extract in rehearsal.
Retention conformance: number of records deleted early or kept beyond schedule.

Framework mapping

Article 12 theme	NIST SP 800-53 Rev 5	NIST CSF 2.0
Events to log and record content	AU-2 Event Logging, AU-3 Content of Audit Records, AU-12 Audit Record Generation	PR.PS-04
Time accuracy	AU-8 Time Stamps	PR.PS-04
Integrity and protection	AU-9 Protection of Audit Information, AU-10 Non-repudiation	PR.PS-04
Retention	AU-11 Audit Record Retention	PR.PS-04
Operational monitoring	AU-12 Audit Record Generation	DE.CM-09, DE.AE-03

On standards, the Commission's standardisation request to CEN and CENELEC includes record keeping among its deliverables. ISO/IEC 24970, Artificial intelligence: AI system logging, was shown by ISO as under publication when checked. Watch the EU AI Act Conformity Assessment and Harmonised Standards Guide for any harmonised standard that would give a presumption of conformity.

Common failure patterns

Infrastructure logs only: HTTP and container logs exist, but nothing records model version, output, threshold or the human decision, so no decision can be reconstructed.
Deployer can switch it off: logging is an optional setting, so the system no longer "technically allows" recording in practice and nobody notices.
Nobody owns retention: provider and deployer each assume the other keeps the logs, and records age out under a short platform default.
Shared accounts: overseers or components share credentials, so RBI verifiers and override decisions cannot be tied to people.
Over-collection: full prompts and personal data are stored indefinitely "for compliance", creating a GDPR problem and a breach target.
Untested export: the first attempt to answer an authority's request reveals missing periods, broken schemas and no integrity proof.

Practitioner checklist

Each high-risk system has a documented event catalogue mapped to Article 12(2)(a), (b) and (c).
RBI systems log all four Article 12(3) fields on every use.
Logging is default-on, emits health events and alerts when disabled.
Instructions for use explain how deployers collect, store and interpret logs (Article 13(3)(f)).
Control of each log store is assigned to provider or deployer, with retention of at least six months set against purpose and data protection law.
Logs are pseudonymised where possible, held in write-once storage, hash-chained and time-synchronised.
Every action records both the human and the machine identity behind it.
A scoped, verifiable export for an Article 21(2) request has been rehearsed.
The catalogue is reviewed after every substantial modification and feeds post-market monitoring.

Standards and references

This guide summarises Article 12 of the EU AI Act and related provisions and is not legal advice. Related NHI Mgmt Group resources: EU AI Act High-Risk AI Systems Guide · EU AI Act Post-Market Monitoring Guide (Article 72) · Secure AI logging · Log Retention Requirements Map

EU AI Act Article 12 Guide: Automatic Logging and Record-Keeping for High-Risk AI