Articles 12 and 13: logging, traceability and instructions
These two articles are about the same thing from opposite ends: what the system records about itself, and what you tell the person deploying it. Both are engineering obligations dressed as documentation obligations, and both are cheaper to build in than to retrofit.
Article 12: what the logs are for
High-risk systems must technically allow for the automatic recording of events over the lifetime of the system. The Regulation defines the purpose rather than the schema: the capability must enable:
- identifying situations that may result in the system presenting a risk within the meaning of Article 79(1), or leading to a substantial modification;
- facilitating post-market monitoring under Article 72;
- monitoring the operation of the system by deployers under Article 26(5).
Work backwards from those three. If your logs cannot support an incident investigation, feed the monitoring plan, or let a deployer see what the system did, they do not satisfy Article 12 however voluminous they are.
The prescribed minimum for remote biometric identification
Article 12(3) is the one place the Act specifies fields. For Annex III point 1(a) systems, logs must at minimum record: the period of each use (start and end date and time); the reference database against which input data was checked; the input data for which the search led to a match; and the identification of the natural persons involved in verifying the results under Article 14(5).
Retention: six months, both sides
| Who | Basis | Duty |
|---|---|---|
| Provider | Art. 19 | Keep logs automatically generated by the system, to the extent under their control, for a period appropriate to the intended purpose and at least six months, unless Union or national law provides otherwise. |
| Deployer | Art. 26(6) | Keep logs under their control for a period appropriate to the intended purpose and at least six months, unless Union or national law provides otherwise. |
“Under their control” is the operative phrase and it produces gaps. In a SaaS arrangement the provider often holds the logs and the deployer holds none. In an on-premise deployment it is reversed. Neither party is relieved by the other holding them, each owes retention for what it controls. Settle this in the contract, and record which party holds what in the technical file.
Where this usually goes next
Three situations account for most people reading this page. Each has a different answer.
A deal is blocked on an AI questionnaire
Legal will not sign until you can evidence how AI is governed. HumanAudit’s AI Trust Package is a fixed $3,500 over five business days: a public trust page, a pre-filled SIG Lite / CAIQ / SSPA Section K questionnaire bank, and your AI inventory and classification.
You need ISO/IEC 42001 documentation
23 clause-mapped AIMS documents with all 38 Annex A controls pre-populated, editable and yours to keep, from $199. Or score your gaps first: 18 questions, free, no signup to begin.
You are not sure what reaches you
Twenty minutes with the founder. No prep, no deck, straight to the person accountable for the work. If none of this applies to you, you get told that on the call.
This reference is published by HumanAudit Inc. Not a law firm, not an accredited certification body, not a registered auditor. We build documentation, your counsel interprets it, and an accredited body of your choosing certifies you. How this is funded →
Article 13: transparency to the deployer
Distinct from Article 50, which is transparency to the public. Article 13 is transparency to the organisation deploying your system, and its test is functional: the system must be sufficiently transparent to enable deployers to interpret the output and use it appropriately.
Instructions for use must be concise, complete, correct and clear, in an appropriate digital or other format, and must contain:
- Provider identity and contact details.
- Characteristics, capabilities and limitations of performance: intended purpose; the level of accuracy including its metrics, robustness and cybersecurity against which the system was tested and validated; known or foreseeable circumstances that may lead to risks to health, safety or fundamental rights; technical capabilities to provide information relevant to explain output; performance regarding specific persons or groups on which the system is intended to be used; specifications for input data.
- Changes to the system and its performance pre-determined at the time of the initial conformity assessment.
- The Article 14 human oversight measures, including the technical measures put in place to facilitate interpretation of outputs by deployers.
- Computational and hardware resources needed, expected lifetime, and maintenance and care measures including software updates.
- Where relevant, a description of mechanisms allowing deployers to properly collect, store and interpret the logs.
Point 3 is a design decision disguised as documentation
Changes pre-determined at initial conformity assessment and described in the technical documentation are not substantial modifications requiring fresh assessment. Changes outside that envelope are. So the breadth of what you declare here directly determines how often you re-assess, which makes it an architecture conversation, not a technical-writing task. Substantial modification →
Expert analysis. The article text is clear; how broadly a pre-determined change envelope may be drawn has not been tested.
Status labels on this page
Verified fact: The Art. 12 purposes, the Art. 12(3) minimum fields, the six-month retention in Arts. 19 and 26(6), and the Art. 13(3) contents list.
Expert analysis: The control-gap analysis for SaaS versus on-premise, and the change-envelope framing.
Unsettled: How broadly pre-determined changes may be specified before an authority treats a change as substantial.
Decide who holds which logs
The cheapest thing you can do this quarter is write down, per system, which party controls which logs, for how long they are retained, and how a deployer requests them. It is a paragraph in a contract and a row in an inventory, and it closes a real gap.
Not sure where you sit?
The classifier maps your system against Articles 5, 6, 50 and Annex III. Twelve questions, no email.
Questions
What does Article 12 of the EU AI Act require?
Article 12 requires high-risk AI systems to technically allow for the automatic recording of events, called logs, over the lifetime of the system. The logging capabilities must enable recording of events relevant for identifying situations that may result in the system presenting a risk within the meaning of Article 79(1) or leading to a substantial modification, facilitating post-market monitoring under Article 72, and monitoring the operation of the system by deployers under Article 26(5).
How long must AI Act logs be kept?
Article 19 requires providers to keep the logs automatically generated by their high-risk AI systems, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months, unless provided otherwise in applicable Union or national law. Article 26(6) places a parallel obligation on deployers for logs under their control, also at least six months.
What must the instructions for use contain?
Article 13(3) prescribes the contents: the identity and contact details of the provider; the characteristics, capabilities and limitations of performance including intended purpose, the level of accuracy robustness and cybersecurity against which the system was tested, known or foreseeable circumstances that may lead to risks, technical capabilities to provide information relevant to explain output, performance regarding specific persons or groups, and input data specifications; changes to the system and its performance pre-determined at the time of initial conformity assessment; the human oversight measures under Article 14; and the computational and hardware resources needed, expected lifetime, and maintenance measures including software updates.
What logging is required for remote biometric identification?
Article 12(3) sets a minimum for systems listed in Annex III point 1(a). Logs must record the period of each use with start and end date and time, the reference database against which input data has been checked, the input data for which the search led to a match, and the identification of the natural persons involved in the verification of results under Article 14(5).
Obligations, article by article
- Art. 5 prohibitions
- Art. 4 AI literacy
- Art. 50 transparency
- Art. 9 risk management
- Art. 10 data governance
- Art. 11 / Annex IV
- Art. 14 human oversight
- Art. 15 accuracy & security
- Art. 17 QMS
- Arts. 43–48 conformity
- Art. 49 registration
- Art. 57 sandboxes
- Open source
- Art. 72 monitoring
- Art. 73 incidents
- Arts. 51–56 GPAI
- Art. 99 penalties
- Compliance checklist
- FRIA template (Art. 27)
- When Annex III does not apply →