EU AI ACT · SOC 2 · HIPAA
What Article 12 requires, what it doesn’t, and what a dispute requires anyway.
The regulation
“High-risk AI systems shall be designed and developed with capabilities enabling the automatic recording of events (‘logs’) throughout the lifetime of the AI system.”
An honest note on the dates: the Digital Omnibus (Regulation (EU) 2026/1744) entered into force on 27 July 2026 and moved the start of the high-risk obligations to 2 December 2027 for stand-alone systems (Annex III) and 2 August 2028 for AI built into products already regulated under Annex I. Article 12 applies from the date that applies to your system; confirm the dates against the Official Journal text. There is no August 2026 cliff. The useful reading is lead time: audit infrastructure takes months to stand up either way.
Also honest: Article 12 says “logs,” not “tamper-evident logs.” The regulatory minimum is recording. But Article 9 requires a risk management system, and when an incident occurs (a credit-scoring model produces a discriminatory output, a medical diagnostic is challenged, a recruitment tool is investigated), “we have logs but cannot prove they weren’t modified” is a gap in that system. The regulation doesn’t mandate cryptographic integrity protection. Defensible evidence production calls for it regardless.
Requirement → mechanism
The five evidence classes
| class | what it means | when you have it |
|---|---|---|
| AUTHORITATIVE_EVIDENCE | Sealed by Archeion and verified against the Archeion public key you pinned (--trust-key). | Archeion sealed + pinned key |
| SELF_SEALED_EVIDENCE | A valid seal, but only against its own embedded key. Anyone can produce this. | Sealed, no pinned key |
| SIGNED_NON_AUTHORITATIVE | Ed25519 signatures against a key inside the log. Consistency, not identity. | SDK signing enabled |
| NON_AUTHORITATIVE_EVIDENCE | Hash chain intact. Detects edits to events, not a complete rewrite. | Default |
| PARTIAL_EVIDENCE | Chain intact but events were dropped during the session. | LOG_DROP events present |
| NO_EVIDENCE | Chain broken or structurally invalid. | Verification failed |
For most internal compliance purposes, NON_AUTHORITATIVE_EVIDENCE is sufficient. For regulatory submissions and legal proceedings where the operator is a party to the dispute, AUTHORITATIVE_EVIDENCE is the correct target (verified with the Archeion key pinned). See how the boundary is enforced.
Producing the record
Verification shows a log is internally consistent. The evidence pack turns that log into the artifact an auditor actually reads: a self-contained report plus a machine-readable manifest anyone can re-verify. One command, no server, no account.
The auditor-facing document: system under audit, Article 12 requirement checks, interaction timeline, evidence class, root hash, and data-minimisation note.
The machine-readable record. Re-verifiable independently with `sasana verify` — no Sasana tooling required for the cryptographic checks.
Same command, other frameworks: soc2, hipaa, siem. Exit code 0 compliant, 2 gaps, 3 error — drop it straight into CI. Want to see what a broken chain looks like first? tamper with a log.
What Sasana does not do
Hashes only. You cannot reconstruct what the agent said from a Sasana log.
Detects it after the fact. Detection and prevention are different properties.
Those are observability. Sasana is evidence production. Complementary.
Self-hosted only. Your evidence never depends on someone else's uptime, or honesty.