Article 12(1) requires high-risk AI systems to technically allow for the automatic recording of events over the system’s lifetime. Three things drive what “events” means here, per Article 12(2): the logs have to support identifying situations where the system could present a risk, or has undergone a substantial modification, facilitating post-market monitoring under Article 72, and monitoring the deployer’s operation of the system under Article 26.
The word “automatic” is doing real work in this article. A process where an operator manually notes down decisions in a spreadsheet doesn’t satisfy Article 12, however diligently it’s maintained, because it isn’t a built-in capability of the system and it won’t reliably capture every event at volume. For systems that weren’t designed with this in mind, retrofitting audit-grade automatic logging is frequently a larger engineering task than the compliance requirement first suggests: it usually means capturing inputs, intermediate steps, outputs, and any human intervention as a structured, continuous stream, not a periodic export.
Special content requirements for biometric systems
For systems intended for biometric identification specifically, Article 12(3) sets a concrete minimum for what the logs must capture: the period of each use (start and end, date and time), the reference database checked against the input data, the input data for which the search produced a match, and the identity of the natural persons involved in verifying the result under the Article 14(4) two-person rule. This is the only place in the Act where log content is specified this precisely; for systems outside this category, the general traceability requirement in Article 12(2) applies more broadly, without a prescribed content list.
Two retention duties, two different parties, both directly finable
Two provisions govern how long the logs have to be kept, and they apply to different parties in the relationship.
| Provider (Article 19) | Deployer (Article 26(6)) | |
|---|---|---|
| What’s covered | Logs under the provider’s control | Logs under the deployer’s control |
| Minimum retention | 6 months | 6 months |
| Can be extended by | Other Union or national law (e.g. data protection law) | Other Union or national law |
| Financial institution carve-out | Can fold into existing internal governance documentation | Can fold into existing internal governance documentation |
| Fine exposure | Named directly in Article 16(e), reached through the Article 16 tier | Named directly within Article 26, reached through the Article 26 tier |
Both retention duties are more exposed than they might first appear. Article 19 sits in Chapter III, Section 3, rather than Section 2, so it isn’t caught by Article 16’s general “ensure compliance with Section 2” clause the way Article 12’s logging capability is. It doesn’t need to be: Article 16 has its own specific limb, Article 16(e), which separately names keeping the Article 19 logs as one of the provider’s enumerated duties. Since Article 16 itself carries the full €15 million or 3%-of-turnover fine tier under Article 99(4)(a), a provider’s failure to retain logs under Article 19 is directly, not just indirectly, exposed at that level. Article 26(6) needs no such route at all, since it’s simply part of Article 26, which is named outright in Article 99(4).
A provider and a deployer can each be holding a different slice of the same system’s logs, depending on the deployment architecture. Where a provider hosts the model and the deployer only consumes an API, the provider is likely to control most of the raw event log, and the deployer’s Article 26(6) duty attaches to whatever subset is actually exposed to them. This is worth clarifying contractually rather than assuming, since “the logs are under the provider’s control” is doing real legal work in both articles.
Six months is a floor, and it can move in either direction
None of Article 12, 19, or 26(6) sets a maximum. The recurring phrase across all three is “appropriate in light of the intended purpose,” and that has teeth in practice. A credit-scoring system that becomes the subject of a discrimination complaint two years after a lending decision isn’t well served by a six-month retention window, and organisations with existing sector-specific record-keeping obligations, banking supervision, insurance solvency documentation, medical device vigilance, should treat those as the operative floor rather than the AI-specific six months.
The direction isn’t only “longer,” though. Article 19’s own text flags data protection law as a specific source of a different requirement, and that cuts both ways. GDPR’s storage limitation and data minimisation principles can push in the opposite direction for the personal-data portions of a log: keeping full inference records, including inputs and outputs that contain personal data, for longer than necessary creates its own GDPR exposure. For an insurer or bank whose logs are full of personal data by default, this is a genuine tension rather than a one-directional “keep everything longer to be safe” answer, and it’s worth a specific conversation between compliance and data protection teams rather than assuming the AI Act’s minimum and GDPR’s principles point the same way.
A worked example: Reconstructing a decision
Take a bank running a credit-scoring model. Fourteen months after a lending decision, a rejected applicant files a discrimination complaint. To respond credibly, the bank needs to reconstruct exactly what happened: the inputs the model received, the score it produced, whether a human reviewer looked at the case, and what that reviewer decided, the same reviewer whose oversight function is what Article 14 and GDPR Article 22 both require to be genuine. If the bank’s log retention followed only the Article 26(6) six-month floor, that record no longer exists. If instead the bank had assessed, correctly, that “appropriate to the intended purpose” for a credit decision meant a longer retention window, consistent with its existing regulatory record-keeping obligations, the reconstruction is straightforward. This is the practical difference between treating six months as a target versus treating it as a floor.
Record-keeping compliance checklist
- Automatic logging built into the system architecture from the start, not added as a post-hoc export
- Logs capture, at minimum: timestamps, inputs, outputs, and any human interventions or overrides
- For biometric identification systems specifically: usage period, reference database, matched input data, and verifier identity captured (Article 12(3))
- Logs are tamper-evident and access-controlled
- Provider-side retention policy set at minimum six months, checked against sector-specific law for a longer requirement (Article 19, reached directly through Article 16(e))
- Deployer-side retention policy set at minimum six months for logs under the deployer’s control (Article 26(6))
- GDPR data minimisation and storage limitation reviewed specifically for the personal-data content of logs, not assumed to automatically align with the six-month AI Act floor
- Contractual clarity established between provider and deployer on which party controls which portion of the log, where the deployment is API-based or third-party hosted
- Financial institutions: log retention mapped onto existing internal-governance documentation rather than run as a parallel process
- Logs available in a form that can be produced to a market surveillance authority on request
Deeploy: Continuous monitoring and insights
This sits close to the centre of what Deeploy’s platform is built for. Deeploy’s monitoring and insights capability captures inference logs, inputs, outputs, and model events automatically as a structured, auditable stream, stored under configurable retention policies rather than requiring a bespoke logging pipeline to be built around each model. For a deployer running third-party models via API, that also means having a clear, queryable record of the portion of the log actually under your control, precisely the ambiguity Article 26(6) leaves open, and a foundation for the post-market monitoring and human oversight obligations these same logs are meant to support.
Frequently asked questions
It can create tension in that direction. GDPR's storage limitation and data minimisation principles apply to the personal-data content of a log, and can push toward shorter retention for that content, even while the AI Act sets a six-month floor for the log's compliance purpose. This needs a specific assessment rather than an assumption that longer is always safer.
Both parties retain their own duty: the provider under Article 19 for logs under its control, the deployer under Article 26(6) for logs under its control. Where the boundary sits should be clarified contractually, since API-based deployments often mean the provider holds most of the raw log.
Yes. Article 16(e) specifically names keeping the Article 19 logs as one of the provider's enumerated duties, and Article 16 is directly listed in Article 99(4), carrying the €15 million or 3%-of-turnover tier.
No. Article 12(3)'s specific content requirements, usage period, reference database, matched data, verifier identity, apply only to biometric identification systems. Other high-risk systems are governed by the more general traceability requirement in Article 12(2).
