EU AI ACT · SOC 2 · HIPAA

What Article 12 requires, what it doesn’t, and what a dispute requires anyway.

01

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 deadline: the Digital Omnibus provisional agreement of 7 May 2026 moved the high-risk deadline for stand-alone systems to 2 December 2027, pending formal adoption. The original 2 August 2026 date remains in law until that process completes. Treat August 2026 as the planning deadline — the audit infrastructure work takes months 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 immutability. Defensible evidence production requires it regardless.

02

Requirement → mechanism

Automatic recording of events throughout the system's lifetime
Art. 12(1)
SDK hooks / passive observer record every session automatically — zero code changes with `sasana observe`. Every OpenClaw session produces a JSONL trail by default.
Logs that enable verification of system operation (traceability)
Art. 12(2)
Five-check verifier, runnable by anyone — regulator included — with no server, no API key, no network. Exit codes 0/1/2/3 for CI.
Evidence that survives a dispute, as part of a functioning risk-management system
Art. 9 + Art. 12 read together
SHA-256 hash chain over RFC 8785 canonical JSON: any post-hoc modification is detectable. Evidence class states exactly how strong the guarantee is.
Records whose claimed time can be independently verified
the question a regulator will actually ask
RFC 3161 anchoring: an independent TSA signs the SESSION_START hash at creation time. Backdating requires forging the TSA's signature.
Logging that doesn't itself create a data-protection problem
GDPR / HIPAA §164.312(b)
Hashes only — raw prompts, responses, and PHI are never stored. The audit trail can be handed over without disclosing content.
03

The five evidence classes

classwhat it meanswhen you have it
AUTHORITATIVE_EVIDENCEIndependent party sealed it. Agent could not have forged this.Archeion sealed
SIGNED_NON_AUTHORITATIVEEd25519 signatures present. Requires private key to forge.SDK signing enabled
NON_AUTHORITATIVE_EVIDENCEHash chain intact. Proves no post-hoc modification.Default
PARTIAL_EVIDENCEChain intact but events were dropped during the session.LOG_DROP events present
NO_EVIDENCEChain 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 — see how the boundary is enforced.

04

What Sasana does not do

Does not record raw content.

Hashes only. You cannot reconstruct what the agent said from a Sasana log.

Does not prevent tampering.

Detects it after the fact. Detection and prevention are different properties.

Does not replace LangSmith or Arize.

Those are observability. Sasana is evidence production. Complementary.

Does not have a managed cloud.

Self-hosted only. Your evidence never depends on someone else's uptime — or honesty.