EU AI Act Article 12: Logging and Transparency for High-Risk AI Systems

What the EU AI Act Says

Article 12 of the EU AI Act establishes mandatory automatic logging requirements for high-risk AI systems. The provision requires that high-risk AI systems are technically capable of automatically recording events throughout their entire operational lifecycle. These logs must contain sufficient detail to enable post-hoc traceability of decisions, detection of situations that may give rise to risks, and monitoring by competent authorities after the system has been placed on the market or put into service.

Article 12 does not operate in isolation. It connects directly to Article 9 (risk management), which requires providers to implement risk management systems throughout the AI system's lifecycle. Logging is one of the primary technical mechanisms through which risk management becomes auditable in practice. Article 12 also feeds into Article 17 quality management obligations, which require providers to maintain documented procedures covering the full lifecycle of a high-risk AI system, including post-deployment monitoring.

Who This Applies To

Article 12 applies to providers of high-risk AI systems as defined under Annex III of the EU AI Act. Annex III covers systems used in areas including biometric identification, critical infrastructure, education, employment, access to essential services, law enforcement, migration and border control, and administration of justice. If your AI product touches any of these domains and your customers are in the EU, Article 12 applies to you as the provider.

Deployers of high-risk AI systems also carry obligations under Article 12. Specifically, deployers must keep the logs generated by the system for a defined retention period. The division of responsibility between provider and deployer is important: the provider must build the logging capability into the system, while the deployer is responsible for retaining and protecting those logs once the system is in operation.

What the Obligation Requires Concretely

The logging capability required by Article 12 must cover at minimum the following categories of events:

• Each use of the system: Every instance in which the high-risk AI system is used must be recorded, including the date, time, and reference data inputs that allowed the system to determine its output.
• Decisions and outputs: The system must log the outputs it produces, including where those outputs inform a consequential decision affecting a natural person.
• Identity of persons involved: Where relevant and technically feasible, the logs must capture information about the persons responsible for verifying the results or supervising the system's operation.
• Contextual data: For some categories of high-risk system, particularly those covered by Annex III points 1 and 6 (biometrics and law enforcement), the regulations require additional logging granularity around input data sets used for each session.

The retention period for logs held by deployers is a minimum of six months from the date of each use, unless applicable EU or national law requires a different retention period. For certain regulated sectors such as financial services or healthcare, sector-specific rules may extend this period significantly.

Competent market surveillance authorities have the right to access these logs. This is a direct audit right, not a voluntary disclosure mechanism. Product teams should treat log access as a certainty, not a remote possibility, when designing their logging architecture. Logs must be stored in a format that is readable and retrievable by a competent authority within a reasonable timeframe.

From a technical architecture perspective, your logging system needs to satisfy several properties. Logs must be tamper-evident or tamper-resistant, since authorities need to trust that records have not been altered after the fact. Logs must be structured enough to enable traceability of individual decisions back to inputs. And logs must be accessible to deployers without requiring provider involvement, since deployers carry independent retention obligations.

Product teams should also consider the interaction between Article 12 logging and data minimisation obligations under the GDPR. Logging input data that includes personal information creates a potential tension, particularly for biometric or health applications. The recommended approach is to log decision identifiers and input references rather than raw personal data where possible, and to apply appropriate access controls and retention schedules to log storage.

Read more about the documentation requirements that sit alongside logging in Article 11 (technical documentation) and how these fit into your broader compliance programme in our CTO guide to the EU AI Act.

Key Deadlines

The compliance timeline for Article 12 depends on where your system sits within the EU AI Act's scope:

• Article 5 prohibited practices: Already in force since February 2 2025. If your system is near this boundary, that assessment should already be complete.
• GPAI model obligations and Article 50 transparency rules: In force from August 2 2026. GPAI providers face fines of up to EUR 15 million or 3% of global annual turnover for non-compliance, whichever is higher.
• Annex III high-risk AI systems (including Article 12): Compliance required by December 2 2027. This is the deadline that applies to most product teams building AI features in the domains listed above.

December 2 2027 may seem distant, but building compliant logging infrastructure into a live AI product is a non-trivial engineering project. Retrofitting logging into a system that was not designed for it is significantly harder than building it in from the start. Teams beginning new high-risk AI products today should design Article 12 logging as a first-class architectural requirement, not a compliance afterthought.

What to Do Now

The practical steps for product teams are:

1. Determine whether Annex III applies to your system. The scope question is the first and most important step. Not every AI product is high-risk under the EU AI Act. If you are not in scope, Article 12 does not apply to you.
2. Audit your current logging capability. Many engineering teams already log model inputs and outputs for debugging and monitoring purposes. Assess whether your existing logs would satisfy Article 12 requirements around completeness, retention, and accessibility to authorities.
3. Define the log schema. Decide what data fields your Article 12 logs will capture. Include at minimum: timestamp, session or request identifier, input data reference, output or decision, and operator identity where applicable. Document this schema in your technical documentation under Article 11.
4. Implement tamper-evident storage. Use an append-only log store or a signed log format that allows authorities to verify log integrity. Cloud audit log services from major providers typically satisfy this requirement.
5. Map your deployer obligations. If you sell to deployers who are themselves subject to Article 12 retention requirements, make sure your contracts and technical handover documentation address how deployers will access and retain logs after deployment.
6. Connect logging to your Article 9 risk management system. Logs are only useful if someone is monitoring them. Build a process for reviewing log anomalies as part of your ongoing risk management cycle.

Use the free ActComply risk screener to check your obligations: https://www.getactcomply.com/check