Automatic Logging Under AI Act Article 12: Retention, Tamper-Evidence and What to Capture

A log that a person can edit, or that silently rotates away after a fortnight, is worth nothing the moment an authority asks you to reconstruct a decision. Article 12 turns logging from an operational nicety into a design constraint on any high-risk AI system.

Most writing on AI Act logging treats it as a documentation task: keep some records, tick the box. That reading fails the first real test. When a market surveillance authority or a deployer’s regulator comes to reconstruct what a high-risk system did and why, they are not testing whether you kept records. They are testing whether the records are complete, verifiable, and demonstrably not altered after the fact. That is an engineering property, and you either build it in or you retrofit it after an incident has already happened — which, by then, is too late to be credible.

What Article 12 actually requires

Article 12 of the AI Act says that high-risk systems shall technically allow the automatic recording of events — logs — over the lifetime of the system. Two words in that sentence do the work. Automatic: not a manual export a person remembers to run, but a capability designed into the system. Lifetime: not the current release, but the operational existence of the system across versions and redeployments.

Article 12(2) then scopes what the logging must be capable of recording. It names events relevant to three things: identifying situations where the system may present a risk or has undergone a substantial modification; facilitating post-market monitoring; and supporting the deployer’s monitoring of the system in operation. Those are not three separate log files. They are three questions your single log has to be able to answer from the same underlying record.

Article 12(3) adds a specific floor for remote biometric identification systems: the period of each use with start and end date and time, the reference database checked, the input data that produced a match, and the identification of the people who verified the result. If you build a biometric system, treat that list as a minimum schema, not a suggestion. For everything else, Article 12(2) sets the intent and leaves the schema to you — which is where the real design decision sits.

Append-only is the whole point

The word the Act does not use, but plainly means, is tamper-evidence. A log satisfies its purpose only if an authority can rely on it not having been quietly edited. A plain application log table that any operator with database access can update or delete does not clear that bar, however comprehensive it looks. Neither does a log shipped to a system where retention is governed by whoever holds the admin console.

The mechanism is not exotic. Write records append-only, and hash-chain them: each record seals the hash of the record before it, so any edit, reordering, or deletion breaks the chain and is detectable by anyone who recomputes it. Store the chain on write-once media — object storage with an object-lock or WORM policy, or an equivalent your platform provides — so that even a privileged operator cannot rewrite history without leaving a hole that verification will find. This is the same discipline that underpins credible incident reconstruction under other regimes; if you have read our note on Article 9 risk management systems, the logging layer is what makes the risk controls in that framework auditable rather than asserted.

The schema, and the chain that proves it

A workable event schema captures the decision without dragging the raw personal data into a second store you now have to secure and justify. Reference inputs by hash; record the output, the model version, and any human intervention. The append routine seals each record to the last.

import hashlib, json, datetime as dt

# Append-only, hash-chained log for high-risk AI inference events (AI Act Art. 12).
# Each record seals the previous record's hash, so any edit or deletion breaks the chain.

# --- Event schema: the minimum a high-risk inference event should carry ---
example_event = {
    "system_id":     "hr-screener",             # which high-risk system
    "model_version": "2026.07.1",               # exact model/weights in service
    "event_type":    "inference",               # inference | override | config_change | error
    "occurred_at":   "2026-07-20T09:14:02Z",    # UTC, from a trusted clock
    "input_ref":     "sha256:9f2b1c...",        # hash of input, not the raw personal data
    "output_ref":    "decision:refer",          # the decision or score emitted
    "confidence":    0.71,
    "human_reviewer": None,                     # populated on an Art. 14 oversight action
}

def _canonical(record: dict) -> bytes:
    # Deterministic serialisation so the hash is reproducible at verification time.
    return json.dumps(record, sort_keys=True, separators=(",", ":")).encode("utf-8")

def append_event(store: list, event: dict) -> dict:
    prev_hash = store[-1]["record_hash"] if store else "0" * 64
    body = {
        "event":     event,
        "logged_at": dt.datetime.now(dt.timezone.utc).isoformat(),
        "prev_hash": prev_hash,
    }
    body["record_hash"] = hashlib.sha256(_canonical(body) + prev_hash.encode()).hexdigest()
    store.append(body)          # in production: write to WORM / object-lock storage
    return body

def verify_chain(store: list) -> bool:
    prev_hash = "0" * 64
    for record in store:
        body = {k: record[k] for k in ("event", "logged_at", "prev_hash")}
        expected = hashlib.sha256(_canonical(body) + prev_hash.encode()).hexdigest()
        if record["prev_hash"] != prev_hash or record["record_hash"] != expected:
            return False        # chain broken: tampering or loss
        prev_hash = record["record_hash"]
    return True

The point of verify_chain is that you can run it in front of an auditor. A log you cannot independently verify is a log you are asking a regulator to take on trust, and regulated-industry supervisors do not take logs on trust.

Retention without unbounded storage

Article 19 sets the retention floor for providers: keep the automatically generated logs, to the extent they are under your control, for a period appropriate to the intended purpose and in any case at least six months, unless a longer period is required by other Union or national law — data protection law in particular. Financial institutions already subject to record-keeping duties under Union financial services law fold these logs into that existing documentation rather than running a parallel regime.

Six months is a floor, not a target, and “appropriate to the intended purpose” is where the engineering lives. A credit-scoring system whose decisions can be challenged for years needs a retention horizon set by the challenge window, not by the statutory minimum. This is also where naive designs blow their storage budget: keeping every full inference record, hot, forever, is neither required nor affordable. Tier it. Keep recent records hot and verifiable; roll older records to cheaper immutable storage while preserving the hash chain across the boundary so verification still runs end to end. Retention is a schedule tied to purpose and to the post-market monitoring obligations the same logs feed, not a single number applied to everything.

Decide this before December 2027

Under the Digital Omnibus adopted in mid-2026, the obligations for standalone Annex III high-risk systems apply from 2 December 2027, with product-embedded Annex I systems following in August 2028. That is not distant. The logging layer is one of the few AI Act requirements you genuinely cannot bolt on after launch: you cannot hash-chain events you never captured, and you cannot prove the integrity of a store you designed to be mutable. Every inference a production system emits before the log is right is an event you will never be able to reconstruct credibly.

Specify the schema, make the store append-only, set retention by purpose, and be able to run the verification in the room. Do that now, while the systems are still being built, and Article 12 becomes a property of the architecture. Leave it until an authority asks, and it becomes the one gap you cannot honestly close.