EU AI Act Article 12
The EU AI Act Evidence Gap: What Auditors Will Actually Demand
Notified bodies are already signaling stricter expectations
The conformity assessment ecosystem mobilized around the August 2025 notified body designation deadline. TUV SUD began offering voluntary AI Act conformity certificates in November 2025. Team-NB has warned of a potential shortage of designated bodies with AI expertise. Those that do achieve designation will apply rigorous standards.
Spain's AESIA regulatory sandbox has produced 16 technical execution guides covering specific documentation methods. Participants receive "exit reports" that conformity assessors must "take positively into account," establishing early precedent for what acceptable documentation looks like.
Under Annex VII, notified bodies will have extensive access powers: full access to training datasets via API, direct testing rights, and in exceptional cases, access to trained models themselves. Your dataset access logs will become audit targets.
The pattern is clear: vague text becomes strict practice
Every major regulation follows the same trajectory. Principles-based requirements evolve into highly specific audit expectations within 2-4 years.
What it evolved into
- 100 microseconds UTC divergence (HFT)
- 1 millisecond (algorithmic trading)
- WORM storage for 5-7 years
- 72-hour trade reconstruction on demand
Key lesson
Timing precision became 1,000,000x stricter
Article 12's "automatic recording of events" will become tamper-evident, cryptographically-anchored logging within 2-4 years of enforcement beginning.
How other regulations evolved from vague to prescriptive
Original requirement
"Accurate time source" for trading records
What it became
100 microseconds UTC divergence (HFT), WORM storage, 5-7 year retention, 72-hour reconstruction
Timing precision requirements became 1,000,000x stricter than original text implied
Original requirement
"Adequate internal control" (no definition)
What it became
COSO framework: 17 principles, 87 focus points, 40% Big 4 audit deficiency rates
Principles-based text became highly prescriptive through audit practice
Original requirement
"Appropriate technical measures"
What it became
2FA now expected (Haga Hospital fine), documented access procedures required
Accountability principle made documentation itself a compliance requirement
Original requirement
"Technical documentation" requirements
What it became
IEC 62304 audit trails, complete version control, traceability from requirements to tests
Medical device patterns are being imported directly into AI Act expectations
What auditors are preparing to assess
Based on prEN ISO/IEC 24970, prEN 18286, and emerging Big 4 practice areas, here's what conformity assessment will likely cover.
- Operation events (inputs, outputs, decisions)
- Automated monitoring events (drift, anomalies)
- Human oversight interventions (approvals, overrides)
Technical signals converging across audit guidance
While not explicitly mandated, these technical patterns address the practical question auditors will ask: how do you prove these logs haven't been modified?
Cryptographic chaining
Each log entry includes a hash of the previous entry, creating tamper-evident sequences
SHA-256 hash chains with Merkle tree rollups
WORM storage
Write-Once-Read-Many storage prevents modification of historical records
immudb, Amazon S3 Object Lock, Azure immutable blobs
Timestamp anchoring
Independent third-party timestamps prove records existed at a specific time
OpenTimestamps, RFC 3161 TSA, blockchain anchoring
Append-only architecture
Corrections become linked new versions rather than overwrites
Event sourcing, append-only ledgers, audit-trail-native databases
Evidence chain: from operations to audit-ready proof
Every step produces evidence a reviewer can verify independently, offline.
Auditors want proof that your QMS runs (records) and that the records are trustworthy (integrity proofs).
Where teams get this wrong
- Waiting for harmonized standards before implementing integrity controls
- Treating 6-month retention as sufficient when sector rules require longer
- Logging exists but integrity is unverifiable (no hashing, no chaining)
- Dataset access logs are missing or easily modified
- No independent timestamp proof that records existed when claimed
Build tamper-evident evidence into your AI operations
KLA provides cryptographically-anchored audit trails from day one.
- immudb-backed ledger: append-only evidence storage; each export is anchored to the ledger and the anchor record travels in the bundle
- OpenTimestamps anchoring: batch-anchored to Bitcoin hourly; the bundle carries the OTS receipt so the timestamp can be confirmed against the Bitcoin chain when you choose to
- S3 Object Lock: compliance-mode WORM storage for raw payload retention
- Evidence Room exports: signed bundles with per-artifact hashes and verification instructions
Don't wait for harmonized standards. Build the evidence architecture auditors will demand.
Verify evidence integrity with the CLI:
# Verify evidence bundle integrity kla evidence verify --bundle ./evidence-export.zip # Export with full hash chain kla export evidence \ --tenant $KLA_TENANT_ID \ --days 30 \ --include-timestamps \ --format pdf
What the verifier proves
The Evidence Room export ships with a standalone verifier that checks a bundle with no network access and no KLA infrastructure. Offline it proves the bundle is internally consistent: every input — data, proofs, and public keys — comes from the bundle itself.
Manifest signature
The manifest canonicalizes (RFC 8785 / JCS) and its digest recomputes. The detached JWS carries valid SEK and TEK ES256 signatures over that digest, checked against the public keys the bundle embeds in keys/jwks.json.
Merkle inclusion
Every artifact re-hashes (SHA-256) to the digest the manifest declares, each artifact's inclusion proof reaches the sealed root, and the recomputed Merkle root equals the manifest value.
Receipt signatures
Every governance receipt chain verifies: each receipt's ed25519 signature checks against a key embedded in the bundle, and each step's prevReceiptHash links to the prior step, genesis to last.
Ledger hash chain
Every exported ledger record re-hashes to its stated hash, and consecutive records link through previousHash end to end.
OpenTimestamps anchor
timestamp.ots parses under the strict OpenTimestamps rules and commits to the recomputed manifest digest. When the receipt is Bitcoin-attested the verifier reports its block height; a pending calendar receipt is accepted as pending Bitcoin confirmation.
What offline verification does not prove
- Authenticity needs an out-of-band key check. The SEK, TEK, and receipt signatures are all checked against the keys the bundle embeds in keys/jwks.json, so offline the bundle proves only that it is internally consistent. To prove it came from KLA, pin those keys against a KLA-published JWKS or key fingerprint.
- The OpenTimestamps Bitcoin anchor is trusted offline. Confirming its block height compares the proof against the live Bitcoin chain, and a pending calendar receipt stays pending until a calendar upgrade.
- The immudb ledger anchor's proof is present and parses offline. Confirming its inclusion against the ledger's signed state needs a networked check.
FAQ
Does Article 12 explicitly require cryptographic integrity?
No, but the pattern from MiFID II, SOX, GDPR, and MDR is unambiguous: principles-based text becomes prescriptive practice within 2-4 years. Auditors and notified bodies will interpret "automatic recording" to mean tamper-evident logging.
What retention periods apply to AI logs?
Article 12 specifies 6 months minimum for automated logs, but sector-specific requirements often override this. Financial institutions should expect 5-7 years. Technical documentation must be retained for 10 years after the system is placed on the market.
When will harmonized standards be published?
prEN ISO/IEC 24970 (logging standard) is in Draft International Standard ballot. prEN 18286 (QMS standard) entered public enquiry in October 2025. Final standards expected Q4 2026, but auditor expectations are forming now.
What access will notified bodies have?
Under Annex VII, notified bodies can require full API access to training, validation, and testing datasets. They may conduct direct tests if unsatisfied with provider evidence. Dataset access logs will themselves become audit targets.
How should we handle ML model auditability?
Thresholds for extensive logging remain unclear, but auditors will likely expect: model version tracking, hyperparameter changes, training run metadata, and decision traceability for high-risk outputs.
Related Resources
Continue your EU AI Act compliance journey.
Article 17 QMS Template
Quality Management System template for high-risk AI with prEN 18286 mapping.
Don't Wait for the Standards to Catch Up
The gap between Article 12's text and practical audit expectations will close quickly. Organizations that anticipate stricter requirements will have significant competitive advantages when conformity assessments begin.