Chapter III · Section 2 · Requirements for high-risk AI systems
Article 12 — Record-keeping
▼ Primary text, verbatim. Our annotations appear below, visibly separated.
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 (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.
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
In your terms · Automatic recording of events
You already have the pipeline. The gap is usually schema and retention: events rich enough to reconstruct one specific decision on one specific date, protected against tampering.
You already haveA log pipeline and retention config. The gap is decision-grade fidelity, not plumbing.
- Inference event schema
- Tamper-evident log storage
- Replay runbook
Failure smells likeA regulator asks why one decision happened on one date, and the best answer available is a dashboard screenshot.
In your terms · Automatic recording of events
This is the obligation that makes answering why the system decided something possible at all.
In your terms · Automatic recording of events
Long-retention, full-fidelity decision logs are a real storage line item and a real privacy surface; budget both.
Obligations derived from this article
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.
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 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
- Data and data governance
- Technical documentation
- Automatic recording of events
- Human oversight
- Accuracy, robustness and cybersecurity
- Deployer obligations
- Fundamental rights impact assessment
- Conformity assessment
- Registration in the EU database
- Right to explanation of individual decisions
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.
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.