Begin with the question an auditor must answer
“Make the AI auditable” is not a specification. A regulator may need to reconstruct which system version affected a person. An operator may need to determine whether a policy check ran. A researcher may need to reproduce an output. A security team may need to know whether execution occurred in an approved environment. Each question requires different evidence, retention, access, and assurance. The first design artifact should be a set of audit questions and threat actors, not a choice of blockchain or proof system.
A minimum decision record binds a request identifier, time, actor or service identity, purpose, authorization result, input references or commitments, model and dependency versions, configuration, output, uncertainty or abstention, policy version, human action, and downstream state change. Sensitive inputs usually should not be copied into a widely shared log. Hashes, encrypted references, access-controlled storage, and retention schedules can preserve linkage while respecting minimization and correction requirements.
Separate provenance, integrity, execution, and correctness
A digital signature authenticates a signer under a key and makes alteration detectable. A hash binds bytes. An append-only transparency service makes inconsistent history more detectable. Remote attestation supplies evidence about a computing environment. A zero-knowledge proof can demonstrate that a stated computation or policy relation held without exposing all inputs. None of these mechanisms proves that a sensor was calibrated, a label was correct, the training set was representative, or the decision rule was legitimate.
This separation prevents “verified” from becoming an unbounded marketing adjective. The evidence statement should name the property: artifact integrity verified; signer credential valid at signing time; environment matched approved measurements; computation proof checked; or log inclusion confirmed. Substantive evaluation remains necessary for accuracy, calibration, discrimination, human rights, clinical utility, and lawful purpose. Cryptography can make an evidence chain harder to rewrite; governance determines which chain deserves trust.
Attestation is a policy-mediated claim
IETF RFC 9334 describes an Attester that creates Evidence, a Verifier that appraises it using reference values, endorsements, and policy, and a Relying Party that uses the resulting Attestation Result. The architecture is neutral to processor and protocol. This matters because attestation is not a magical statement that a machine is secure. It is a structured claim that observed measurements satisfied a verifier’s policy at a relevant time.
Reference values and endorsements need their own provenance, expiry, revocation, and compromise response. A measured software identity can match an approved version that contains a vulnerability. A trusted execution environment reduces some exposure while adding hardware, firmware, side-channel, and vendor dependencies. The relying party must define freshness, acceptable evidence, fallback, and action when appraisal fails. High-consequence systems should rehearse key revocation, verifier outage, reference-value error, and enclave compromise rather than assume the attestation path is infallible.
Regulatory logging raises the minimum evidence floor
The EU AI Act requires high-risk AI systems to technically allow automatic event recording over their lifetime and requires providers to retain logs under their control for a period appropriate to purpose, with a baseline of at least six months unless other Union or national law provides otherwise. The regulation also connects logs to traceability, monitoring, human oversight, and incident obligations. Retention is therefore not a universal “store everything” instruction; privacy and other laws continue to apply.
A compliant-looking log can still be operationally useless if timestamps drift, identifiers cannot be resolved, model versions are ambiguous, or events omit the human decision. Teams need a canonical event schema, trusted time, sequence and correlation identifiers, access controls, tamper evidence, tested export, and documented semantics. Monitoring should verify log completeness and not only protect stored entries. Deletion, legal hold, correction, and subject-access workflows must be designed alongside immutability claims.
Design for algorithm and key migration
NIST approved FIPS 203 for module-lattice key encapsulation and FIPS 204 and 205 for module-lattice and stateless hash-based digital signatures in August 2024. These standards provide concrete migration targets; they do not make every system quantum safe. Inventory is prerequisite: which data and records need confidentiality or signature validity for how long, which protocols and hardware embed vulnerable algorithms, and which counterparties control upgrades?
Long-lived decision evidence particularly needs crypto-agility. The record should identify algorithm, parameters, certificate chain, signing time, and validation policy. Systems may need to preserve old signatures, add trusted timestamps, or re-attest archives under new schemes without falsely rewriting origin. Migration tests should include size, latency, hardware support, failure interoperability, and rollback. Algorithm diversity can reduce common-mode risk but increases operational complexity; it should be governed as an engineering trade, not a decorative feature.
A falsifiable auditability test
An auditability programme should run reconstruction exercises against sampled and adversarial decisions. Can an independent reviewer identify the authorized actor, exact model, input provenance, applicable policy, output, human intervention, and downstream effect? Can the reviewer detect a removed or reordered event, a revoked key, an unapproved environment, a stale consent, or a model substituted after the fact? Can the organization answer within the decision’s regulatory and operational time window without exposing unrelated sensitive data?
NIST’s AI RMF organizes risk work through Govern, Map, Measure, and Manage, with governance crossing the lifecycle. Cryptographic controls serve each function only when connected to owners and response. A failed proof must stop or safely degrade an action; a detected discrepancy must open an incident; a corrected record must retain accountable history. The mature claim is narrow and testable: for a defined decision class and threat model, the organization can reconstruct and validate specified properties of the decision chain. Truth and justice still require evidence beyond the chain.
Scope and limitations
Cryptographic assurance depends on key security, implementation quality, trusted roots, reference values, policy, and endpoint integrity. Remote attestation and transparency mechanisms address selected threats and can introduce new privacy or availability risks. The EU AI Act requirements cited apply within a specific legal framework and phase-in schedule. Post-quantum standards continue to acquire implementation guidance. This article is a systems-security framework, not a certification, legal opinion, or proof that any machine decision is fair, accurate, or lawful.
References
Source review: 20 August 2026. Quantitative values retain their original definitions, periods, and boundaries.
- 01Approval of Three Federal Information Processing Standards for Post-Quantum Cryptography
US National Institute of Standards and Technology · 2024
csrc.nist.gov ↗ - 02Artificial Intelligence Risk Management Framework 1.0
US National Institute of Standards and Technology · 2023
nvlpubs.nist.gov ↗ - 03Regulation (EU) 2024/1689, Artificial Intelligence Act
Official Journal of the European Union · 2024
eur-lex.europa.eu ↗ - 04RFC 9334: Remote ATtestation procedureS Architecture
Internet Engineering Task Force · 2023
www.rfc-editor.org ↗ - 05C2PA Content Credentials Technical Specification 2.2
Coalition for Content Provenance and Authenticity · 2025
spec.c2pa.org ↗ - 06Secure Software Development Framework Version 1.1
US National Institute of Standards and Technology · 2022
csrc.nist.gov ↗