EU AI Act Article 12: Tamper-Evident Logging for AI Systems

Published 2026-08-24 · mpps.io · 8 min read

Since August 2, 2026, high-risk AI systems placed on the EU market must technically allow the automatic recording of events (logs) over their lifetime — and supervisory practice expects those logs to be tamper-evident. This guide summarizes what Article 12 of the EU AI Act actually requires, why plain log files don't meet the bar, and the three architectures teams use to make logs tamper-evident — including external hash anchoring, which you can implement in an afternoon with any independent witness service (mpps.io is one).

What Article 12 requires

The regulation's record-keeping requirement has four practical parts:

• Automatic. The system must generate logs itself. Manual documentation, screenshots, or after-the-fact reconstruction do not satisfy the requirement.
• Lifetime. Logging must cover the system from deployment to decommissioning — not just the current release.
• Traceability. Logs must be capable of identifying situations that present risk, supporting post-market monitoring (Article 72), and monitoring system operation. Assessors read this as inputs, outputs, and decision points.
• Retention. Providers keep logs under their control (Article 19); deployers keep logs for at least six months (Article 26(6)), longer where other law applies.

Non-compliance with high-risk system obligations carries fines up to €15 million or 3% of global annual turnover, whichever is higher (Article 99).

Why a plain log file fails the audit question

Every logging stack can produce a log file. The question an auditor or opposing counsel asks is different: "How do I know these logs weren't edited after the incident?" A file on a disk you control, in a database you administer, proves nothing about tampering — whoever operates the system can rewrite it. "Appropriate to the intended purpose" in Article 12 is increasingly interpreted as requiring tamper evidence: the property that any modification of the record is detectable.

Three architectures for tamper-evident logs

1. WORM storage (write once, read many)

Write logs to storage that physically or contractually prevents modification — AWS S3 Object Lock in Compliance Mode, Azure immutable blobs, dedicated appliances. Strong within one cloud account, and often sufficient. Weakness: the operator configures the storage, so an auditor must trust that the lock was on from day one and that no parallel unlocked copy was substituted. It is tamper-resistant, but the proof still lives entirely inside the operator's trust boundary.

2. Internal hash chains

Chain each log record to the previous one with a hash (like a mini-blockchain inside your log pipeline). Any in-place edit breaks the chain. Weakness: whoever holds the chain can recompute the entire tail after an edit. Without an external reference point, a rewritten chain is indistinguishable from the original.

3. External hash anchoring (independent witness)

Periodically — per event, per batch, or per day — compute a hash of your log segment (or the head of your internal hash chain) and register it with a party outside your trust boundary. The external party signs and stores the hash with a timestamp. Later, anyone can recompute the hash from your logs and compare it to the anchored receipt. If the logs were modified after anchoring, the hashes will not match — and you cannot alter the receipt, because you never controlled it.

This is the same principle behind RFC 3161 timestamping and certificate transparency logs. It composes with the other two architectures: WORM storage plus external anchoring gives you both retention and independently checkable integrity. Because only hashes leave your system, no log content — and no personal data under GDPR — is disclosed to the anchoring party.

Implementing external anchoring in practice

Any independent timestamping or attestation service works as the witness. Using mpps.io (free, no API key), a nightly cron anchoring your log segment looks like this:

> HASH=$(sha256sum /var/log/ai-system/decisions-$(date +%F).log | awk '{print "sha256:" $1}')
curl -X POST https://api.mpps.io/v1/receipts \
  -H "Content-Type: application/json" \
  -d "{
    \"action\": \"log.segment.anchor\",
    \"subject\": \"decisions-$(date +%F).log\",
    \"artifact_hashes\": [{\"label\": \"daily-log\", \"sha256\": \"$HASH\"}],
    \"context\": {\"system\": \"credit-scoring-v2\", \"period\": \"$(date +%F)\"}
  }"

The response is an HSM-signed receipt with a UUID, a timestamp, and a verify URL. Store the UUID beside the log segment. At audit time: recompute the hash, fetch the receipt (or verify its signature offline with the published public key), show they match. The receipt itself is held in S3 Object Lock Compliance Mode for 10 years — outside your infrastructure and outside your control.

What anchoring does and does not give you

• It gives you: independently verifiable evidence that a specific log state existed at a specific time, with tamper evidence that survives even a hostile audit of your own infrastructure.
• It does not give you: Article 12 compliance by itself. You still need the logging scope (inputs, outputs, decision points), the retention policy, and the operational monitoring the Act requires. Anchoring makes the logs you already keep provable; it does not decide what to log.

Checklist for engineering teams

• Confirm with counsel whether your system falls under Annex III (high-risk) — the record-keeping obligation attaches there.
• Log inputs, outputs, and decision points automatically, from deployment onward.
• Put logs in WORM storage with a retention period matching your obligations (deployers: ≥ 6 months).
• Anchor a hash of each log segment to an external witness on a fixed cadence (daily is common; per-decision for high-stakes systems).
• Store receipt IDs with the segments and document the verification procedure in your technical documentation (Annex IV).
• Test the recovery path: can a third party actually verify a segment end-to-end without trusting you?

Sources

• EU AI Act, Article 12 — Record-Keeping (full text)
• Article 19 — Automatically Generated Logs (provider retention)
• Article 26 — Deployer obligations (six-month log retention)
• Article 99 — Penalties