Cryptographically signed, Bitcoin-anchored, and mapped to Articles 12 & 19 of the EU AI Act. The record-keeping evidence your auditor can verify — without trusting the vendor who produced it.
Article 12 requires automatic logging over an AI system's lifetime. ArmoredLedger makes those logs provable to a third party — not just present in your database.
The EU AI Act turns record-keeping into a legal obligation: high-risk systems must log their operation (Article 12), and those logs must be kept for auditors and market-surveillance authorities (Article 19). But a log that lives only in your vendor's database is a log they can edit, back-date, or lose — and one an auditor has no independent way to trust. When a regulator asks you to prove what your AI did and when, "here's our export" is an assertion, not evidence.
Governance platforms give you a self-attested "system of record" — a log inside an application database that you, and only you, can vouch for. ArmoredLedger anchors each day's records into the public Bitcoin blockchain via OpenTimestamps. An auditor can verify a record's signature and its Merkle inclusion against a chain no vendor owns — offline, with no access to our systems, and even if we disappear tomorrow.
This gap is the market's own admission: in 2024, IBM had to partner with Casper Labs to bolt blockchain onto watsonx.governance for the "tamper-resistant, time-synched" AI records it couldn't produce natively. Public-blockchain anchoring isn't a feature the governance suites have — it's one they reach outside for.
The difference an auditor actually cares about.
ArmoredLedger is an audit-trail and record-integrity layer. It supports the record-keeping and traceability obligations below — it is not a full governance suite, and it doesn't claim to be.
| Article | Obligation | How ArmoredLedger supports it |
|---|---|---|
| Art. 12 | Record-keeping — automatic logging of events over the system's lifetime | The ai-action-v1 schema records operational AI events — tool calls, content generation, code changes — with input and output digests, outcome, and model, under fail-closed authority binding. Signed and hash-chained so the log itself is tamper-evident. |
| Art. 19 | Log retention — keep automatically generated logs (≥ 6 months) | Records are retained in the hosted ledger for your plan's retention window, and their Bitcoin anchor makes the proof-of-existence permanent — verifiable long after the raw rows age out. |
| Art. 26(6) | Deployer obligations — deployers keep logs under their control | Deployers emit their own attestations to a private trust anchor, giving them an independently verifiable copy of the logs they are obligated to keep. |
| Art. 50 | Transparency — disclosure and labelling of AI-generated content | Content-generation events carry the input/output digest and model in the signed record, producing durable, verifiable evidence of what was AI-generated and when. |
| Art. 11 · Annex IV | Technical documentation kept up to date | Signed provenance for software releases and model/pipeline changes gives your technical documentation an anchored, tamper-evident change history. |
Honest framing. ArmoredLedger provides the tamper-evident record that supports these obligations; it is not itself a certification, and using it does not by itself make an AI system "EU AI Act compliant." The operational-logging SDK (ai-action-v1) exists and enables Article 12 logging, but is not yet wired into live products — this is the integrity layer for AI records, not a claim that we log your model's every decision today. The signed, enforced path (/v1/attest) is distinct from the unsigned developer path (/v1/attestations); only signed records are presented as proof of authorship. The declared principal ("who acted") is emitter-asserted — ArmoredLedger proves the record is signed, anchored, and unaltered, not which human was at the keyboard. Signing uses a FIPS 140-2 Level 3 HSM; it is not a CMVP-certified module. Records are tamper-evident between anchor intervals.
The EU's Digital Omnibus deferred the high-risk obligations — including Articles 12 and 19 — from August 2026 to 2 December 2027 (Annex III systems; Annex I-embedded systems follow in August 2028). That's runway, not reprieve: traceability is the one obligation you can't retrofit after the fact, and general-purpose AI (GPAI) obligations have already been in force since August 2025.
General-purpose AI model obligations already apply. Provenance for model and pipeline releases is due now, not later.
Articles 12 & 19 apply to Annex III high-risk systems. Article 12 logging must cover the system's lifetime — you can't backfill a log you never kept.
High-risk AI embedded in Annex I regulated products reaches its obligation date. Same traceability requirement, longer product cycles.
Article 12 requires logs that cover a system's operating life. Because you cannot reconstruct a traceable, anchored history retroactively, the practical lead time for record-keeping is longest — it starts the day the system goes live, not the day the obligation bites.
The same integrity model, applied to your AI records.
Every AI event is hash-chained — what happened, the input/output digests, the model, the outcome, on whose declared authority.
Each attestation is signed (Ed25519 / HSM P-384) and verified against published trust anchors.
Every day the Merkle root is timestamped into Bitcoin via OpenTimestamps — a clock no one owns.
Your auditor checks any record in-browser: signature, inclusion, anchor. No login. No faith in us.
The integrity layer for AI record-keeping under the EU AI Act — signed, Bitcoin-anchored, and verifiable by anyone. Slot it beneath the governance suite you already run.