EU AI Act
Article 12.
Plain English.

Short version.

EU AI Act Article 12 requires that high-risk AI systems technically allow for the automatic recording of events (“logs”) over the lifetime of the system, with traceability sufficient for risk identification, post-market monitoring, and operation monitoring under Articles 26(5), 72, and 79(1).

Three points trip everyone up. First, the scope is narrower than “all AI” — it applies to systems on the Annex III high-risk list (plus product-safety AI under Annex I). Second, the requirement is on the provider, with downstream obligations on the deployer. Third, “lifetime of the system” routinely outlives the SaaS contract you are signing today, which is why “our vendor logs it for us” is fragile as a sole compliance answer.

This guide quotes the article verbatim, walks the clauses, and ends with three architectural patterns providers and deployers actually use in 2026.

Disclaimer: this guide is editorial, not legal advice. For binding interpretation, consult counsel and the official text of Regulation (EU) 2024/1689.

The article, verbatim.

From Regulation (EU) 2024/1689 (the EU AI Act), Article 12 — “Record-keeping.” Quoted from the official consolidated text via artificialintelligenceact.eu/article/12 .

1. High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.

2. In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for:

(a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification;

(b) facilitating the post-market monitoring referred to in Article 72; and

(c) monitoring the operation of high-risk AI systems referred to in Article 26(5).

3. For high-risk AI systems referred to in point 1(a), of Annex III, the logging capabilities shall provide, at a minimum: (a) recording of the period of each use of the system; (b) the reference database against which input data has been checked by the system; (c) the input data for which the search has led to a match; (d) the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5).

Three substantive clauses, one paragraph of minimum logging fields for the specific case of remote biometric identification. The rest of this guide unpacks each in turn.

What counts as “high-risk.”

Article 12 only applies to high-risk AI systems. The Act defines two routes into that classification. Both routes are listed in Article 6, with the substantive lists in Annex I and Annex III.

• Annex I — product-safety AI. An AI system is high-risk if it is a safety component of a product (or a product itself) covered by Union harmonisation legislation listed in Annex I (medical devices, toys, machinery, lifts, etc.) and is required to undergo a third-party conformity assessment.
• Annex III — listed use cases. Eight categories, including: biometric identification and categorisation; critical infrastructure (e.g. road traffic); education and vocational training; employment, worker management and access to self-employment; access to essential private and public services; law enforcement; migration, asylum and border control; and the administration of justice and democratic processes. The full list is at artificialintelligenceact.eu/annex/3 .

If your system is on neither list, Article 12's logging obligation does not directly apply. That said, two notes. First, GPAI (general-purpose AI) models have their own technical documentation regime under Articles 53–55. Second, the same traceability is rapidly becoming a market expectation even for non-high-risk AI — buyers will increasingly ask for it because their own downstream uses may be high-risk.

“Automatic recording of events.”

The word doing the work in Article 12(1) is automatic. The system itself must be capable of recording events without relying on a human operator to remember to write things down. This is the same shape as GDPR-era audit logging in healthcare and finance: the record is a property of the system, not of a process around it.

Article 12(2) then constrains what events must be loggable. The three categories — risk identification (12(2)(a)), post-market monitoring (12(2)(b)), and operation monitoring (12(2)(c)) — are each defined elsewhere in the Act:

• Article 79(1) risk. A risk to the health, safety, or fundamental rights of persons. The logs must let you identify situations that may result in such a risk — i.e. early enough to act, not only after harm.
• Article 72 post-market monitoring. Providers must run a documented post-market monitoring system. The logs feed that system. Post-market here is the same idea as in MDR for medical devices: track real-world performance, not just conformity-assessment-time performance.
• Article 26(5) operation monitoring. Deployers must monitor operation and inform providers of incidents. The logs are the substrate.

