Record-keeping should make one system version traceable across its registration entry, technical documentation, automatically generated logs, quality management records and post-market monitoring findings, using a shared system identifier. High-risk providers must keep technical documentation and logs as the Act requires, deployers must retain logs under Article 26, and registration entries must be kept accurate for the version they describe. The evidence chain should show who decided what, on what source, on what date, and what triggered each review, so a later reviewer or authority can reconstruct the system's compliance history without relying on memory.
What records must a high-risk provider keep?
A high-risk provider must keep technical documentation as specified in Annex IV, together with the records that support conformity, including the quality management system records under Article 17, the post-market monitoring plan and findings under Article 72, and the registration information under Articles 49 and 71. High-risk systems must also be designed to allow automatic recording of events, or logs, while operating, in accordance with Article 12, and the provider must keep those logs under its control where the Act requires it. The documentation must be kept up to date and made available to authorities on request, for the period the Act specifies. A provider should therefore treat documentation as a product in its own right, with an owner, a version history and a review cycle, rather than as a file produced once for conformity assessment and then forgotten. Documentation that does not match the system version in use is worse than no documentation, because it misleads the reader who relies on it.
What records must a deployer keep?
A deployer of a high-risk system must, under Article 26, retain the automatically generated logs for a period appropriate to the intended purpose of the system, subject to the provision's conditions, and must use the system in accordance with the provider's instructions, assign human oversight and monitor operation. The deployer should also keep its own deployment record: the system and version used, the provider entry selected, the registration of its use where Article 49(3) applies, the oversight assignments, the training given, and any incidents, complaints or performance issues observed. Those records allow the deployer to answer an authority, a provider or an affected person about how a particular decision was reached, and they provide the feedback the provider needs for post-market monitoring. A deployer that keeps no record of its own use cannot show that it followed instructions, and cannot contribute meaningfully to the provider's monitoring system.
For the broader regulatory framework, see EU database, registration and post-market monitoring.
How should the records be linked?
Records should be linked by a shared identifier for the system version, carried consistently across the registration entry, the technical documentation, the logs, the quality management records, the monitoring plan and the incident log. The link should be explicit: each record should cite the system identifier and version, the provision it supports and the date it was last reviewed. A change to any record should trigger a check of the linked records, so a new version, a new intended purpose or a new deployer use does not leave a stale entry in one part of the chain. The practical tool is a single lifecycle index per system version, listing each record, its owner, its location and its review date, maintained by a named person. That index is an internal control, not a legal document in its own right, but it is what makes the evidence chain usable when it is needed, rather than a collection of files that must be reconstructed under pressure.
How long should records be kept, and in what form?
Retention periods and form depend on the provision concerned and on other applicable law, and they should be checked in the consolidated text and in the organisation's retention schedule before any record is destroyed. Technical documentation, conformity records and logs have different retention rules, and data protection law can limit how long personal data in logs and monitoring data may be kept. Records should be kept in a form that is complete, legible and retrievable, with access controls that protect personal data and confidential information while allowing an authority to obtain what it is entitled to see. A record that cannot be found, cannot be read or has been overwritten without a preserved earlier version does not support a compliance claim. The retention decision for each record type should therefore be written down, with the legal basis, the period and the destruction method, and applied consistently across the portfolio.
What makes a record useful to an authority?
A record is useful to an authority when it answers, without further investigation, what was decided, by whom, on what evidence, on what date and under which provision. That requires the record to be contemporaneous, attributed, dated and sourced, with the reasoning visible rather than only the conclusion. A classification record that states only that a system is not high-risk, without the Annex III analysis and evidence, does not help an authority assess the conclusion. A monitoring record that lists data without analysis or disposition does not show that monitoring was effective. A registration record without a submission date does not show that registration happened before market placement. The test for every record should therefore be whether a reviewer who was not involved in the original decision could reconstruct it from the record alone. If the answer is no, the record should be improved before it is needed.
Continue with registration timing and updates.
What does this guide not decide?
This guide does not set retention periods, does not prescribe a particular record-keeping tool or format, and does not decide which records a specific provider or deployer must keep for a specific system. Those matters depend on the system's classification, the operator role, the provisions engaged and other applicable law, and they require the consolidated text and the organisation's legal advice to be applied to the facts. The guide also does not cover legal privilege, trade secret protection or data subject rights in relation to records, which need separate advice. Where record-keeping is designed for a high-risk system, confirm the retention, access and disclosure position with a competent authority or legal adviser, and keep the design decision with the system's compliance record.
Frequently asked questions
Must logs be kept by both provider and deployer?
High-risk systems must support automatic event recording under Article 12, providers must keep logs under their control where required, and deployers must retain automatically generated logs for an appropriate period under Article 26. The exact duties depend on the provision and the deployment.
Is the EU database entry enough as a compliance record?
No. The entry is one link in the chain. Technical documentation, conformity records, logs, quality management records and monitoring findings are separate records that must describe the same system version and be kept together.
How should a change be recorded across linked records?
By a shared system version identifier, a dated change record showing what changed, who approved it, and which linked records were checked and updated. Earlier versions should be preserved rather than overwritten.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689, as amended ↗AI Act Service Desk: Article 49 registration ↗AI Act Service Desk implementation timeline ↗