The decisions that determine whether an AI system can be audited are made before a single output is produced. Output logging, cryptographic attestation, and chain of custody are not features that can be added after the fact. They are architectural properties. Organizations that build AI systems without them will find, when a regulator asks, that retrofitting is expensive, partial, and often not sufficient.
Why Accountability Cannot Be Retrofitted
Consider what it means to produce a verifiable audit trail for an AI output. You need to record what input was provided, what model version was used, what parameters were active, what output was produced, and when. You need to record this in a way that cannot be modified after the fact, because an audit trail that can be modified is not a trail at all.
If you wait until after deployment to implement this, you face a fundamental problem: you have no records for any output produced before the implementation. More importantly, if your logging infrastructure runs in the same environment as your application, your audit trail is controlled by the same party whose compliance is being assessed. It can be disputed.
Provenance infrastructure needs to be part of the architecture from the start, not a compliance layer bolted on afterward.
Output Logging: What to Capture
The minimum useful record for an AI output contains: the input or a hash of the input; the model identifier and version; the output or a hash of the output; the timestamp of production; and the identity or identifier of the system or user that initiated the request.
For systems subject to the EU AI Act's Article 12, logging must also capture the reference databases used in any retrieval-augmented generation, the start and end dates of operational periods, and, where technically feasible, the input data that led to a given result.
Where capturing the full input and output creates privacy concerns, hashing is appropriate. A cryptographic hash of the input and output, stored with the metadata, provides a record that can verify content integrity without storing the content itself. If the original content later becomes available, the hash proves whether it matches the recorded version.
Cryptographic Attestation
A log record stored in a database controlled by the operator proves nothing. Any competent database administrator can modify it. For audit purposes, what matters is not just the record, but evidence that the record has not been altered since it was created.
Cryptographic attestation uses hash functions and digital signatures to produce a proof that a record existed in a specific form at a specific time. The hash of an output, signed with a private key associated with the producing system, creates an unforgeable link between the output and the identity of the system that produced it.
The limitation of signature-based attestation is that it depends on the signer's key management. If the signing key is compromised or the signer later repudiates the attestation, the record can be disputed. External verification requires trusting the signer.
Chain of Custody Across Model Versions
Modern AI deployments involve model versioning, fine-tuning, and retrieval-augmented generation pipelines that combine a base model with dynamic context from external sources. A single user interaction may involve multiple model versions, multiple retrieval steps, and multiple intermediate outputs.
A complete chain of custody needs to track each component. For a RAG pipeline, this means recording not just the final output but the retrieval results that were included in the context, the version of each retrieval index, and the version of the base model. A response produced by one model version with a retrieval index from a particular date is a different output from the same query run the following week against an updated index. If the audit question concerns what information was available to the model when it produced a response, the chain of custody needs to capture the full context.
On-Chain Attestation: What It Provides That a Database Cannot
An on-chain attestation is a hash committed to a blockchain. The blockchain provides an independent timestamp that does not depend on the operator to maintain. Once committed, the hash cannot be modified without invalidating the chain's state, which any observer can detect.
This provides three things a database cannot. First, the timestamp is independent: the block timestamp is set by the network, not the operator. Second, the record is tamper-evident: any modification to the committed hash is detectable by anyone with access to the chain. Third, the record is independently verifiable: any party can verify the attestation without relying on the operator to produce or maintain the record.
For compliance purposes, this means an organization can produce a verifiable attestation record to a regulator that the regulator can verify independently. For IP purposes, it means an organization can prove in legal proceedings that a specific output existed in a specific form at a specific time, without requiring the court to trust the organization's internal systems.
Mintlayer's IP Notary and Compliance Sentinel provide on-chain attestation infrastructure for AI outputs and decisions, building provenance into the architecture rather than attempting to reconstruct it after the fact.
This article is for informational purposes only and does not constitute investment advice.
Mintlayer Web Services helps developers and organizations build on Bitcoin-native infrastructure. Learn more →