What about data minimisation? Article 10 and the GDPR remain in force. Logs are personal data when they include identifiable inputs or decisions about identifiable people. The conservative read: log what is necessary for the three purposes in 12(2), no more; pseudonymise where possible; keep the schema explicit so a data protection impact assessment (DPIA) can reason about it.

“Lifetime of the system.”

Article 12(1) requires logging over the “lifetime of the system.” The Act does not pin this to a hard number of years; it is functional. The lifetime ends when the system is decommissioned, not when a vendor contract churns or when a database is migrated.

For the documentation regime, Article 18 (Documentation keeping) gives a concrete floor: 10 years after the system is placed on the market or put into service. For the logs themselves, Article 19 (Automatically generated logs) requires providers to keep logs “to the extent such logs are under their control” for at least six months unless other Union or national law (notably GDPR) requires otherwise. Deployers must keep logs “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months.”

Read literally, the six-month floor is the floor; the lifetime-of-system ceiling is the ceiling. Real-world high-risk AI lives years; a six-month log is a starting point, not a target. Deployers in finance, health, and HR are typically retaining for the full statute-of-limitations window for the underlying decision (often 5–10 years).

This is where SaaS vendor logging gets fragile. A SaaS contract canonically lasts 1–3 years; the AI system, the obligation, and the potential subpoena all outlive that. The pattern that closes the gap is exporting an immutable, vendor-independent copy of the log — a tamper-evident anchor — so the record survives vendor change. See the AI audit-trail pillar for the long form.

Three architectural patterns.

How providers and deployers actually satisfy Article 12 in 2026 falls into three patterns. They are not mutually exclusive; the most defensible stacks combine all three.

Pattern C is what Orynq ships — see the anchoring deep dive in the proof-of-inference pillar and the Orynq SDK reference for code. Cost on Cardano L1 is approximately 0.2–0.3 ADA per anchor.

Common questions.

• Does my logging need to be on-chain to satisfy Article 12? No. Article 12 does not specify the medium. It specifies automatic recording, traceability for three named purposes, and retention over the lifetime of the system. On-chain anchoring is one way to meet the spirit of “lifetime of the system” durably; immutable object storage with documented controls is another. The point is the property, not the technology.
• Can a SaaS vendor satisfy Article 12 for me? Partially. The vendor can provide the technical capability; the obligation sits with the provider or deployer of the high-risk AI system. If your vendor is the AI provider, you inherit responsibility as a deployer under Article 26 and must still operate-monitor and retain logs “appropriate to the intended purpose.” The legal sufficiency of a single SaaS log is a question for counsel and depends on your role.
• When does Article 12 apply? Most provisions of the Act became applicable on 2 August 2026. Some obligations (prohibited practices in Article 5, AI literacy in Article 4) applied earlier from 2 February 2025; GPAI obligations from 2 August 2025; specific high-risk AI under Annex I has a longer runway (Article 113). Article 12 itself is in force for high-risk AI systems falling under the Act's applicability dates as of 2 August 2026. Cross-check against the official application timeline.
• What is the minimum retention? Six months under Article 19 unless other law requires more, subject to the “lifetime of the system” framing of Article 12(1). Documentation under Article 18 is 10 years. In practice, log-retention regimes track the statute of limitations for the underlying decision (often 5–10 years).
• How does this relate to NIST AI RMF and ISO/IEC 42001? Article 12 is a binding EU regulation. NIST AI RMF is a voluntary US framework; ISO/IEC 42001:2023 is a certifiable management-system standard. The three converge on “produce an auditable record of decisions made by the AI system,” but Article 12 is the only one that is law. See the ISO 42001 + NIST AI RMF mapping for the side-by-side.
• Does Article 12 require me to log inputs and outputs? Article 12(3) sets explicit minimums for Annex III(1)(a) remote-biometric-identification systems (period of use, reference database, input that matched, human verifier identity). For other high-risk systems Article 12(2) constrains what events the logging must enable; what you choose to record beyond that is a data-protection balancing exercise.