Art. 12 EU AI Act: record-keeping and logging for high-risk AI

Updated: June 2026

This is an explicit providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → obligation under the EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry →. The logging capability must be built in by the provider; deployersdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → carry the matching log-retention duty under Art. 26.6.

Introduction: making the system auditable by construction

Art. 12 is the obligation that turns a high-risk AI systemhigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry → from a black boxblack boxInformal name for a system whose internal decision logic cannot be inspected or meaningfully explained.Open full entry → into an auditable one. It requires that the system technically allows for the automatic recording of events, logs, throughout its lifetime. This is a design requirement on the provider: the capability to log must be built into the system, not bolted on by the deployer afterward. Without it, none of the downstream accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress; never the system itself. The EU AI Act attaches obligations to the role rather than the technology, with provider duties in Article 16 and deployer duties in Article 26, supported by technical documentation (Article 11) and record-keeping (Article 12). See provider, deployer, record-keeping, responsible AI.Open full entry → obligations can be satisfied, because there is no record to examine.

The purpose of the logging is traceability. The logs must make it possible to reconstruct how the system functioned, at a level of detail appropriate to the intended purpose, so that a deployer, an auditor, or a supervisory authority can understand what the system did and why. Logging is the evidentiary foundation on which oversight, incident investigation, and conformity all rest.

What the logs must capture

Art. 12 requires the logging capability to record events relevant for identifying situations that may result in the system presenting a riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → or undergoing a substantial modificationsubstantial modificationA change to a deployed AI system that materially alters its function or purpose, capable of shifting provider obligations onto the modifier.Open full entry →, for facilitating post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use, the product-regulation half of continuous monitoring.Open full entry →, and for monitoring the operation of the system. For the high-risk systems where it applies most strictly, the logging must at minimum capture the period of each use, the reference data against which inputs were checked, the input data, and the identification of the people involved in verifying the results.

The guiding principleprincipleOne of the seven responsible-AI values a governed system should live up to (fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, human oversight). A principle is abstract: it states an outcome, not a lever you can pull. It becomes governable by naming the harm that would breach it, assessing the risk that harm carries, and placing controls against that risk. Held this way, a principle becomes a pillar. See pillar, harm, risk.Open full entry → is that the logs must be sufficient to reconstruct the system's operation to the degree the risk of the use case demands. A system making consequential decisions about people requires logging detailed enough to reconstruct an individual decision; a lower-stakes system requires less.

Why immutability matters

A log is only evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry → if it cannot be quietly altered. This is the point that separates real record-keepingrecord-keepingThe EU AI Act obligation for high-risk AI systems to allow automatic recording of events over the system's lifetime, laid down in Article 12. Deployers must keep the logs under their control for a period appropriate to the system's purpose, at least six months, under Article 26(6). Logs are what make decisions reconstructable afterward. See evidence, human oversight.Open full entry → from the appearance of it. Database logs that an administrator can edit do not qualify as a tamper-resistant audit trail, because a record that can be changed after the fact proves nothing about what happened. The logging Art. 12 envisages is automatically generated, tamper-evident, and retained, so that the record presented to a supervisor is the record of what occurred, not a version that could have been adjusted.

This is the difference between policy as a document and compliance as an instrumented system. An organization that can produce immutable, automatically generated logs demonstrates controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → at the level a supervisor can verify. One that offers editable database tables offers an assertion, not evidence.

The relationship to Art. 19 and Art. 26

Art. 12 is the design obligation; two other articles complete the picture. Art. 19 requires providers to keep the automatically generated logs that are under their control for an appropriate period. Art. 26.6 places the retention duty on deployers: keep the logs the high-risk system generates for at least six months, unless other law requires longer. Together, Art. 12 ensures the logs exist, Art. 19 and Art. 26.6 ensure they are kept, and the combination ensures that when an incident or audit occurs, the evidence is available.

Why it matters

For the deployer, the logs are the primary evidence that the system was used in accordance with its instructions and under proper human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system. It is meaningful only when the human has authority, information and time to act. One of the seven pillars of responsible AI, and under the EU AI Act a requirement for high-risk AI systems: Article 14 requires that those systems are designed so natural persons can effectively oversee them. Oversight that exists on paper but amounts to confirming in practice does not meet that bar. See override rate, automation bias, high-risk AI system, fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, responsible AI. In the IAPP AIGP body of knowledge, this principle appears as human-centricity, with human oversight as one of its elements.Open full entry →. When a supervisory authority asks how a particular decision was reached, or whether oversight was real, the logs are the answer. A deployer who cannot produce them cannot demonstrate compliance, regardless of how well the rest of the program is run.

Governing record-keeping

The controls ensure the logging capability exists, is tamper-resistant, and is retained for long enough to serve its purpose.

At procurement, the deployer confirms that the high-risk system provides the Art. 12 logging capability and that the logs are exportable in a usable format, because a retention duty cannot be met for logs that cannot be extracted. In operation, the deployer ensures the logs are captured, protected against alteration, and retained for the Art. 26.6 minimum or longer where other law applies. The retention design balances the six-month logging floor against the GDPRGDPRRegulation (EU) 2016/679, the General Data Protection Regulation, the EU's law on the processing of personal data. It applies to AI wherever personal data enters training, inputs, outputs, or logs, and it operates alongside the EU AI Act rather than being replaced by it. See controller, processor, lawful basis, DPIA.Open full entry → minimization principle through pseudonymizationpseudonymisationReplacing identifying fields so data can't be attributed to a person without separate information, a minimization and security technique that keeps data personal under GDPR.Open full entry → where the logs contain personal data.

Compliance checklist

1. Does each high-risk system provide an automatic logging capability as required by Art. 12?
2. Are the logs detailed enough to reconstruct the system's operation to the level the use case demands?
3. Are the logs tamper-resistant, so that an administrator cannot silently edit them?
4. Are the logs exportable in a usable format so the retention duty can be met?
5. Are the logs retained for at least six months (Art. 26.6), or longer where other law requires?
6. Where logs contain personal data, is the retention reconciled with the GDPR minimization principle through pseudonymization?