Does Article 12 of the EU AI Act require an immutable audit log?

Article 12 requires automatic event recording 'over the lifetime of the system' and that the logs be 'traceable to specific events'. It does not literally use the word 'immutable', but Article 19 requires providers to keep the logs for the period the AI system is on the market — and Article 12 paragraph 2 lists specific events that have to be recorded. A log a deployer could silently edit would fail both the traceability requirement and the broader 'risk management system' requirement of Article 9.

Which Annex III categories require the audit log?

All eight: biometric ID, critical infrastructure, education, employment, essential private and public services, law enforcement, migration, administration of justice. Annex III simply lists which AI use cases are 'high-risk'; Articles 9-15 then apply uniformly to every high-risk system. If your LLM-in-the-loop feature falls into any Annex III category, Article 12 applies.

Is a Datadog log enough for Article 12 compliance?

A Datadog or Splunk application log records what happened operationally. It does not by itself prove that the log was not edited after the fact. A regulator asking 'how do you know this log was not backdated?' will not be satisfied by 'because Datadog'. Article 12 expects logs that are traceable to specific events; that is functionally a tamper-evidence requirement, even if the article does not use that word.

What does 'identification of inputs that may lead to high-risk decisions' mean?

Article 12 paragraph 2 lists what the log must enable: identification of situations that may result in a high-risk situation, facilitation of post-market monitoring, and identification of biometric data subjects. In practice this means the log must let you go from 'a problem happened on date X' to 'the specific decision the AI made on date X under spec Y with input hash Z'. Promethean's L12 receipt chain entries carry exactly those fields — inputHash, specHash, recordedAtIso, reviewerVerdict — by design.

What is Promethean's role in EU AI Act compliance vs. what the operator still owes?

Promethean ships the technical record-keeping layer that satisfies Article 12 record-keeping and Article 14 reviewer-gate evidence. The operator still owes the risk-management system (Article 9), the data governance documentation (Article 10), the technical documentation in Annex IV (Article 11), the transparency-to-deployer instructions (Article 13), and the accuracy/robustness/cybersecurity programme (Article 15). Promethean's regulator handoff packet for the AI Act enumerates each article and explicitly surfaces what the operator still has to do.

EU AI Act Annex III audit-log requirements — what Article 12 actually demands

The EU AI Act (Regulation 2024/1689) enters its main application phase on 2026-08-02. For any AI system that falls into one of the eight Annex III categories, the obligations of Chapter II — risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy + robustness — apply in full. This post is about one of those obligations: Article 12, record-keeping.

Article 12 looks short. The text fits on a page. But it encodes a specific engineering requirement that most application logs do not satisfy: every event affecting a high-risk decision must be automatically recorded, retained for the lifetime of the system, and traceable to a specific decision. Built right, this is a chain-of-custody log. Built wrong, it's a Datadog stream that a deployer's SRE could silently edit.

What Annex III actually lists

Annex III contains eight numbered categories of high-risk AI use cases. The article-text version is short. Loosely:

Biometric identification — real-time and post remote biometric ID systems, biometric categorisation, emotion recognition.
Critical infrastructure — safety components in road traffic, water, gas, electricity supply, digital infrastructure.
Education and vocational training — access determination, assessment scoring, prohibited-behaviour monitoring.
Employment, workers management, self-employment — recruitment, evaluation, promotion + termination decisions, performance monitoring.
Access to essential private and public services — creditworthiness scoring, eligibility assessment, fraud detection, emergency-response dispatch.
Law enforcement — risk assessment of natural persons, polygraphs and similar, evidence reliability evaluation, profiling.
Migration, asylum, border control — risk assessment, document verification, application examination.
Administration of justice and democratic processes — judicial decision-support, electoral influence.

Falling into any single category triggers the whole Chapter II obligation set, including Article 12. The classification is the deployer's responsibility — and a regulator will not accept "we did not realise" as a defence. Self-classify early, document it, attach the rationale to your Annex IV technical documentation.

What Article 12 says, literally

The article opens with a one-sentence design requirement:

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.
— EU AI Act, Article 12(1)

Two phrases do most of the work: technically allow and over the lifetime of the system. The first means the recording cannot be optional or disable-able by the deployer's SRE — the system has to be designed such that the log happens automatically. The second means short retention windows fail; Article 19 then specifies the practical retention period (at least six months, more if national law requires).

Paragraph 2 of Article 12 lists what the log has to enable. Paraphrased:

Identification of situations that may result in a substantial modification of the AI system or in a risk under Article 79(1) (a high-risk situation).
Facilitation of post-market monitoring under Article 72.
Identification of natural persons whose biometric data is involved (for biometric ID systems).

Each of those bullets is an indexable property the log has to have. You cannot satisfy them with a free-text log; you need a structured record where you can look up "which decisions were made under spec X between dates A and B" and get a verifiable answer.

What the log has to contain, in engineering terms

Translating Article 12 + the surrounding articles (9, 14, 15) into specific fields per decision:

