What the EU AI Act’s Article 12 Requires From Your Log Infrastructure

Article 12 of the EU AI Act requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. That word, technically, is doing significant work. It means the logging capability has to be built into or applied to the infrastructure running the system. A policy document, a manual export process, or a spreadsheet of audit notes does not satisfy the requirement. And where those logs live, who can access them, and how long they are kept are infrastructure decisions that determine whether your compliance posture holds up when a competent authority asks to see them.

Let’s consider this situation: an HR software company deploys an AI-powered CV screening tool for clients operating in EU member states. The system falls under Annex III of the EU AI Act, making it a high-risk AI system. Their current log setup sends application events to a managed cloud logging service billed per gigabyte, with a 30-day retention window before automatic deletion. They have no immutable storage layer. Their logs live in a US-headquartered cloud provider’s EU region. When their legal team asks what a regulatory audit would require, the answer is uncomfortable: the logs that would need to exist may already be gone, and the ones that remain are not configured to resist modification.

The infrastructure work required to fix that is not a small lift. It involves log architecture, retention policy, storage configuration, and data residency decisions, all of which need to be in place before enforcement applies to your system.

What Article 12 Actually Says

Article 12 of Regulation (EU) 2024/1689 reads: “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”

The article goes on to specify that logging capabilities shall enable recording of events relevant for:

Identifying situations that may result in the high-risk AI system presenting a risk, as defined in Article 79. Supporting post-market monitoring under Article 72. Monitoring the operation of high-risk AI systems as referred to in Article 26.

For remote biometric identification systems specifically, Article 12 sets a more detailed minimum: usage timestamps, the reference database against which input data was checked, the input data that produced a match, and the identities of the natural persons who verified results.

Article 19 covers providers: they must keep automatically generated logs for the minimum period appropriate to the system’s intended purpose, with a floor of six months unless other Union or national law requires longer. Article 26(6) sets the same six-month floor for deployers. Penalties for non-compliance with high-risk AI system requirements fall under Article 99 of the regulation, which the official EU AI Act text at EUR-Lex sets out in detail.

The regulation does not define a maximum retention period, and it does not specify log formats. What it specifies is that the logging must be automatic, that it must cover the lifetime of the system, and that it must produce records capable of supporting risk identification, post-market monitoring, and operational oversight when authorities request them.

Why This Is an Infrastructure Problem Before It Is a Software Problem

Most compliance frameworks create documentation obligations. Article 12 creates a technical obligation. The regulation does not ask whether you intend to keep logs. It requires that high-risk AI systems are built or operated in a way that makes automatic logging technically possible.

That distinction matters because it shifts responsibility onto the infrastructure layer. If your AI system runs in an environment where logs are automatically rotated and deleted, or where storage costs incentivize short retention windows, or where there is no mechanism to prove a log was not modified after it was written, you have an infrastructure problem before you have a software problem.

Three infrastructure properties are implied by Article 12 even though the regulation does not prescribe them explicitly:

• Automatic and continuous. Logging cannot be a periodic batch job or a triggered export. It has to be an inherent property of how the system operates. The infrastructure running the system needs to support write-on-event logging without manual intervention.
• Tamper-evident. The regulation requires logs that support risk identification and regulatory oversight. A log that can be modified after the fact does not serve that purpose. Regulators interpreting Article 12 expect logs to be credible, which practically means they need to resist modification. The infrastructure holding them needs to support immutable or write-once storage semantics.
• Long-duration. Six months is the statutory floor, but “lifetime of the system” is the actual framing. AI systems deployed for years generate logs that accumulate over years. The infrastructure needs to be designed for that volume and that duration without costs that create incentives to delete early.

None of those properties come automatically from a general-purpose cloud logging service with default settings.

What Compliant Log Storage Requires in Practice

Immutable Object Storage

The most direct infrastructure answer to the tamper-evidence requirement is write-once object storage. An object stored with a retention lock cannot be modified or deleted for the duration of the lock period. If a regulator asks for logs covering a specific window of the system’s operation, logs stored under a retention policy are retrievable in their original form.

