Article 12 of the EU AI Act requires automatic logging for high-risk AI systems. Here is what that means technically, what data you need to capture, and how to implement it.

If your company operates a high-risk AI system with EU users, Article 12 of the EU AI Act is probably the most technically demanding obligation you face. It requires automatic logging of events throughout the operational lifetime of your system. Not occasional logging. Not manual audit trails. Automatic, continuous, structured logging of every inference event your system produces.

This post explains what Article 12 actually requires, what data you need to capture, and what good implementation looks like in practice.

What Article 12 Says

Article 12 is titled “Record-keeping.” The core obligation reads:

High-risk AI systems shall technically allow for the automatic recording of events (logs) throughout the lifetime of the system.

The Article goes on to specify that logging must capture enough information to trace the system’s decisions and enable post-incident investigation. Specifically, the logs must record:

  • The period of each use of the system (start and end timestamps)
  • The reference database against which input data was checked, where applicable
  • The input data or results of any data preprocessing that was used
  • The identity of the natural persons involved in the verification of results, where applicable

For systems operating in particularly sensitive contexts, including biometrics, critical infrastructure, and employment, additional logging requirements apply under Annex III.

What This Means Technically

Let’s translate the legal language into engineering requirements.

Every inference call needs a log entry. This is not about logging errors or edge cases. Every time your AI system makes a decision or produces an output, that event must be recorded. If your system processes 100,000 requests per day, you need 100,000 log entries per day.

Logs must be automatic. The regulation specifically says “automatic recording.” Manual logging, periodic exports, or batch summaries do not satisfy this requirement. The logging must happen at inference time, as part of the system’s normal operation.

Timestamps must be precise. You need to know exactly when each decision was made. Millisecond precision is the standard to aim for, both for the start of processing and the delivery of output.

Input data must be captured or referenced. This is where many teams underestimate the scope. You need to either store the actual input data or a cryptographic reference to it, so you can reconstruct what the system was given when it made a particular decision.

Model version must be logged. Regulators need to know which version of your model produced a given output. If you update your model, the logs need to clearly distinguish outputs produced before and after the update.

Confidence scores should be included. The regulation does not explicitly require confidence scores in all cases, but they are strongly implied for systems where output certainty affects how the decision is used. In practice, any serious compliance posture includes them.

Human oversight events must be captured. When a human reviews or overrides a system output, that event needs to be logged alongside the original AI decision. Article 14 (human oversight) and Article 12 work together here.

A Practical Logging Schema

Here is what a compliant Article 12 log entry looks like in practice:

{
  "event_id": "evt_a3f8c1d2",
  "system_id": "hiring-screener-v2",
  "model_version": "1.4.2",
  "timestamp_start": "2026-05-24T14:32:01.847Z",
  "timestamp_end": "2026-05-24T14:32:02.103Z",
  "input_reference": "sha256:a8f3c9...",
  "output": {
    "decision": "advance",
    "confidence": 0.84,
    "risk_flags": []
  },
  "human_review": {
    "required": true,
    "reviewed_by": null,
    "reviewed_at": null,
    "override": null
  },
  "data_source_version": "candidate-db-2026-05",
  "processing_environment": "prod-us-west-2"
}

Every field serves a purpose. The event_id makes each decision uniquely traceable. The input_reference uses a hash rather than storing raw data, which satisfies both Article 12 and GDPR data minimization principles. The human_review block is pre-populated with nulls, ready to be filled when a reviewer acts on this decision.

Where Teams Get This Wrong

The most common mistake is treating Article 12 as a logging problem rather than a system design problem. Retrofitting logging onto an existing AI system is painful. The cleanest implementations treat logging as a first-class concern from the start, instrumenting at the inference layer rather than bolting on at the application layer.

The second most common mistake is logging outputs but not inputs. Outputs without inputs are nearly useless for compliance purposes. If you can not reconstruct what the system was given when it made a particular decision, you can not meaningfully audit that decision.

The third mistake is logging to ephemeral storage. Application logs that roll off after 30 days do not satisfy a regulation that requires records for the operational lifetime of the system. Article 12 logs need durable, searchable, tamper-evident storage.

How Long Do You Need to Keep Logs?

The EU AI Act does not specify a single retention period for all systems. For most high-risk systems, the practical standard is at least five years from the date of each logged event. For systems used in particularly sensitive contexts, longer retention may be required. Your legal counsel should confirm the appropriate retention period for your specific system and use case.

The GDPR Overlap

If your Article 12 logs contain personal data, and for most high-risk AI systems they will, GDPR applies alongside the EU AI Act. This creates a tension: Article 12 says keep logs, GDPR says minimize data and honor deletion requests.

The resolution is to separate the structural compliance data from the personal data. Log the decision metadata (timestamps, model version, confidence scores, human review events) in your compliance log. Store personal data separately with appropriate GDPR controls. Use references, not raw data, in the compliance log. This way a subject access request or deletion request under GDPR does not require you to destroy your Article 12 evidence.

What Auditors Will Want to See

When enforcement begins, auditors will not just want to know that you have a logging system. They will want to see that it works. Specifically, they will want to:

  • Query your logs by date range and see complete records
  • Take a random sample of decisions and reconstruct the full context of each one
  • Verify that human review events are captured where required
  • Confirm that logs are tamper-evident and have not been modified after the fact
  • See that model version changes are clearly reflected in the log history

If you can hand an auditor a query interface and let them investigate freely, you are in a strong position. If you have to manually assemble evidence from multiple systems, you are not.

The Bottom Line

Article 12 is not a checkbox. It is a continuous operational requirement that touches your inference pipeline, your storage architecture, your data governance practices, and your human oversight workflows. The good news is that if you instrument it properly from the start, it becomes largely invisible. The bad news is that many teams will not realize how substantive the requirement is until they are trying to satisfy an auditor.

The enforcement deadline for high-risk AI systems is December 2, 2027 under the revised Digital Omnibus on AI. That is more runway than the original August 2026 date, but it is not as much time as it sounds. Building and operating a compliant logging system takes time to get right, and you want months of clean logs before enforcement begins, not days.

Aiella provides technical AI compliance monitoring software. Our free risk assessment identifies your EU AI Act obligations in under 2 minutes at assessment.aiella.com. This post is for informational purposes only and does not constitute legal advice.