EU AI Act audit logging requirements (Article 12) and how to satisfy them

The control

Regulation (EU) 2026/1744 (the Digital Omnibus, in force 27 July 2026) deferred Annex III high-risk obligations: which is where Article 12 lives: to 2 December 2027, and Annex I to 2 August 2028. Article 50's transparency obligations were not deferred. If your system is high-risk under Annex III, Article 12 is real but not a 2026 deadline; build the logging now and you won't be scrambling in 2027.

What an auditor asks for

A notified body or market surveillance authority reviewing a high-risk AI system wants proof that every model inference is automatically recorded with enough detail to reconstruct what the system did and why, not a design document asserting that logging is planned.

Retention requirement

AuditRails retains EU AI Act audit logs for a minimum of 10 years by default: the longest retention window of any framework we support, matching Article 12's full-lifetime traceability expectation. Retention extends automatically if you're also subscribed to a framework with a longer requirement.

What AuditRails captures

Model-inference events capture the model version, input/output hashes, risk tier, and whether human oversight was involved, not just "the model ran," but the specific fields Article 12 traceability actually needs.

import { AuditRails } from '@auditrails/node';

const audit = new AuditRails({ apiKey: 'at_live_...' });

await audit.log({
  action: 'aiact.model_inference_logged',
  actor_id: '...', // required
  resource: '...', // required
  metadata: {
    system_id: '...', // required
    model_id: '...', // required
    input_hash: '...', // optional
    output_hash: '...', // optional
    latency_ms: '...', // optional
    risk_tier: '...', // optional
    model_version: '...', // optional
    prompt_ref: '...', // optional
    decision: '...', // optional
    human_oversight: '...', // optional
  }
});

What you hand your auditor

Generate an evidence bundle for your audit window and you get a zip containing a PDF summary report, the full event log as NDJSON, and a manifest with SHA-256 checksums of both files plus a hash-chain proof: evidence you can hand directly to a notified body or market surveillance authority, not a design claim they have to take on faith.

Common ways teams fail this control

• Logging that inference happened, but not the model version or input/output hashes. Article 12 traceability needs to reconstruct what the system did, not just that it ran.
• No human-oversight field on inference events, when Article 14's oversight requirements and Article 12's logging are meant to work together, not as separate, disconnected controls.
• Retention shorter than the system's actual operational lifetime, missing Article 12's explicit "over the lifetime of the system" language.
• Building logging only after a system is classified high-risk and the compliance deadline is close, rather than from the start: retrofitting traceability into a system already in production is far harder than building it in from day one.
• No consistent system_id/model_id across logged events, making it impossible to reconstruct a single system's full operational history when an authority asks for it.

Frequently asked questions

This page describes regulatory obligations for information purposes and does not constitute legal advice. Whether they apply to your organisation should be confirmed with your own advisers.