AI Record-Keeping
Follow topic LLM context A cited markdown file you can paste into your AI assistant (ChatGPT, Claude, a RAG or project knowledge base) to ground it in this topic. Contains: the overview, key law text, case law, enforcement and guidance for this topic. Everything links back to its source on overview.legal — legal information, not advice.The AI Act imposes specific record-keeping obligations for AI systems that are distinct from general GDPR record-keeping. A dedicated topic would capture AI-specific documentation, logging, and record retention requirements that differ from traditional data protection record-keeping.
Overview
12 sources · Jul 23, 2026Legal Framework
AI record-keeping obligations under the AI Act are anchored primarily in Articles 11 and 12, which impose documentation and logging requirements that are structurally distinct from GDPR Article 30 record-keeping. Article 11 requires providers of high-risk AI systems to draw up and maintain technical documentation demonstrating compliance with the requirements set out in Chapter III of the Act, before the system is placed on the market. The documentation must enable national competent authorities and notified bodies to assess conformity with the Act's requirements. Annex IV prescribes the specific content, covering system architecture, training data descriptions, design specifications, and risk mitigation measures.
Article 12 imposes a separate obligation to ensure that high-risk AI systems are technically capable of automatically recording events (logs) while operating. These logs must enable post-hoc monitoring of the system's functioning relative to the intended purpose and must be retained for a period appropriate to the system's purpose and complexity. This is not a processing-records obligation but a technical capability and retention requirement embedded in the system itself.
Recital 109 introduces a proportionality principle for general-purpose AI model providers, signalling that compliance burdens should scale with provider size and model risk profile. SMEs and start-ups may benefit from simplified compliance pathways, though the substantive obligation to maintain adequate documentation remains.
Key Developments
No enforcement actions under the AI Act have yet materialised, given the phased application timeline. However, the GDPR enforcement landscape provides instructive parallels. The Dutch Data Protection Authority's approach to documentation deficiencies — particularly its emphasis on demonstrable accountability under Article 5(2) GDPR — signals how supervisory authorities are likely to approach AI Act technical documentation gaps. Regulators have consistently treated incomplete or generic documentation as evidence of non-compliance rather than mere administrative oversight.
The CJEU's jurisprudence on Article 22 GDPR (automated decision-making), including Schufa Holding v. BF, establishes that meaningful documentation of automated processing logic is a precondition for lawful deployment. This principle will likely transfer to AI Act enforcement: providers unable to produce coherent technical documentation tracing training data lineage, model behaviour, and risk mitigation will face structural compliance failures rather than marginal ones.
Practical Guidance
- Map your role before documenting anything. Article 11 obligations attach to providers; deployer obligations are narrower under Article 26. Misallocating documentation responsibilities between provider and deployer creates gaps that neither party fills.
- Build logging capability into the system architecture at design stage. Article 12 requires automatic event recording as a technical feature, not a manual process. Retrofitting logging capability after deployment will not satisfy the obligation and may itself constitute evidence of non-compliance.
- Align AI Act documentation with GDPR Article 30 records where overlapping. Where an AI system processes personal data, the technical documentation under Article 11 and the processing records under Article 30 GDPR should cross-reference each other, but must not be conflated — they serve different supervisory purposes and different authorities.
- Apply the proportionality principle from Recital 109 to documentation depth. For SME providers of general-purpose AI models, simplified documentation pathways are available, but the threshold for "simplified" is not defined — maintain substantive coverage of core risk areas even in abbreviated formats.
- Set retention periods by reference to system risk, not a fixed calendar. Article 12's "appropriate period" language requires a risk-based determination. High-risk systems used in law enforcement or biometric identification will demand longer retention than low-impact applications.