Art. 19 EU AI Act: keeping the automatically generated logs
Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.
Updated: June 2026
This is an explicit providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → obligation under the EU AI Act. It is the provider's retention duty for the logs it controls; the matching deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → duty sits in Art. 26.6.
Introduction: the retention half of the logging obligation
Art. 12 requires high-risk AI systems to generate logs. Art. 19 requires that those logs are kept. The two articles are halves of the same control: a logging capability that produces records nobody retains is as useless as no logging at all, and a retention duty for records that were never generated is meaningless. Read together, they ensure that when an incident, a complaint, or an audit arises, the evidence of what the system did is still available.
Art. 19 places the retention duty on the provider, for the logs that are under the provider's control. The parallel duty for deployers sits in Art. 26.6. Which logs fall under whose control depends on the deployment: in a cloud-hosted system the provider may retain much of the operational logging, while in an on-premise deployment the deployer holds it. The two duties are complementary, and the practical task is to make sure that, between provider and deployer, every relevant log is retained by someone.
What Art. 19 requires
Providers must keep the automatically generated logs referred to in Art. 12, to the extent those logs are under their control, for a period that is appropriate to the intended purpose of the high-risk AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → and at least six months, unless provided otherwise in applicable law, in particular Union law on the protection of personal data.
The phrase "appropriate to the intended purpose" matters: six months is a floor, not a ceiling. A system whose decisions can be challenged or investigated long after the fact, such as one used in credit or employment, may warrant a longer retention period so the evidence survives as long as the decision can be contested. The provider sets the period by reasoned judgement against the use case and documents it.
The interaction with data protection
Art. 19 contains its own tension with the GDPR, the same tension that runs through Art. 26.6. The logs frequently contain personal data, and the GDPR requires that personal data is not kept longer than necessary. Art. 19 resolves the tension by carving out "unless provided otherwise in applicable law, in particular Union law on the protection of personal data": the retention duty does not override data protection, it operates within it. In practice this means pseudonymising the personal data in the logs where possible, so the traceability the logs provide is preserved while the privacy exposure is reduced.
Why it matters
For the provider, Art. 19 is the obligation that makes the rest of the accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress — never the system itself.Open full entry → framework provable over time. The logs are the evidence base for demonstrating that the system performed as documented, for investigating an incident, and for cooperating with a supervisory authority. A provider who generates logs under Art. 12 but fails to retain them under Art. 19 has the capability without the evidence, which is the same as having neither when a question arises months later.
Governing log retention
The control is a retention schedule that names, for each high-risk system, which logs are retained by the provider and which by the deployer, for how long, and on what basis the period was chosen. The schedule reconciles the six-month floor with the GDPR minimisation principle through pseudonymisationpseudonymisationReplacing identifying fields so data can't be attributed to a person without separate information — a minimisation and security technique that keeps data personal under GDPR.Open full entry →, and it is reviewed when the system, its use, or the applicable law changes.
The provider and deployer confirm, ideally in the contract, who retains which logs, so that no relevant log falls into a gap between the two retention duties. The retention itself is protected against alteration, because a retained log that can be edited does not serve its evidentiary purpose.
Compliance checklist
- Is there a retention schedule that covers the automatically generated logs of each high-risk system?
- Does it allocate retention between provider (Art. 19) and deployer (Art. 26.6) so no relevant log is unretained?
- Is the retention period at least six months, and longer where the use case warrants it, with the period documented?
- Is the retention reconciled with the GDPR through pseudonymisation of personal data in the logs?
- Are the retained logs protected against alteration?
- Is the allocation of retention duties confirmed contractually between provider and deployer?