recordedAtIso — when the decision happened. Monotonic, ISO-8601, ideally with timezone.
specId + specHash — which version of the AI system made the decision. Changing the prompt template, model identity, or output schema must change the spec hash. Article 11 + Annex IV require this level of traceability for change management.
modelIdentity — provider + model + version. "GPT-4" is not a version; "openai/gpt-4-0613" is.
inputHash — SHA-256 of the input. Raw input must not be stored if it contains personal data (GDPR Article 5(1)(c) data minimisation interaction). Hashes allow replay against redacted source data.
outputCanonicalHash — same treatment for the model output.
schemaValid — did the output validate against the declared schema (Article 15 robustness requirement)?
reviewerVerdict — when the system requires human oversight (Article 14), what did the human decide?
fallbackTriggered — did the system fall back to a deterministic safe state when the model failed?
prevHash + hash — chain linkage so a retroactive edit is detectable. This is not literally mentioned in Article 12, but it is the only honest answer to "how do you know this log was not backdated?".

Why a Datadog stream is not enough

Standard application logging (Datadog, Splunk, CloudWatch, Loki) records what happened operationally. It does not structurally prevent an SRE with the right credentials from editing or deleting entries. It does not chain entries to each other so that a deletion would be detectable. It does not sign entries so that a regulator can verify the log wasn't retroactively populated.

A regulator asking "how do you prove this entry has been in the log since the day the decision was made, rather than added retroactively to fit a story?" expects one of two answers:

A cryptographic chain. Each entry's content includes the hash of the previous entry. Editing any entry requires re-hashing every subsequent entry. If you also publish the chain head periodically (e.g. anchored to a public timestamp service), the post-publication window is closed: nothing can be inserted before the anchor block without redoing the proof of work.
A third-party witness. A trusted external party (notary, escrow service, transparency log) attests that they saw entry X on date Y. Same effect, more operational overhead, harder to scale.

Promethean takes the first path: every L12 entry carries prevHash, the chain head is periodically anchored to Bitcoin via OpenTimestamps, and the verifier is zero-dependency Apache-2.0 Node code a regulator runs on their own machine.

What Promethean's L12 chain gives you, vs Article 12 verbatim

Mapping the substrate's output to Article 12's requirements:

Article 12 requirement                  →  Promethean evidence
─────────────────────────────────────────────────────────────────────
12(1) automatic recording               →  appendRuntimeAIReceipt
                                           is the SDK boundary;
                                           no path in the SDK
                                           returns a result without
                                           appending
12(2)(a) identify high-risk situations  →  per-entry schemaValid +
                                           fallbackTriggered +
                                           reviewerVerdict fields
12(2)(b) facilitate post-market mon.    →  L12 chain itself is
                                           the post-market log;
                                           summariseRuntimeAIReceiptLog
                                           gives spec/category/model
                                           breakdowns
12(2)(c) identify biometric subjects    →  operator-supplied
                                           (PII out of scope of
                                           the substrate by design)
19 retention                            →  chain lives on operator
                                           disk; cron + audit-bundle
                                           ensure exportable across
                                           deletion attempts

Promethean does not satisfy Article 12 on the operator's behalf. It makes the technical implementation of Article 12 a one-line SDK call and gives the regulator a verifiable artefact. The classification of the system as Annex III, the surrounding risk-management documentation, the human oversight ladder design, the post-market surveillance process — all operator-owned.

Reviewer gate and Article 14 — the log records the human verdict

Article 14 requires "effective oversight by natural persons" for high-risk systems. The deployer must enable people to interpret output, decide whether to act, and intervene or override. The substrate's reviewer gate is a closed enum: the spec declares reviewerGate: 'always-human' | 'on-schema-violation' | 'on-low-confidence' | 'never'.

When the gate fires, the L12 entry records the verdict (approved, rejected, amended). A regulator auditing your reviewer process can runnode verify.mjs on your chain and count the verdicts directly — no separate spreadsheet, no risk of retroactive editing.

Annex IV ties the log to the documentation

Article 11 + Annex IV require detailed technical documentation for every high-risk AI system. Annex IV lists thirteen categories of content. Several of them are exactly the per-entry fields in the L12 chain (intended purpose, model identity, monitoring functioning, performance metrics) plus the surrounding lifecycle process. Building the documentation on top of the chain — rather than maintaining them separately and hoping they stay aligned — is a structural win. Promethean's handoff packet for the AI Act generates the relevant sections directly from the chain plus the operator's spec metadata.

Actionable summary

Classify your AI feature against Annex III early; document the classification rationale.
Decide whether the log will be in your application's existing observability stack or in a separate tamper-evident chain. Application observability is fine for SRE; it is not enough for Article 12.
Make sure every entry carries the eight fields listed in "What the log has to contain" above.
Verify the log periodically and publish (or anchor) the head. A log no one is checking is a log no one trusts.
Build your Annex IV documentation on top of the log, not alongside it.

Promethean does all five of those automatically when an operator installs the SDK and points it at a workspace. The free Dev tier is enough to evaluate the substrate locally against a real chain; paid tiers add hosted anchoring, federation, and the framework handoff templates for the other six regulators.

Sector-specific guidance

For your industry

Annex III enumerates eight high-risk use-case families. Most regulated SaaS sectors map onto one or more of them — the per-sector pages translate the Annex III obligations into the decisions and audit fields that matter for your product.

All 12 industries →