Does tamper-evident require blockchain?

No. Blockchain is one option for external anchoring. The same property is achievable with RFC 3161 timestamping, certificate transparency-style append-only logs, separately administered audit services, or internal anchoring across separately administered systems. The choice depends on the threat model, the operational complexity tolerated, and the cost. For most enterprise AI compliance use cases, a managed timestamping service or an append-only object storage tier with cross-account replication is sufficient.

What is the difference between tamper-evident and immutable?

Immutable means the records cannot be altered. Tamper-evident means alteration is detectable. Immutability is stronger and harder to deliver. The regulatory regimes typically expect tamper-evident properties, not strict immutability. The legal value of tamper-evident is that any alteration becomes part of the audit narrative; the alteration itself is a finding that the regulator can act on.

How is the signing key protected?

The signing key is held in a hardware security module (HSM) or in a cloud KMS with restricted access and rotation policies. Access to the key for signing is granted to the inspection layer's service account. Access for key management is granted to a small set of administrators under separation of duties. Use of the key is logged and the log is itself tamper-evident. Key rotation is performed on a documented cadence with overlap so that records signed under previous keys remain verifiable.

What happens if the chain is broken?

A broken chain is a finding. The verification process detects the break and reports the affected records. The handling depends on the cause. A legitimate operational event (corrupted storage, failed migration) requires recovery from a backup that pre-dates the break. A potential tampering event triggers an incident investigation. In either case, the audit narrative captures the break and the resolution. The records on either side of the break remain verifiable within their sub-chains, anchored to the external commits.

How do tamper-evident logs interact with the data subject's right to deletion?

GDPR, CCPA, and similar regimes give data subjects the right to request deletion of personal data. Audit logs are typically subject to a regulatory retention obligation that overrides the deletion right. The interaction is reconciled by retaining the records, redacting or pseudonymizing the personal data within the records where the technical scheme supports it, and documenting the override in the audit file. The cryptographic integrity is preserved across the redaction by recording the redaction as a separate event with its own signature, rather than by modifying the original record.

Tamper-Evident Audit Logs for AI: What Cryptographic Integrity Brings to Compliance Records

A tamper-evident audit log is a log where any modification to a committed record is detectable through cryptographic integrity. The property does not prevent modification; it makes modification visible. For AI compliance records, the distinction matters because regulators do not require unforgeable storage. The regulators require evidence that the records they review are the records that were produced at the time of the decision. Application logs that the application can modify silently do not produce that evidence. A per-decision AI audit log with cryptographic integrity does.

I want to walk through the cryptographic mechanisms that make a log tamper-evident, the operational characteristics that matter for AI compliance specifically, where the technique sits in the broader audit architecture, and the regulatory regimes that depend on it.

What tamper-evident means precisely

Tamper-evident is a property of a log, not a property of storage. The property means that if any record is altered, inserted, deleted, or reordered after commit, the alteration is detectable by an independent verifier with access to the integrity material.

The property is weaker than tamper-proof, which would prevent modification entirely. Tamper-proof storage requires either physical isolation (write-once media) or trusted execution environments with hardware-enforced immutability. The cost is high and the use cases are narrow. Tamper-evident, by contrast, is achievable with standard cryptographic primitives and integrates with mainstream storage.

For an auditor, tamper-evident is sufficient. The auditor needs to know that the records on review are the records that were produced. The auditor does not need a guarantee that modification was impossible; the auditor needs assurance that modification, if it occurred, would be detected.

The cryptographic mechanisms

Three mechanisms combine to produce tamper-evident logs.

Per-record signing

Each record is signed at commit. The signing key is held by an entity separate from the application that produced the record (typically the inspection layer or the audit infrastructure). The signature covers the record's content, its timestamp, and its position in the sequence. A verifier with access to the signing public key can confirm that a specific record was signed by the inspection layer and has not been altered.

The choice of signature scheme depends on operational requirements. EdDSA (Ed25519) is fast and produces compact signatures. ECDSA over P-256 has broad library support. RSA-PSS is slower but interoperates with older systems. The key management uses HSMs or cloud KMS with rotation and access control.

Hash chaining

Each record's signature commits to the previous record's hash. The chain is a Merkle-like sequence where any modification to a middle record breaks the chain at the next record. A verifier walks the chain forward and detects breaks.

