--- authoritative: false representation: annotated-page publisher: AstroKube methodology: https://ai-act.astrokube.com/about/ source_verified_on: '2026-09-15' site_content_updated_on: '2026-09-15' title: 'Article 12: Record-keeping | EU AI Act | AstroKube' description: 'Article 12, EU AI Act: 1. High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. 2. In…' language: en source: https://ai-act.astrokube.com/law/art-12/ --- 1. [Start](https://ai-act.astrokube.com/) 2. [The law](https://ai-act.astrokube.com/law/) 3. Article 12 Chapter III · Section 2 · Requirements for high-risk AI systems # Article 12 — Record-keeping ▼ Primary text, verbatim. Our annotations appear below, visibly separated. [1\.](https://ai-act.astrokube.com/law/art-12/#p-1) High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. [2\.](https://ai-act.astrokube.com/law/art-12/#p-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\.](https://ai-act.astrokube.com/law/art-12/#p-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 (start date and time and end date and time of each use); (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). This text is meant purely as a documentation tool and has no legal effect. The Union's institutions do not assume any liability for its contents. The authentic versions of the relevant acts, including their preambles, are those published in the Official Journal of the European Union and available in EUR-Lex. [ Recital 71 — interpretive context Having comprehensible information on how high-risk AI systems have been developed and how they perform throughout their lifetime is essential to enable traceability of those systems, verify compliance with the requirements under this Regulation, as well as monitoring of their operations and post market monitoring. This requires keeping records and the availability of technical documentation, containing information… ](https://ai-act.astrokube.com/law/recital-71/) ## What this means for you In your terms · Automatic recording of events Logging capability is a design-time decision, not a config you bolt on later: correlation IDs and event coverage live in the code. - Decision-correlation IDs across services ## Obligations derived from this article [Automatic recording of eventsArt. 12](https://ai-act.astrokube.com/explorer/?art=art-12) ## Commonly misquoted What gets said Article 12 requires tamper-evident logs. What the provision says Article 12 says a high-risk system shall technically allow for the automatic recording of events over its lifetime, and that the logging capabilities shall enable recording what is relevant for identifying risk situations and substantial modification, for post-market monitoring, and for monitoring the operation under Article 26(5). It says nothing about integrity, storage, or tamper evidence. Those are engineering answers to a real risk, and worth having, but they are not what this provision demands. [EU Art. 12(1), (2)](https://ai-act.astrokube.com/law/art-12/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") ## Scenarios that touch this provision ### A credit-decision feature Illustrative A model scores applicants for a lending product and the score drives the decision, with a human able to override it. ### Your role ProviderDeployer ### Where it lands High risk Deferred 2 Dec 2027 ### Decided by Annex III, point 5(b): systems intended to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of systems used to detect financial fraud. What applies - [Risk management system](https://ai-act.astrokube.com/explorer/?q=art-9-risk-management) - [Data and data governance](https://ai-act.astrokube.com/explorer/?q=art-10-data-governance) - [Technical documentation](https://ai-act.astrokube.com/explorer/?q=art-11-technical-documentation) - [Automatic recording of events](https://ai-act.astrokube.com/explorer/?q=art-12-logging) - [Human oversight](https://ai-act.astrokube.com/explorer/?q=art-14-human-oversight) - [Accuracy, robustness and cybersecurity](https://ai-act.astrokube.com/explorer/?q=art-15-accuracy-robustness) - [Deployer obligations](https://ai-act.astrokube.com/explorer/?q=art-26-deployer-obligations) - [Fundamental rights impact assessment](https://ai-act.astrokube.com/explorer/?q=art-27-fria) - [Conformity assessment](https://ai-act.astrokube.com/explorer/?q=art-43-conformity-assessment) - [Registration in the EU database](https://ai-act.astrokube.com/explorer/?q=art-49-registration) - [Right to explanation of individual decisions](https://ai-act.astrokube.com/explorer/?q=art-86-right-to-explanation) What you have to be able to produce - Adversarial and injection test suite - Annex IV technical file - Bias examination report - Conformity route decision per system - Dataset cards with provenance - Decision factors captured per output - Decision-correlation IDs across services - Declared accuracy levels and metrics - Deployer-side log retention - Deployment instructions record per system - Doc generation wired into CI - Documentation format decision on record - Escalation path for emergent risk - Explanation request process - Field-risk signal feed into the register - Foreseeable-misuse analysis per release - Fundamental rights impact assessment - Inference event schema - Kill switch and override, with tests - Living risk register with review cadence - Model performance SLOs with alerts - Named oversight roles - Oversight runbook - Oversight UX with override path - Per-run lineage records - Registration entries per system - Replay runbook - Representativeness note for the target population - Risk-to-control mapping in the design docs - Scope determination on record - Stated assumptions per data set - Tamper-evident log storage - Worker information notice What would change the answer - Unlike the hiring case, this one carries a fundamental rights impact assessment: Article 27(1) names Annex III point 5(b) explicitly. - Restricting the system to fraud detection takes it out of point 5(b). Scoring the same people for a lending decision puts it back. - An affected person can ask for an explanation of the individual decision under Article 86, and that explanation comes from the same records Article 12 asked you to keep. [EU Annex III, point 5(b)](https://ai-act.astrokube.com/law/annex-iii/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 27(1)](https://ai-act.astrokube.com/law/art-27/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 86](https://ai-act.astrokube.com/law/art-86/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 12](https://ai-act.astrokube.com/law/art-12/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") A scenario describes a system we made up, not yours. It is not a classification of your system and not legal advice. Pending review by a named legal reviewer. ## If you would rather not read the law The basics page explains the Regulation's own categories in order: scope, role, tier, date. The engineering view groups the obligations by the platform capability they demand. [Start with the basics →](https://ai-act.astrokube.com/basics/) [Open the engineering view →](https://ai-act.astrokube.com/engineering/) ## About this provision ### Status Upcoming 2 Dec 2027 Moved from ~2 Aug 2026~ ### Regime High-risk ### Binds Provider ### Type Article · Chapter III · Section 2 ### Amended by Not amended ### Recitals [71](https://ai-act.astrokube.com/law/recital-71/) ### Related [Article 11](https://ai-act.astrokube.com/law/art-11/) [Article 19](https://ai-act.astrokube.com/law/art-19/) [Article 72](https://ai-act.astrokube.com/law/art-72/) [Article 79](https://ai-act.astrokube.com/law/art-79/) ### Cited capture regulation-2024-1689/en-2026-08-18.html sha256 8f0b656302f9864c… [Authentic text (EUR-Lex) →](http://data.europa.eu/eli/reg/2024/1689/oj) [This version (EUR-Lex) →](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R1689-20260727) ### Machine readable [/law/art-12.md](https://ai-act.astrokube.com/law/art-12.md) [/api/law.json](https://ai-act.astrokube.com/api/law.json) ### Found an error? [Write to us →](https://astrokube.com/contact)