What are the logging and record-keeping requirements under the EU AI Act?

Updated 9 August 2026 for Regulation (EU) 2026/1744.

High-risk AI systems must "technically allow for the automatic recording of events (logs) over the lifetime of the system" under Article 12. Article 19(1) then requires providers to keep those logs for at least six months, and Article 26(6) sets the same floor for deployers.

Quick answer

• The design duty: Article 12(1) — the system itself must "technically allow for the automatic recording of events (logs)" over its lifetime. This is a product requirement, not a retention policy.
• What to log: Article 12(2) defines logging by purpose — traceability "appropriate to the intended purpose" — not by an event catalogue. A minimum event list exists only for remote biometric identification (Article 12(3)).
• Provider retention: logs under the provider's control, for a period appropriate to the intended purpose, "of at least six months" (Article 19(1)).
• Deployer retention: the same six-month floor for logs under the deployer's control (Article 26(6)).
• From when: these rules apply from 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems high-risk under Article 6(1) and Annex I (Article 113, third paragraph, point (c), as amended by Regulation (EU) 2026/1744).

What does Article 12 require the AI system itself to do?

Article 12(1) requires that "high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Three words carry the weight: "technically allow" makes this a capability built into the system, not a policy; "automatic" rules out manual note-taking as a substitute; "lifetime" means the capability cannot be switched off after launch.

Article 12 sits in Section 2 of Chapter III, so it is one of the requirements the provider must ensure are met under Article 16, point (a). Keep the boundary with its neighbour clear: Article 12 is about traceability of the system's functioning; the information a provider owes deployers is Article 13's transparency requirement, a separate obligation with separate content.

Which events do the logs have to capture?

Article 12(2) answers by purpose, not by list. Logging capabilities must ensure "a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system," recording events relevant for three things:

• Article 12(2), point (a) — risk and modification signals: "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." Article 79(1) risks are risks "to the health or safety, or to fundamental rights, of persons"; "substantial modification" is the defined term in Article 3, point (23) — a post-market change not foreseen in the initial conformity assessment that affects Section 2 compliance or changes the intended purpose.
• Article 12(2), point (b) — post-market monitoring: "facilitating the post-market monitoring referred to in Article 72," the monitoring system every provider must establish and document. Logs are its main data feed.
• Article 12(2), point (c) — deployer monitoring: "monitoring the operation of high-risk AI systems referred to in Article 26(5)" — the deployer's duty to monitor operation on the basis of the instructions for use.

The Act publishes no general event catalogue; outside Article 12(3), what to log is an engineering judgement defended against these three purposes. The Article 40 harmonised standards expected to concretise this were still incomplete at the time of writing — until they land, document why your event set serves each purpose.

What extra logging applies to remote biometric identification?

For systems under point 1(a) of Annex III — remote biometric identification systems, which that point expressly distinguishes from biometric verification whose sole purpose is confirming a person is who they claim to be — Article 12(3) sets a floor. The logging capabilities "shall provide, at a minimum":

• Article 12(3), point (a): "recording of the period of each use of the system (start date and time and end date and time of each use)";
• Article 12(3), point (b): "the reference database against which input data has been checked by the system";
• Article 12(3), point (c): "the input data for which the search has led to a match";
• Article 12(3), point (d): "the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5)" — the two-person rule, which Article 14(5) disapplies for law enforcement, migration, border control and asylum where Union or national law considers it disproportionate. See the human oversight guide.

This is the only place Article 12 names concrete log fields. For every other high-risk system, the purposes in Article 12(2) govern.

How long must providers keep the logs?

Article 19(1) requires providers to "keep the logs referred to in Article 12(1), automatically generated by their high-risk AI systems, to the extent such logs are under their control." The period must be "appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law, in particular in Union law on the protection of personal data."

Read that sentence as three moving parts. Six months is a floor, not a target — "appropriate to the intended purpose" can demand longer. The "unless provided otherwise" clause means other law can move the period in either direction, and the text singles out data protection law: where logs contain personal data, storage-limitation rules are not overridden — reconcile the two retention clocks in writing. And "under their control" scopes the duty: a provider does not breach Article 19 over logs that only ever exist on a customer's infrastructure.

The retention duty is anchored twice more. Article 16, point (e) lists it among the core provider obligations — "when under their control, keep the logs automatically generated by their high-risk AI systems as referred to in Article 19." And under Article 21(2), providers must, "upon a reasoned request by a competent authority," give that authority, "as applicable, access to the automatically generated logs of the high-risk AI system referred to in Article 12(1), to the extent such logs are under their control" — so store them retrievably, not in cold storage nobody can query.