Ceph, the open-source distributed storage system that OpenMetal deploys across all hosted private cloud environments, supports S3-compatible object storage with object locking. You can configure buckets with WORM (write once, read many) semantics, set retention periods at the bucket or object level, and write your AI system’s event logs directly to that storage layer. The logs are accessible via standard S3 API tools but cannot be deleted or overwritten during the retention window.

This is meaningfully different from a managed cloud logging service, where the provider controls the retention policy, the deletion behavior, and the underlying storage configuration, and where your access to proving the logs have not been modified is limited.

Access Control Between the AI System and the Log Store

Article 12 puts the logging obligation on the high-risk AI system. Article 26 puts monitoring obligations on deployers. Competent authorities have inspection rights. That creates a situation where multiple parties need controlled access to the same log data, with different levels of permission.

A private cloud environment gives you the network and identity layer to model that access cleanly. The AI system writes to the log store. Deployer personnel can read but not modify. Audit access for competent authorities can be scoped to specific log buckets or time ranges without giving access to other infrastructure. None of that requires a custom compliance platform, just a network and identity architecture that matches the access model the regulation implies.

OpenStack’s identity and access management through Keystone, combined with Ceph’s S3-compatible bucket policies, gives you the controls to build that model on infrastructure you administer directly.

Long-Duration Retention at Predictable Cost

Six months is the floor, but it is not a ceiling, and many AI systems will need to retain logs for the lifetime of the system, which could be years. A metered cloud storage model charges per gigabyte stored, with costs that grow as log volume accumulates over time. For high-throughput AI systems generating large event volumes, the cost curve becomes a retention-policy driver: teams shorten retention windows to manage storage bills rather than because the regulation permits it.

Fixed-cost dedicated infrastructure removes that incentive. A server with 6.4TB or 25.6TB of NVMe and Ceph object storage has a predictable monthly cost regardless of how much log data accumulates within its capacity. You can configure retention policy based on what the regulation requires and what your risk posture calls for, not on what your storage bill looks like this month.

Where EU Data Residency Fits

Article 12 does not specify where logs must be stored. But Article 12 does not exist in isolation. GDPR applies to personal data processed by high-risk AI systems. Many AI systems in scope for Article 12, including those screening job applicants, assessing creditworthiness, or operating in law enforcement contexts, process personal data.

Where that data is logged matters for GDPR compliance. Logs that include input data, which Article 12 requires for biometric systems and which many other AI systems will capture as a practical matter, may contain personal data. Storing those logs on infrastructure outside the EU, or routing them through infrastructure of uncertain location, creates GDPR exposure separate from the AI Act compliance question.

OpenMetal operates a data center in Amsterdam, Netherlands. Deploying AI systems on that infrastructure, or deploying the log storage tier there specifically, keeps log data within the EU on infrastructure with a known physical location. Our EU confidential computing guide covers related infrastructure decisions for regulated workloads in Amsterdam.

Single-tenant infrastructure also simplifies the audit scenario. When a competent authority requests access to your logs, they are accessing a system that contains only your logs, not a multi-tenant environment where access scoping is a more complex problem.

The Enforcement Timeline and What Is Currently Live

Article 113 of the EU AI Act set August 2, 2026 as the enforcement date for high-risk AI system obligations, including Article 12. That date has passed.

There is an important caveat: a Digital Omnibus proposal would defer standalone Annex III systems to December 2, 2027. As of this writing, that deferral has not been published in the Official Journal of the European Union and does not yet have legal effect. The enforcement status of specific systems in the standalone Annex III category is genuinely unsettled. The European Commission’s AI Act Service Desk publishes the official text and timeline, and readers should verify with legal counsel which date applies to their specific systems.

What is not unsettled: the infrastructure work required to meet Article 12 does not change based on the enforcement date. The logging architecture needs to exist and be producing records before the obligation applies. Organizations that have not built compliant log infrastructure yet are building toward a deadline, not away from one.

What This Looks Like on Private Infrastructure

The practical implementation on OpenMetal involves three components:

The AI system, running on compute in a private cloud or on bare metal, is configured to write structured event logs to an object storage endpoint. For hosted private cloud deployments, that endpoint is the integrated Ceph object store accessible within the same environment.