Hash chaining provides ordering integrity. An attacker who modifies one record has to recompute all subsequent records to keep the chain consistent. The attacker also has to re-sign each modified record, which requires access to the signing key.

External anchoring

The hash chain is periodically anchored to an external system whose history the attacker cannot rewrite. The anchor can be a blockchain transaction, a public certificate transparency log, an external timestamping service (RFC 3161), or a separately administered audit log. The anchor commits the chain's state at a point in time. Any modification to the chain prior to the anchor produces a detectable inconsistency with the anchor.

External anchoring closes the case where the attacker controls the signing key. Without the anchor, an attacker with the key can re-sign a forged chain that is internally consistent. The anchor makes the forgery detectable because the anchored state does not match the new chain.

Operational characteristics that matter for AI compliance

Five operational properties have to be specified.

The first is record volume. AI deployments at enterprise scale produce records at rates from tens to thousands per second. The signing and chaining have to operate at that rate without becoming the bottleneck. Modern hardware signs Ed25519 at hundreds of thousands of signatures per second per core.

The second is record retention. The EU AI Act Article 19 floor is six months. Sector regimes extend retention to seven years and beyond. The integrity material has to persist for the full retention period and the verification has to be possible across the period.

The third is read access. Auditors, regulators, and internal teams need read access to the records and the integrity material. The access has to be granular by tenant, role, and time window. The audit infrastructure has to log its own access (the audit-of-the-audit), which is also tamper-evident.

The fourth is searchability. The records have to be searchable by identity, time, tenant, classification, and outcome. The cryptographic integrity material has to allow per-record verification on retrieval, which works only if the chain structure supports random access through a tree or an external index.

The fifth is regulatory acceptance. The auditor's acceptance of the records depends on documentation of the cryptographic scheme, the key management practices, the access controls, and the verification procedure. The documentation is part of the audit file and is reviewed alongside the records.

Where tamper-evident logs sit in the audit architecture

The audit architecture has four layers.

The first layer is the producer. The producer is the inspection layer that intercepts the AI request, evaluates the policy, and emits the record. The producer's signing key is the source of the cryptographic integrity.

The second layer is the durable storage. The storage holds the records and the chain. Object storage with versioning, append-only buckets, and immutable storage classes are common choices.

The third layer is the verifier. The verifier reads records on demand, walks the chain, validates signatures, and reports integrity status. The verifier runs independently of the producer.

The fourth layer is the external anchor. The anchor periodically commits the chain state to an external system. The frequency is a tradeoff between operational complexity and the maximum undetected modification window.

The four layers are conceptually separable. In practice they may live in the same cloud account, the same region, or the same vendor. The separation matters for the threat model. An attacker who compromises one layer should not be able to compromise the others.

Regulatory regimes that depend on tamper-evident logs

EU AI Act Article 12 expects records that allow regulators to identify risk situations and reconstruct what happened. The expectation includes that the records are the records that were produced, which is the tamper-evident property.

Fannie Mae LL-2026-04 requires audit trails that permit reconstruction of AI-assisted decisions. Lender-controlled logs that the lender can modify do not satisfy the GSE's audit expectations.

HIPAA's audit controls (45 CFR 164.312(b)) require mechanisms to record and examine activity in information systems containing ePHI. The implementing guidance is open to cryptographic integrity as a means of meeting the standard.

DORA's ICT incident reporting requires firms to reconstruct incidents from records that hold up in supervisory dialogue. The supervisor accepts records that show integrity properties consistent with the firm's documented audit architecture.

NIST AI RMF and the NCCoE's AI agent identity and authorization framework expect action lineage records (Pillar 3) that support post-hoc investigation. Tamper-evident logs are the canonical implementation.

DeepInspect

This is the gap DeepInspect closes for enterprises that need tamper-evident AI audit records. DeepInspect's per-decision audit record is signed at commit, chained to the previous record, and committed to durable storage before the model response returns to the calling application. The audit infrastructure runs independently of the calling application and the signing key is held outside the application's blast radius.

For an auditor or regulator, the records are verifiable on demand. For an internal investigation, the records support reconstruction with cryptographic confidence. For a vendor that has to produce records on a customer's audit request, the records carry the integrity properties the customer's reviewer expects.

If you are building AI infrastructure for a regulated environment and your audit story depends on application logs the application can modify, book a technical deep dive at deepinspect.ai.