Do not confuse this clock with documentation keeping: Article 18(1) requires the provider to keep the technical documentation and related records "for a period ending 10 years after" market placement or putting into service — a separate duty covered in the technical documentation guide.

Providers that are financial institutions "subject to requirements regarding their internal governance, arrangements or processes under Union financial services law" maintain the logs "as part of the documentation kept under the relevant financial services law" (Article 19(2)) — the duty is discharged through that framework, not waived.

What must deployers do with logs under Article 26(6)?

Article 26(6) mirrors the provider rule: deployers "shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data." The second subparagraph gives deployers that are financial institutions the same route as Article 19(2): logs kept as part of the financial-services documentation.

The control test does the allocation work. In a typical SaaS setup the provider holds most logs; in a self-hosted deployment they sit on the deployer's infrastructure and Article 26(6) does the heavy lifting. The Act does not assign log types to roles beyond that test — sort out in the contract who controls what, before an authority asks.

Retention is not the deployer's only stake in the logs. Article 12(2), point (c) exists so the deployer can discharge Article 26(5), which puts two duties in one sentence: deployers "shall monitor the operation of the high-risk AI system on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72." Monitoring is what the logs are for; informing the provider is what the monitoring is for. A deployer that keeps six months of logs but never looks at them has met Article 26(6) and missed both limbs of Article 26(5).

What this means for you

If you're a provider: Treat Article 12 as a design ticket: automatic logging built in, event coverage argued against the three purposes of Article 12(2), the Article 12(3) minimum implemented if you fall under point 1(a) of Annex III. Then set retention — a documented period of at least six months, justified as appropriate to the intended purpose and reconciled with data protection law — and keep logs retrievable for an Article 21(2) request. All of this applies from 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 for the Article 6(1) and Annex I route (Article 113, third paragraph, point (c)); the high-risk obligations overview maps the full set. Complipath's requirements checklist tracks every obligation the classification triggers, with status, owner, evidence link and notes — including who owns log retention and where the evidence lives.

If you're a deployer: Establish which logs are under your control — that phrase, not your role, defines your Article 26(6) duty — and keep them at least six months. Then use them: Article 26(5) monitoring is the reason Article 12(2), point (c) put deployer-relevant events in the logs at all. If you are a financial institution, route retention through your existing financial-services documentation. Unsure which role you hold — or whether you hold both? Start with provider vs deployer.

Which of your systems must keep logs?

Classify your system now — 7 questions on the main line, plus follow-ups where they apply, no account, and the classification runs in your browser: answers stay there unless you choose to keep the result.

FAQ

How long must AI system logs be kept under the EU AI Act? At least six months — for providers under Article 19(1) and deployers under Article 26(6), each for logs under their control, for "a period appropriate to the intended purpose of the high-risk AI system, of at least six months". Other Union or national law, in particular data protection law, can change the period in either direction.

Does the AI Act list exactly which events a high-risk system must log? Only for remote biometric identification: Article 12(3) sets a four-item minimum for systems under point 1(a) of Annex III. For all other high-risk systems, Article 12(2) defines logging by purpose — risk identification, post-market monitoring and deployer monitoring — not by an event catalogue.

Who keeps the logs — the provider or the deployer? Both, split by control. Article 19(1) binds providers "to the extent such logs are under their control"; Article 26(6) applies the same test to deployers. In a typical SaaS deployment the provider holds most logs; self-hosted, the deployer does. Allocate control contractually before an authority asks.

Are financial institutions exempt from AI Act log-keeping? No. Article 19(2) lets providers that are financial institutions maintain the logs as part of the documentation kept under the relevant financial services law, and Article 26(6) gives deployers the same route. The duty is discharged through the existing framework — it is not waived.

Sources: Regulation (EU) 2024/1689 (EUR-Lex), Articles 3, 12, 14, 16, 18, 19, 21, 26, 72, 79 and 113, and Annex III, as amended by Regulation (EU) 2026/1744 (EUR-Lex), which replaced Article 113, third paragraph, point (c). Articles 12, 19 and 26 are themselves unamended; only their date of application moved. The Article 40 harmonised standards expected to concretise the Section 2 requirements, including what event coverage satisfies Article 12(2), were still incomplete at the time of writing; the obligations apply regardless, and the adequacy of a logging design remains the provider's documented judgement until standards or case law say otherwise.