The EU AI Act imposes record-keeping obligations on high-risk AI systems. Article 12 covers automatic logging of events across the system’s lifetime; Article 19 and related provisions address retaining those logs and producing them for authorities; Article 14 adds human-oversight duties that presuppose you can review prior decisions. The common assumption is that any observability pipeline already satisfies this. It doesn’t — and the gap is subtle enough that most teams won’t notice until someone asks them to prove it.

Standard log systems record events into mutable tables or files. An engineer with database access, a compromised service account, or a routine retention script can alter or delete entries without leaving a detectable trace. (Some deployments already use WORM or append-only storage that reduces this; the contrast here is with ordinary mutable stores.) When a regulator asks you to prove a decision was made under the conditions you claim, the honest answer from a mutable store is “trust our database.” That is not the kind of record the Act’s record-keeping provisions are reaching for.

So the obligation isn’t merely to collect data — it’s to be able to produce records whose integrity can be verified independently. Tamper-evidence has to be built into the record itself, not asserted afterward. This isn’t a new idea; the integrity expectations show up in NIST SP 800-92 and in the foundational work on hash-chained secure logging (Schneier & Kelsey, 1999). What’s new is that AI agents now generate the high-stakes events that fall under the rules.

What a tamper-evident record looks like

Marturia generates a signed receipt for each decision event you choose to record. The receipt carries a hash of the event payload, a timestamp, and a monotonically increasing sequence number. Each receipt includes the hash of the previous one — a per-tenant hash chain. Each is signed with an Ed25519 key (RFC 8032) that belongs to your tenant. At intervals, an in-house witness process builds a Merkle tree over the SHA-256 hashes accumulated since the last witness point and signs the root. Verification needs only the tenant public key, the receipts, and the witness signatures. No external transparency service sits in the path.

A minimal receipt:

{
  "seq": 18472,
  "event_hash": "sha256:9f3a...",
  "prev_receipt_hash": "sha256:4c2b...",
  "timestamp": "2026-05-29T14:22:03Z",
  "sig": "ed25519:5f8e..."
}

The verifier runs locally and offline — no account, no API key:

pip install marturia-verify
marturia-verify --receipt receipt.json --pubkey-hex <tenant-public-key>

It checks the Ed25519 signatures, walks the hash links, and confirms the witness-cosigned Merkle root. Anyone who receives the exported receipts can run it without contacting you. Alter any receipt and the subsequent signatures or the Merkle root break. Deletion shows up too: sequence numbers must be contiguous between witnessed roots, so a gap between two consecutive witness signatures flags missing entries.

flowchart LR
    A[Decision event] --> B[Hash payload]
    B --> C[Include prev hash, sign with tenant Ed25519]
    C --> D[Append to chain]
    D --> E[Witness builds Merkle root over interval, cosigns]
    E --> F[Regulator receives slice + tenant pubkey]
    F --> G[Independent verification]

You hand a regulator or auditor a slice of the chain plus your tenant’s public key — whose authenticity you establish out of band, through a registry you publish — and they verify it themselves. The trust moves out of your database and into math anyone can check.

What this does not do

This is the part I want to be plain about, because compliance is exactly where overclaiming does damage. This post is not legal advice, and Marturia is not a complete compliance solution. It supplies one specific thing: the tamper-evident integrity layer for records you’re already obligated to keep. You still have to decide which events must be logged, how long to retain them, and how to present them to human overseers under Article 14. Cryptographic integrity can support the record-keeping expectations in the Act, but mapping specific controls to specific legal obligations remains yours — ideally with counsel.

The practical pattern is undramatic: teams already running structured logging emit the same events to both their observability stack and to Marturia. Operational logs give you observability; receipts give you records you can prove. Retention stays under your control — receipts export on demand through the same path used for verification.

Closed beta is open. To see the chain construction and verification in your own environment:

Related Marturia resources - /guides/gdpr-immutable-audit-tombstone.html - /docs/quickstart.html - /docs/