When a tax authority audits a company's expenses, they do not accept a policy that says "we only book legitimate business expenses." They ask for receipts — the original, timestamped, source-level evidence that a specific transaction occurred, in a specific amount, for a specific purpose, on a specific date.
AI regulation is going the same way. And most organisations are not ready for it.
The AI Receipt
The "receipt" for an AI decision is the decision-level log: a tamper-evident record that captures what the AI system processed, what it decided, when it decided, which version of the model was active, and what happened to the decision afterwards. It is not a summary report. It is not an aggregate accuracy metric. It is the specific, individual-level record for a specific decision at a specific point in time.
When a regulator investigates an adverse AI outcome — a discriminatory credit denial, a wrongful benefits termination, a biased hiring recommendation — they will ask for this receipt. They will want to see the input data that fed the model, the output the model produced, and the chain of custody from AI output to real-world consequence. They will want to verify that the record has not been altered since the decision was made. And they will want to be able to reconstruct the full decision environment: what model version was running, what data it was trained on, what its performance metrics were at time of deployment.
Why Most Organisations Cannot Produce This
Most enterprise AI systems were not built to produce receipts. They were built to produce decisions — fast, accurate, at scale. The infrastructure for generating, storing, and maintaining tamper-evident decision-level records is separate from the inference infrastructure, and in most organisations it does not exist.
What exists instead is a patchwork: application logs that capture some events but not others, database records that can be modified by administrators, aggregate dashboards that show model performance but not individual decisions, and documentation that describes intended system behaviour rather than actual system behaviour. This patchwork is not the receipt. It is a description of the drawer where the receipt was supposed to be kept.
Building the Receipt System
The technical components of an AI receipt system are not exotic. They are: a logging layer that captures decision-level records at inference time; a cryptographic integrity layer that hashes each record and chains the hashes to detect any subsequent modification; a retention layer using WORM-compliant storage that prevents deletion or modification for the required retention period; and a retrieval layer that makes specific records findable on demand without the retrieval process creating integrity risks.
What requires investment is not the technology — it is the decision to treat AI compliance evidence as a first-class infrastructure concern, at par with the AI system's production function. That decision is increasingly not optional. The EU AI Act's Article 12, the FTC's AI guidance, the UK ICO's AI auditing framework, and the emerging global consensus on AI accountability all point to the same requirement: show your work. Produce the receipt. Demonstrate that your AI system did what you say it did, in the way you say it did it, for the people you say it served.
The organisations that will navigate the coming wave of AI regulation with minimal disruption are those building receipt systems now — before the regulator asks.