The Ceph bucket is configured with object locking and a retention period that meets or exceeds the six-month floor. Write credentials are scoped to the AI system. Read credentials are scoped to authorized operations and audit functions. Deletion during the retention window is blocked at the storage layer, not just by policy.

Log retention and access logs are maintained as a separate audit trail: who accessed which logs, when, and from where. That second-order audit trail supports the regulatory inspection scenario where an authority asks not just for logs, but for evidence about how those logs have been managed.

OpenMetal’s Ceph configuration for high-performance storage workloads is covered in our Ceph and v5 hardware guide. The same Ceph environment supports both the operational storage workloads and the compliance log tier, with bucket-level policies separating the access models. For a deeper look at how S3 Object Lock and WORM semantics work on OpenMetal’s Ceph, our immutable storage guide covers the technical configuration in detail.

Who This Applies To

This is directly relevant if you:

• Develop or deploy AI systems that fall under Annex III of the EU AI Act, including systems used for employment screening, credit scoring, biometric identification, critical infrastructure, law enforcement, or education
• Operate as a deployer of a high-risk AI system and carry the Article 26(6) retention obligation even if you did not build the system
• Store or process personal data as part of your AI system’s operation and need log infrastructure that satisfies both Article 12 and GDPR data residency requirements
• Need to demonstrate to enterprise clients or their compliance teams that the infrastructure running your AI product meets EU regulatory requirements

This is less pressing if you:

• Operate AI systems entirely outside the EU AI Act’s scope, including systems used for purely internal purposes not listed in Annex III, or in jurisdictions where the regulation does not apply
• Have already implemented compliant log storage and your open question is retention policy, not infrastructure

The Compliance Posture Is Only as Strong as the Infrastructure Under It

Article 12 sets a technical requirement, and technical requirements get checked technically. When a competent authority requests logs for a specific window of operation, the question is not whether you intended to keep them. The question is whether the infrastructure kept them automatically, durably, and in a form that demonstrates they have not been modified. Infrastructure configured to do that before enforcement applies is a different situation than documentation promising it will.

Start a proof of concept or contact our team to walk through log infrastructure for your specific AI Act obligations.

Frequently Asked Questions

What Is a High-Risk AI System Under the EU AI Act?

The EU AI Act classifies AI systems as high-risk based on their intended use. Annex III of the regulation lists the categories, which include AI systems used in employment and worker management, access to education, credit scoring, biometric identification, law enforcement, migration and border control, administration of justice, and critical infrastructure. Classification depends on use case and deployment context, not on the underlying technology. The EU AI Act Service Desk covers classification rules under Article 6.

How Long Do Logs Need to Be Retained Under Article 12?

Articles 19 and 26(6) set a six-month minimum floor for both providers and deployers. The regulation specifies retention appropriate to the system’s intended purpose, meaning many systems will require longer retention depending on the use case. Other Union or national law may also require longer periods. Six months is the minimum, not the standard.

Does the Logging Obligation Apply to Deployers or Only to Providers?

Both. Providers of high-risk AI systems must ensure Article 12 logging capability is technically built in, and Article 19 sets their six-month retention obligation. Deployers have their own retention obligation under Article 26(6), regardless of who built the system. Purchasing a high-risk AI system from a vendor does not transfer the deployer’s compliance obligation to the vendor.

Does Using OpenMetal’s Infrastructure Certify EU AI Act Compliance?

No. OpenMetal provides the infrastructure components, including Ceph object storage with immutable bucket policies, EU data residency in Amsterdam, and single-tenant network isolation, that support building compliant log architecture. Compliance depends on how those components are configured and operated in the context of a specific AI system. Whether a specific deployment satisfies Article 12 requires legal and technical assessment of the full system.

What Is the Difference Between Article 12 and Article 13 of the EU AI Act?

Article 12 covers the technical logging requirement: automatic recording of events over the system’s lifetime. Article 13 covers transparency and information obligations to deployers: documentation of system capabilities, limitations, and intended purpose. Both apply to high-risk AI systems, but they address different obligations. Article 12 is an infrastructure requirement; Article 13 is a documentation requirement.