Why AI logging matters
When a regulator, a court or a customer asks what an AI system did on a particular day, the answer comes from the logs or it does not come at all. That is why the EU AI Act treats logging as a substantive requirement rather than IT housekeeping, and splits the duty across three provisions addressed to two parties. Article 12 requires the system to be capable of logging, Article 19 requires the provider to keep the logs, and Article 26(6) requires the deployer to keep them. Each uses the same qualifying phrase, “under their control”, and that phrase is where most of the practical difficulty lives.
None of these obligations applies yet. Regulation (EU) 2026/1744, the Digital Omnibus on AI, moved the application of Chapter III, Sections 1, 2 and 3 to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for those classified under Article 6(1) and Annex I. Articles 12, 19, 21 and 26 all sit inside those sections, and none was amended by the Omnibus. The delay is nevertheless the wrong reason to postpone the work, because logging is the requirement that cannot be retrofitted. A system placed on the market without the right logging design cannot produce evidence about its early operation later.
What Article 12 actually requires
Article 12(1) is a design duty on the system: high-risk AI systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system”. Note what it is not. It is not a duty to retain anything and does not prescribe a log format; it requires that the capability exist. Sitting in Chapter III Section 2, it is discharged by the provider, who must build it in before the system is placed on the market.
Article 12(2) then sets the standard by which the capability is judged. The logging capabilities must enable the recording of events relevant for identifying situations that may result in the system presenting a risk within the meaning of Article 79(1) or in a substantial modification, for facilitating the post-market monitoring referred to in Article 72, and for monitoring the operation of the system as referred to in Article 26(5). All of this is measured against “a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system”. The test is proportionate and purpose-relative, and there is no mandated log schema for high-risk AI generally, so the provider must reason from those three purposes to a design and be able to explain the reasoning.
Who keeps what, and for how long
The capability duty in Article 12 is only the beginning. Minimum log content and the retention duties sit in separate provisions and are not identical.
The extra content for biometric identification systems
Article 12(3) imposes a minimum log content, but only for the remote biometric identification systems in Annex III point 1(a). For those, the logging capabilities must provide at least the period of each use with start and end times, 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 verifying the results under Article 14(5). That last item is the audit trail for the four-eyes rule in Article 14(5), which requires that no action be taken on the basis of an identification unless it has been separately verified and confirmed by at least two competent natural persons. The log has to name them.
The provider’s retention duty
Article 19(1) requires providers to keep the logs referred to in Article 12(1), automatically generated by their systems, 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”. Article 19(2) carves financial institutions into their existing regime: those subject to internal governance requirements under Union financial services law maintain the logs as part of the documentation kept under that law.
The deployer’s retention duty
Article 26(6) mirrors the provider’s duty almost word for word. Deployers keep the logs automatically generated by the system, to the extent such logs are under their control, for a period appropriate to the intended purpose, of at least six months, unless other Union or national law provides otherwise, in particular data protection law. These are two independent duties on two separate copies, so provider and deployer can lawfully end up with different retention periods and different log content.
Six months is a floor, not the answer
The most common misreading of both provisions is to treat six months as the retention period. The text requires a period appropriate to the intended purpose, of at least six months, so where the purpose implies a longer accountability horizon six months is not compliant. A credit scoring system whose decisions can be challenged years later, or an employment tool feeding decisions subject to labour law limitation periods, points to a longer period. Six months as a default policy is a decision to be justified against the purpose, not a safe harbour.
The gap the Regulation leaves open
All three provisions are qualified by “under their control”, and the Regulation nowhere defines control over logs. In a traditional on-premise deployment the deployer holds the logs and Article 19 does relatively little work. In a cloud, API or software-as-a-service deployment the position inverts: the provider hosts and controls the logs, the deployer controls nothing, and the deployer’s Article 26(6) duty shrinks close to nothing while the provider carries the whole retention burden.
That looks convenient until an authority asks the deployer to demonstrate compliance with Article 26. Nothing obliges the provider to give the deployer access to the logs, and nothing obliges the deployer to contract for them, so the gap has to be closed commercially. Article 21 reinforces the point from the other direction: on a reasoned request from a competent authority, providers must supply the information necessary to demonstrate conformity, in an official EU language indicated by the Member State concerned, and give access to the Article 12(1) logs to the extent those logs are under their control. That duty falls on the provider alone; there is no mirror-image obligation on deployers, whose exposure is evidential rather than custodial.
Practical example
A Swedish niche bank buys a credit scoring system from a European vendor and runs it as a hosted service. Creditworthiness assessment sits in Annex III point 5(b), so the system is high-risk and Finansinspektionen is the Swedish market surveillance authority for it. The bank is the deployer; the vendor is the provider. The logs live entirely in the vendor’s infrastructure.
Read literally, the bank’s Article 26(6) duty is close to empty, because no logs are under its control. That is an uncomfortable position for a supervised institution. If a rejected applicant complains, or Finansinspektionen asks how the model treated a cohort in a given quarter, the bank must obtain the record from the vendor on the vendor’s terms. The fix is contractual and belongs in the procurement documents rather than in a later dispute: a right to export logs in a usable format, a retention period on the vendor’s side at least as long as the bank’s own, a duty to preserve logs on notice of a complaint, and clarity on what the system logs at all, which the provider must in any event describe in the instructions for use under Article 13. As a financial institution, the bank should also check how the AI logs interact with the record-keeping it already owes under financial services law, which will usually run far longer than six months.
Common mistakes companies make
The first is reading six months as the retention period rather than as the statutory minimum, and writing it into a policy without ever testing it against the intended purpose. The second is assuming that because the vendor hosts the system the deployer has no logging exposure; the duty may be narrow, but the evidential need is not. The third is treating the AI Act as authority to keep logs indefinitely. Both Article 19(1) and Article 26(6) end by deferring to other Union or national law, in particular data protection law. The AI Act does not override the GDPR storage limitation principle; it yields to it. The fourth is logging everything on the theory that more is safer, which collides with data minimisation and with the proportionate standard in Article 12(2). The fifth is designing logs for engineers rather than the three purposes in Article 12(2), so that when a regulator asks a traceability question the logs answer a debugging question. The sixth is deleting on schedule after a complaint has arrived, when a hold should have stopped the routine.
Recommended actions
Providers should start from Article 12(2) and work backwards. Write down what events must be recoverable to detect a risk situation or a substantial modification, to feed post-market monitoring, and to let deployers monitor operation, then design the log content to those questions and record the reasoning in the technical documentation. Set a retention period derived from the intended purpose and justify it in writing, and if you operate a hosted service, decide now what you will expose to deployers, because that is what customers will negotiate for.
Deployers should treat log access as a procurement issue. Ask the provider what the system logs, where they sit, who controls them, how long they are kept and how they can be exported, and put the answers in the contract rather than a sales email. Then align the retention period with your own data protection documentation. Logs from a high-risk system are usually personal data, both about the people it assesses and about the staff who operate it. Integritetsskyddsmyndigheten’s guidance on säkerhetsloggning och logganalys notes that logging generally involves processing personal data and must be designed with the rights of those recorded in mind, balancing detail, minimisation and storage time. It prescribes no fixed period, which is why the decision has to be documented.
Frequently asked questions
Do we have to keep AI logs for exactly six months?
No. Both Article 19(1) and Article 26(6) require a period appropriate to the intended purpose of the high-risk AI system, of at least six months. Six months is the minimum, not the standard. If the intended purpose means decisions can be questioned or challenged for longer, the appropriate period is longer and a six-month policy would not comply. Both provisions also defer to other Union or national law, which can require a longer period or earlier deletion.
Our AI system is hosted by the vendor. Do we still have a logging duty?
Your duty under Article 26(6) extends only to logs under your control, so where the vendor hosts everything the duty may be very limited in scope. That is not the end of the analysis. You remain responsible for monitoring operation under Article 26(5), for informing affected people under Article 26(11) where that applies, and for demonstrating your own compliance if a market surveillance authority asks. Without contractual access to the vendor’s logs you may have no way of doing any of that, so negotiate access even though the statutory duty is narrow.
Does the GDPR conflict with the AI Act on log retention?
Less than it first appears, because the AI Act resolves the tension in the GDPR’s favour. Article 19(1) and Article 26(6) both apply “unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data”. So where storage limitation requires earlier erasure, the six-month floor gives way, and the AI Act is not a legal obligation licensing indefinite retention. In practice the answer is usually to reduce what is logged rather than how long it is kept.
Conclusion
The AI Act’s logging regime is easy to underestimate because it is spread across four articles and never states a single rule. Read together, they require a system designed to log the right events, a provider and a deployer that each keep what they control, and an authority that can compel production from the provider on a reasoned request. Two questions decide almost every real case: who controls the logs, and what period the intended purpose demands. Both are best answered in the design and the contract, well before the 2027 and 2028 dates. Lawgent helps businesses design AI logging and retention policies and negotiate log access in AI contracts.
