What record-keeping and logging does Article 12 require?

What must a system record automatically?

The system must be capable of automatically recording events relevant to its operation, in a form that can be used after the event to understand what happened. The relevant events depend on the intended purpose and the risks identified, but in outline they include the inputs and outputs that influenced a consequential operation, the timing and sequence of operations, and any relevant human oversight action. Logging should be designed into the system, not added as an afterthought that captures only error messages. The design should record what was decided, on what basis, and by whom or by what process, to the extent needed for traceability. A log that records only that the system ran, without the inputs and outputs that mattered, will not support the post-market and oversight work that Article 12 is meant to enable.

How should logs be designed for traceability?

Traceability means that a later reviewer can reconstruct a particular operation from the log, the documentation, and the version in use at the time. Log design should therefore include identifiers that link a log entry to the system version, the deployment, the affected case or transaction where appropriate, and the relevant oversight action. Timestamps should be consistent and reliable, and log entries should be protected against unauthorised alteration or deletion. The provider should document the log schema, the events recorded, the retention approach, and the access controls, in the technical documentation. Deployers should know how to access logs for their deployment, what they contain, and what they must not alter. A log that cannot be linked to a version or a case is a record in name only.

For the broader regulatory framework, see High-risk requirements overview.

Who keeps logs, and for how long?

Both provider and deployer record-keeping provisions are relevant, and they should be checked in the consolidated text for the system in question. Providers must keep logs and related records available as part of their documentation and post-market duties, and deployers of high-risk systems must keep automatically generated logs under their control for a period set by Article 26, subject to the conditions in that article. The period and the conditions should be recorded for each deployment, together with the storage location, access controls, and handover arrangements. Personal data in logs must be handled in accordance with data protection law, with minimisation and access controls applied. A retention plan that states a period without stating where logs are held, who can access them, and how they are protected will not be sufficient if an authority or an affected person asks for the record.

How do logs support post-market monitoring?

Logs are a primary input to post-market monitoring under Article 72. They allow a provider to detect performance drift, recurring errors, unexpected inputs, and patterns that suggest a new risk. The monitoring plan should state which log signals are reviewed, how often, by whom, and what threshold triggers investigation or corrective action. Log review should be linked to the risk management file, so that a pattern found in logs leads to a risk reassessment where appropriate. Deployers should feed operational observations back to the provider through the channel agreed for that system, and providers should record what was received and what action followed. Monitoring that collects logs but never reviews them, or reviews them without a link to risk and corrective action, does not meet the purpose of the requirement.

How do logs support oversight and incidents?

Human oversight under Article 14 and serious incident reporting under Article 73 both depend on reliable logs. An overseer who needs to intervene, override or halt a system needs a record of what the system did and why, and an incident investigation needs a record that can establish the sequence of events. Log design should therefore support both real-time oversight and retrospective investigation, without requiring the overseer to reconstruct the operation from unrelated systems. Where an incident is reported, the relevant logs should be preserved, secured, and made available through the proper channel, with a record of who accessed them. The incident file should reference the log entries relied on, so that the investigation can be followed by a reviewer who was not present at the time.

Continue with Article 14 human oversight.

What does this guide not decide?

This guide does not decide what events a particular system must log, how long its logs must be kept, or whether a log set is sufficient for a specific investigation. It does not set a log schema, a retention period, or a data protection assessment for any deployment. Those questions depend on the system's intended purpose, the risks identified, the consolidated Articles 12 and 26, and data protection law as it applies to the logs. A provider and deployer should agree the logging and retention arrangements for each system in writing, confirm them with a competent authority or legal adviser where contested, and test that logs can actually be retrieved and understood when needed.

Frequently asked questions

Continue through this AI Act cluster

• High-risk requirements overview
• Article 14 human oversight
• Evidence chains for high-risk requirements
• Deployer responsibilities
• EU database and registration overview
• What risk management system does Article 9 require?