Art. 19 EU AI Act: keeping the automatically generated logs

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. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → obligation under the EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry →. It is the provider's retention duty for the logs it controlscontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry →; the matching deployerdeployerAn organization using an AI system under its own authority in its activities. It carries the 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 systemshigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry → 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 evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry → 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-riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → 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 judgment against the use case and documents it.

The interaction with data protection

Art. 19 contains its own tension with the GDPRGDPRRegulation (EU) 2016/679, the General Data Protection Regulation, the EU's law on the processing of personal data. It applies to AI wherever personal data enters training, inputs, outputs, or logs, and it operates alongside the EU AI Act rather than being replaced by it. See controller, processor, lawful basis, DPIA.Open full entry →, 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 privacyprivacyThe principle that personal data used by or produced through an AI system stays within the purpose and the legal basis it was collected for. Three routes cause most of the trouble: personal data in training material that was never intended for it, model output that reproduces what the model retained, and purpose creep, where a system built for one use drifts into another the original basis never covered. The GDPR governs this in full, and the EU AI Act adds data governance duties for high-risk systems (Article 10). See DPIA, purpose limitation, responsible AI.Open full entry → 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. The EU AI Act attaches obligations to the role rather than the technology, with provider duties in Article 16 and deployer duties in Article 26, supported by technical documentation (Article 11) and record-keeping (Article 12). See provider, deployer, record-keeping, responsible AI.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 minimization principleprincipleOne of the seven responsible-AI values a governed system should live up to (fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, human oversight). A principle is abstract: it states an outcome, not a lever you can pull. It becomes governable by naming the harm that would breach it, assessing the risk that harm carries, and placing controls against that risk. Held this way, a principle becomes a pillar. See pillar, harm, risk.Open full entry → through pseudonymizationpseudonymisationReplacing identifying fields so data can't be attributed to a person without separate information, a minimization 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

1. Is there a retention schedule that covers the automatically generated logs of each high-risk system?
2. Does it allocate retention between provider (Art. 19) and deployer (Art. 26.6) so no relevant log is unretained?
3. Is the retention period at least six months, and longer where the use case warrants it, with the period documented?
4. Is the retention reconciled with the GDPR through pseudonymization of personal data in the logs?
5. Are the retained logs protected against alteration?
6. Is the allocation of retention duties confirmed contractually between provider and deployer?