Article 12 Logging and How Long You Must Keep the Records

This duty almost never bites on the day you deploy. It bites when someone comes asking. A rejected applicant wants to know how the decision about them was reached. A market surveillance authority sends a reasoned request for information. Your own assurance team spots that outputs drifted during a particular quarter and needs to know which cases were affected. Every one of those questions resolves to the same underlying question: what did the system see, what did it output, when, and who was supervising it at the time. If the answer lives only inside a vendor's platform on a rolling thirty-day window, you have nothing to hand over.

Article 12 is the requirement that makes that answer technically possible. Article 19 and Article 26(6) are the requirements that make it survive long enough to be useful. They are short provisions and easy to skim past on a first read of the Act. In practice they determine whether any of your other high-risk controls can be demonstrated at all — human oversight, accuracy and robustness monitoring, post-market monitoring and serious incident reporting are all evidenced from logs. Without them you have a policy, not a control.

What Article 12 actually requires

Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. It is a design requirement, not a filing requirement. The logging capability must enable the recording of events relevant to identifying situations where the system may present a risk to health, safety or fundamental rights or may undergo a substantial modification; to supporting post-market monitoring under Article 72; and to supporting the deployer's monitoring of operation under Article 26(5).

Note what the Article does not do. For most high-risk systems it does not prescribe a field list. The only place the Act sets out minimum log content is for remote biometric identification systems under point 1(a) of Annex III, where the logging must at minimum capture the period of each use, the reference database against which input data was checked, the input data that produced a match, and the identity of the natural persons involved in verifying the results. For everything else, the content of your logs has to be derived backwards from the three purposes in Article 12(2). Harmonised standards intended to give more concrete effect to record-keeping are still in development through the European standardisation bodies, and you should not assume a published standard confers presumption of conformity here until it is cited in the Official Journal. Design your log schema against the statutory purposes, and be ready to revisit it.

Article 13 closes the loop: the instructions for use a provider supplies must describe the mechanisms that allow deployers properly to collect, store and interpret the logs. If the instructions you have received are silent on this, that is a conformity question to put to the provider, not a gap for you to paper over.

Who the duty falls on

This is the point most often got wrong, so state it plainly. The duty to build the logging capability falls on the provider. The duty to retain logs falls on both provider and deployer, each in respect of the logs under their own control. They are separate obligations and neither discharges the other.

Role	Duty	Source
Provider	Build automatic logging into the system over its lifetime	Article 12
Provider	Retain the automatically generated logs under its control	Article 19
Provider	Give competent authorities access to those logs on reasoned request	Article 21
Deployer	Monitor operation against the instructions for use; escalate risks and serious incidents	Article 26(5)
Deployer	Retain the logs under its control	Article 26(6)
Deployer that rebrands, substantially modifies, or changes intended purpose	Assumes the provider duties above	Article 25

That last row is the one that changes people's compliance position without them noticing. Under Article 25, a deployer becomes the provider of a high-risk system if it puts its own name or trade mark on a system already on the market, makes a substantial modification to it, or modifies the intended purpose of a system so that it becomes high-risk. Rebadging a vendor's screening tool as your internal platform is enough to trigger this. If it happens, the Article 12 design duty and the Article 19 retention duty become yours, and you will need the original provider's cooperation and technical access to meet them — which Article 25 requires them to give, but which you should secure contractually rather than rely on.

The "under their control" problem

Both retention duties are qualified by the phrase "to the extent such logs are under their control". Read casually, that reads like an escape hatch for anyone buying software as a service: the vendor holds the logs, so the deployer has nothing to retain. Read properly, it is a warning. Your Article 26(5) monitoring duty, your obligation to notify the provider and the market surveillance authority when a system presents a risk, and your ability to answer an Article 86 request from an individual for an explanation of an AI-assisted decision all depend on evidence you may not hold. Control is something you negotiate, not something you discover.

Retention is also not the same thing as the technical documentation duty. A provider keeps technical documentation, quality management system records, notified body decisions and the EU declaration of conformity at the disposal of national authorities for ten years under Article 18. Logs are a separate, shorter-lived record with a different purpose. Do not let one retention schedule silently absorb the other.

How long you must actually keep them

Both Article 19 and Article 26(6) set the same formula: a period appropriate to the intended purpose of the high-risk AI system, and in any event at least six months, unless Union or national law provides otherwise — data protection law in particular. Six months is a floor, not a target and not a ceiling. "Appropriate to the intended purpose" is doing real work in that sentence.

Things that push the appropriate period beyond six months include the limitation periods for the claims your system could realistically generate, sectoral record-keeping rules, and the cycle length of the decision itself — a system that informs annual promotion rounds produces a comparison that only becomes contestable a year later. Financial institutions subject to internal governance requirements under Union financial services law maintain these logs as part of the documentation kept under that law, which will usually be the longer and more prescriptive regime.

Where logging collides with data protection

Logs of a high-risk system used on people are almost always personal data, and often personal data about two separate groups: the individuals the system was applied to, and the staff who operated or oversaw it. The second group turns your compliance log into workplace monitoring.

The AI Act's six-month minimum gives you a legal obligation to point to for that period. It does not license indefinite retention, it does not by itself justify the granularity you have chosen, and it does not remove the need for a lawful basis, a documented retention justification, a data protection impact assessment where the threshold is met, and appropriate security. The asymmetry matters commercially: under-retention exposes you to AI Act enforcement in a band reaching up to 3% of total worldwide annual turnover, while over-retention of the same records exposes you to data protection enforcement in a band reaching up to 4%. There is no safe default of "keep everything forever".

What evidence actually satisfies this

• A written log schema that maps each recorded field to one of the three purposes in Article 12(2), with a note on why anything omitted is not needed.
• The provider's instructions for use, showing the documented mechanism for collecting, storing and interpreting logs — and a raised issue where it is absent.
• A retention rule for AI logs, distinct from your general IT log rule, stating the period, the justification for it, and the trigger for deletion.
• Contractual terms giving you export, retention and authority-access rights over vendor-held logs, surviving termination of the contract.
• A restore test: evidence that you have actually retrieved a specific historic decision end to end, not merely that a log store exists.
• Records showing who has access to the logs and on what basis, given they contain personal data about employees.
• Chain-of-custody and integrity controls sufficient that a log can be relied on as evidence rather than merely produced.

The limits of this guidance

This is a general explanation of a duty, not advice on your system. Three things in particular cannot be resolved from a page like this. First, whether your system is high-risk at all — classification under Article 6 and Annex III, and any exemption claimed under Article 6(3), is a fact-specific analysis that changes everything downstream. Second, the correct retention period above the six-month floor, which depends on the claims and sectoral rules your organisation is exposed to and is a legal judgement rather than a technical one. Third, the detail of what your logs must contain, where the Act is deliberately open-textured, the relevant harmonised standards are not yet settled, and Commission implementing measures on post-market monitoring may change what a defensible schema looks like.

Take specialist advice where you are in regulated financial services, where the system touches law enforcement or migration contexts, where you may have crossed the Article 25 line into provider status, or where an authority or an individual has already asked for records you are not confident you can produce. Where the Act is uncertain, document the reasoning you applied and the date you applied it. A recorded, reasoned position that later needs updating is a far stronger place to be than a confident position with nothing behind it.