The EU AI Act is the world's first comprehensive legal framework for artificial intelligence. For companies building or deploying AI in high-risk contexts, Article 12 is the provision that will hit operations hardest.
It mandates automatic event logging throughout the entire lifetime of every high-risk AI system. Not optional. Not best practice. A legal requirement with fines of up to €15 million or 3% of global annual turnover for non-compliance.
This guide covers everything you need to know about Article 12: what the law actually says, which systems are in scope, what you must log, how long you must keep it, what the technical standards require, how GDPR intersects, and how to implement it practically before the December 2027 deadline.
What Article 12 actually says
The full text of Article 12 of Regulation (EU) 2024/1689 reads:
“High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”
“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).”
Article 12(3) adds specific requirements for biometric identification systems, covered in detail below.
Three words that do the heavy legal lifting
“Technically allow”
This is the most important phrase in Article 12. Technically means the logging capability must be built into or applied to the system itself. A manual process for exporting logs does not satisfy this requirement. A human who periodically reviews AI outputs and writes notes does not satisfy this requirement. A spreadsheet maintained by your compliance team does not satisfy this requirement.
The system must generate the records automatically, without operator intervention, as a technical capability — not a process.
“Automatic”
Logging cannot depend on a human deciding to log something. Every event must be captured automatically, every time, without exception. A system that logs most events but relies on human judgement to identify which events warrant logging does not comply.
“Lifetime”
From the moment a high-risk AI system is deployed until it is decommissioned. Not from the point at which you decided to start logging. Not from the date your compliance programme went live. From deployment.
If you deployed an AI credit scoring system in January 2025 and implement Article 12 logging in November 2027, you have a gap. That gap is a compliance problem regardless of what you do going forward.
The three purposes Article 12 logging must serve
Article 12(2) defines three specific regulatory purposes your logs must support. Understanding these shapes what you need to capture.
Purpose 1: Risk identification (Article 79(1))
Your logs must enable identification of situations where the AI system presents a risk. This means capturing enough information to detect:
- —Unexpected or anomalous outputs
- —Significant changes in system behaviour over time
- —Performance drift — the model behaving differently than it did at deployment
- —Edge cases where the system produced outputs outside its intended operating parameters
You cannot identify risk after the fact if you only logged the final output. You need enough context to reconstruct what happened and why.
Purpose 2: Post-market monitoring (Article 72)
Providers of high-risk AI systems must conduct post-market monitoring — ongoing assessment of system performance after deployment. Article 12 logs are the primary evidence base for this monitoring.
Your logs must support questions like:
- —Has the model's performance changed since deployment?
- —Are there demographic groups for which the model performs differently?
- —Have there been incidents or near-misses?
- —How does the system perform across different use contexts?
Post-market monitoring is an active, ongoing obligation — not a one-time compliance check.
Purpose 3: Operational oversight (Article 26(5))
Deployers of high-risk AI systems are required to monitor the operation of their systems. Your logs must provide the data that makes this monitoring possible. Article 26(5) requires deployers to monitor the functioning of their high-risk AI systems on the basis of instructions for use and to inform providers about any serious incidents or malfunctions. Logs are the mechanism by which this monitoring is operationalised.
Which AI systems are in scope
Article 12 applies to high-risk AI systems as defined in Annex III of the EU AI Act. These fall into eight categories:
1. Biometric identification and categorisation
Real-time or post-remote biometric identification of natural persons. AI systems that categorise individuals by protected characteristics including race, political opinion, religion, or sexual orientation. Emotion recognition systems.
Note: Emotion recognition in the workplace is prohibited outright under Article 5 — it is not just high-risk.
For biometric identification systems specifically, Article 12(3) imposes additional minimum logging requirements beyond those required for other high-risk categories.
2. Critical infrastructure
AI used in the management of road traffic, water supply, gas, heating, electricity, critical digital infrastructure, and financial market infrastructure.
3. Education and vocational training
AI that determines access to or admission to educational institutions. AI that evaluates learning outcomes or monitors student behaviour during assessments.
4. Employment and workers management
This is the broadest category in practical terms:
- —CV screening and candidate ranking
- —Automated interview analysis
- —Performance evaluation systems
- —Task allocation and workforce management
- —Productivity monitoring systems
If your AI system influences any employment decision affecting EU workers, it is high-risk.
5. Essential private and public services
- —Credit scoring and creditworthiness assessment
- —Loan approval and pricing
- —Insurance risk assessment and pricing
- —Public benefit eligibility decisions
Note: Fraud detection AI that does not affect access to financial services is explicitly excluded.
6. Law enforcement
AI used for risk assessments in criminal investigations, polygraph and similar tools, evaluation of evidence reliability, profiling in the context of detection or investigation of criminal offences.
7. Migration, asylum, and border control
AI used to assess asylum or visa applications, to evaluate the risk of irregular migration, or to assist in border checks.
8. Administration of justice and democratic processes
AI used to assist courts in interpreting facts and law, and AI used to influence elections or referendums.
What you must log
Article 12 defines the purpose of logging but does not prescribe a specific technical format or exact data fields — only what is “appropriate to the intended purpose of the system.”
Based on the regulatory text, the implementing guidance, and draft technical standards, a complete Article 12 log entry for an LLM-based high-risk AI system should contain:
Per AI decision or output
- —Timestamp of the request (UTC, millisecond precision)
- —Timestamp of the response
- —Latency (response time in milliseconds)
- —Unique identifier for the AI system
- —Model version or identifier
- —System version or release identifier
- —Deployment environment identifier
- —The input provided to the model
- —With PII removed or pseudonymised (GDPR requirement)
- —Sufficient to reconstruct what information was presented to the model
- —The output produced by the model
- —With PII removed or pseudonymised
- —Finish reason (completed, stopped, content-filtered)
- —Token count (prompt, completion, total)
- —Model endpoint used
- —Cost or compute units consumed
- —Whether a human reviewed the output before action
- —Whether the human overrode the AI recommendation
- —The final decision taken
For the logging system overall
- —Cryptographic verification that logs have not been modified
- —Chain of custody from log creation to present
- —Evidence of who has accessed the logs
- —When logging began and the retention period applied
- —Confirmation of GDPR jurisdiction compliance
Specific requirements for biometric identification systems
Article 12(3) imposes additional minimum requirements for AI systems used for remote biometric identification. For these systems, logs must capture at minimum:
- —The precise period of each use — start date and time and end date and time of each usage session
- —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 the verification of results as referred to in Article 14(5)
How long must you keep the logs
Article 26(6) requires that automatically generated logs are retained for a minimum of six months. This is a floor, not a ceiling.
Financial services regulation (MiFID II, DORA) may require retention of 5–7 years. Healthcare regulation may impose longer periods. Where sector-specific rules require longer retention, those rules apply.
If an incident is under investigation — by a regulator, a court, or internally — logs related to that incident must be retained until the investigation concludes.
Implement six months as your baseline for all systems. Audit your sector-specific obligations with your legal team and extend retention accordingly. Build the retention period into your logging infrastructure from day one — retrofitting retention periods after the fact is operationally complex and creates compliance gaps.
The tamper-resistance requirement
Article 12 does not use the phrase “tamper-resistant” or “tamper-proof” explicitly. However, the regulatory logic is clear: logs that can be silently altered have zero evidentiary value. A regulator asking to verify the operation of your AI system cannot rely on logs that you or anyone else could have modified after the fact.
Recent enforcement shows that firms rarely fail because their algorithms were irresponsible. They fail because their audit trail could not answer hard questions. If your security, legal, or compliance leaders cannot instantly surface an authorised, forensic timeline of each AI event, Article 12 assumes the worst — regardless of intent.
How to implement tamper-evidence
The established technical approach is cryptographic hash chaining — the same principle used in blockchain systems, without the complexity. Each log entry includes a hash of the previous entry:
Log entry N:
content: { timestamp, model, input, output, tokens, cost }
previous_hash: sha256(log_entry_N-1)
entry_hash: sha256(content + previous_hash)If any entry is modified after the fact, the hash of that entry changes, which breaks the chain from that point forward. The break is immediately detectable. This approach requires no external infrastructure, can be verified by a regulator independently, and creates a mathematically provable record of integrity.
The technical standards — what exists and what does not
There is no finalised technical standard for Article 12 logging yet. Two drafts are worth watching:
prEN 18229-1
Developed by CEN-CENELEC JTC 21. Covers AI logging and human oversight requirements. References Article 12 directly and is intended to become a harmonised standard under the EU AI Act. When a harmonised standard is adopted, compliance with it creates a presumption of conformity with the corresponding legal requirements. Status: draft, not yet published.
ISO/IEC DIS 24970
Focuses specifically on AI system logging. Clause 8.3.1 requires auditability of ML model state information and decision pathway data. The standard requires that AI systems establish a comprehensive logging framework to ensure traceability, compliance, and security. Status: draft international standard, not yet finalised.
The absence of a finalised standard is not a reason to wait. The regulatory outcome — automatic, tamper-evident, complete logs — is clear. Implement to that outcome. Teams that get logging right now will be ahead when the standards land.
The GDPR intersection
Article 12 creates a direct tension with GDPR that every implementing team must resolve.
GDPR requires data minimisation — collect only what is necessary, retain only as long as necessary. Article 12 requires comprehensive logging for at least six months.
Pseudonymise before logging. Replace PII with consistent pseudonyms. You satisfy both obligations simultaneously: Article 12 has the decision with sufficient detail; GDPR has minimised personal data.
Critical timing: scrub before logging, not after
PII scrubbing must happen before the log is written. If you log raw data and then redact, the raw data existed on disk — however briefly. That brief existence is a GDPR processing event that may itself require justification.
The data residency question
Article 12 does not specify where logs must be stored. However, because Article 12 logs contain data related to AI decisions affecting EU individuals, GDPR applies to the log data.
GDPR Article 44 restricts the transfer of personal data outside the EU and EEA without appropriate safeguards. Even pseudonymised log data is likely personal data under GDPR if re-identification is possible.
The US CLOUD Act allows US authorities to compel US companies to produce data stored anywhere in the world. Data stored by a US cloud provider in an EU data centre is subject to the CLOUD Act. Standard Contractual Clauses with US providers do not eliminate CLOUD Act exposure and are increasingly challenged by EU data protection authorities.
Store Article 12 logs with an EU-incorporated provider operating exclusively EU-based infrastructure.
The deadline situation
Original timeline
The EU AI Act entered into force on 1 August 2024. Under the original timeline, obligations for high-risk AI systems listed in Annex III were to take effect on 2 August 2026.
The Digital Omnibus amendment
The European Commission's Digital Omnibus proposal, adopted in May 2026, extended the deadline for Annex III high-risk AI systems to December 2, 2027 for stand-alone systems, and August 2, 2028 for AI systems embedded as safety components in physical products. GPAI obligations for foundation model providers remain on the original timeline.
What this means practically
The Omnibus extension gives companies additional runway to implement compliant logging. It does not reduce the obligation.
If your Article 12 logging starts on December 1, 2027, your audit trail is one day old when regulators can start asking for it. A company that implemented logging in early 2026 will have nearly two years of clean, verified logs. That difference is significant in any regulatory investigation or enforcement action.
How to implement Article 12 logging
There are three practical approaches:
Approach 1: SDK-based compliance logging (lowest friction)
Install a purpose-built compliance logging SDK that instruments your LLM client library automatically.
import sovergate
sovergate.init(api_key="svg_prod_xxxx")
sovergate.instrument(openai)
# All existing LLM calls logged automatically
response = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
)import sovergate from '@sovergate/js'
sovergate.init({ apiKey: 'svg_prod_xxxx' })
sovergate.instrument(openai)
// All existing LLM calls logged automatically
const response = await openai.chat.completions.create({
model: 'gpt-4o',
messages: [{ role: 'user', content: prompt }]
})The SDK:
- —Observes LLM calls without intercepting or forwarding them
- —Scrubs PII locally before any data leaves your infrastructure
- —Sends a clean log to EU-hosted servers asynchronously
- —Adds zero latency to your application
- —Generates monthly Article 12 PDF reports automatically
Approach 2: Custom logging wrapper
Build a wrapper around your LLM client that captures inputs and outputs and writes them to your own logging infrastructure. You need to implement:
- —Input/output capture for every LLM call
- —PII detection and scrubbing
- —Append-only log storage
- —Hash chain computation for tamper evidence
- —Retention management (6 months minimum)
- —Report generation for regulators
Approach 3: LLM provider logging
Some LLM providers offer logging features. At time of writing, no major LLM provider offers EU-only logging with Article 12-compatible tamper evidence and compliance report generation. Provider logging is a supplement to, not a replacement for, Article 12 compliance logging.
Building your Article 12 compliance programme
Article 12 logging is one component of a broader compliance programme. Here is the full picture:
- 1.Identify your high-risk AI systems. Map every AI system your organisation uses or deploys against Annex III. Be conservative — if there is doubt, treat the system as high-risk until you have legal advice confirming otherwise.
- 2.Assess your current logging capability. For each high-risk AI system: are events logged automatically? Is every event captured? Are logs tamper-evident? How long are logs retained? Can you generate a regulator-ready report?
- 3.Implement compliant logging. Close the gaps identified in step 2. Either via SDK, custom build, or a combination.
- 4.Implement human oversight logging. Article 14 requires human oversight of high-risk AI systems. Your logging must capture whether a human reviewed the AI output, whether they overrode it, and the final decision taken.
- 5.Document your data processing. GDPR requires a Record of Processing Activities (ROPA). Add your Article 12 logging to your ROPA with legal basis, retention periods, storage location, and access controls.
- 6.Conduct a DPIA. A Data Protection Impact Assessment is required where processing is likely to result in high risk to individuals. AI systems in high-risk categories almost certainly trigger this requirement.
- 7.Establish your reporting process. Define how you will generate, store, and produce Article 12 compliance reports. Who is responsible? What format? How will you respond to a regulatory request?
- 8.Test your audit trail. Run a tabletop exercise: assume a regulator asks for the full decision log for a specific AI-assisted decision made six months ago. Can you produce it? In what format? How quickly?
Common implementation mistakes
Article 12 requires logging of normal operations — every AI decision, not just the ones that go wrong. You cannot identify risk after the fact if you only logged the failures.
Standard application logs are not designed to be tamper-evident compliance records. They are rotated, overwritten, and modified as a matter of normal operations. Article 12 logs must be append-only and tamper-evident.
The fact that Article 12 requires you to log does not override your GDPR obligations. Implement PII scrubbing as part of your logging pipeline, not as an afterthought.
Article 12 covers the lifetime of the system. If your system has been in production since 2024 and you implement logging in late 2027, you have three years of unlogged operation.
Logs containing data related to EU individuals must be stored in a GDPR-compliant jurisdiction. A US cloud provider's EU region is not sufficient — the CLOUD Act applies regardless of physical data location.
Logs that can be silently modified have zero evidentiary value. Implement cryptographic hash chaining from day one. It is technically straightforward and is the difference between a defensible audit trail and a compliance document a regulator will immediately question.
Frequently asked questions
Yes, if those systems fall under an Annex III high-risk category and make decisions that affect individuals. An internal AI system that screens employee performance or allocates tasks is high-risk under Category 4.
Yes. The Annex III categories cover AI systems used to "assist" in decisions, not only fully automated decisions. A CV screening tool that surfaces a ranked shortlist for human review is still high-risk.
Deployers of high-risk AI systems have their own obligations under Article 26, including ensuring that the AI system generates logs as required by Article 12. If the provider's system does not generate compliant logs, you are responsible for implementing supplementary logging.
Yes. Article 12 requires automatic logging over the lifetime of the system. Selective logging — even sampling-based approaches — does not satisfy the requirement of traceability for every AI decision.
Yes, with care. You may use the logs for debugging, cost management, and model performance monitoring. However, any use beyond Article 12 compliance must have its own legal basis under GDPR, and you must document that basis.
Pseudonymisation is sufficient. Full anonymisation is technically difficult for AI decision logs and may reduce the utility of the logs for incident investigation. Pseudonymise consistently — the same individual should have the same pseudonym throughout the log.
Article 11 requires technical documentation — a dossier describing the AI system, its design, testing, and intended use. This is a static document. Article 12 logs are dynamic — generated in real time throughout operation. Both are required for high-risk AI systems.
Summary
Article 12 of the EU AI Act requires:
The December 2027 deadline gives organisations time to implement this properly. The organisations that use this time to build robust, documented, tamper-evident logging systems will be in a fundamentally different position from those that wait.
Start now. Your audit trail begins the day you install the SDK.
This guide is maintained by Sovergate, a European AI compliance platform that provides Article 12 logging for companies using LLMs in high-risk contexts. For questions about Article 12 implementation, contact hello@sovergate.com. This guide is for informational purposes only and does not constitute legal advice.
Last updated June 2026. Regulation referenced: EU Regulation 2024/1689 (EU AI Act), Articles 12, 14, 26, 72, 79. Deadline: December 2, 2027.
Ready to start building your Article 12 audit trail?
Two lines of code. PII scrubbed locally. Data stored in Germany. Monthly compliance reports ready for your legal team.