Every large enterprise now has an AI ethics policy. Most have an AI governance framework. Many have appointed responsible AI officers and standing ethics committees. And yet, when regulators ask these same organisations to demonstrate that a specific AI decision was made compliantly — to show what data the system used, what it decided, and how that decision was reviewed — the answer is often: we cannot show you that.
The policy exists. The data does not.
The Policy Fallacy
The natural instinct when faced with new regulation is to write policy. The EU AI Act requires a risk management system? We will write a risk management policy. It requires human oversight? We will write a human oversight policy. It requires technical documentation? We will create a documentation template.
Policies are necessary but insufficient. They define what should happen. They do not create evidence that it happened. And in regulatory compliance, the evidence is the compliance. A policy that says AI systems will be monitored for bias, held alongside systems that produce no monitoring data, is not a compliance asset. It is a liability — because it demonstrates that the organisation knew the requirement existed and failed to implement it operationally.
The Actual Bottleneck
The bottleneck in most AI compliance programmes is not a policy gap. It is a data gap. Specifically: the inability to produce decision-level evidence of AI system operation — tamper-evident records that show, for any given AI decision at any given point in time, what inputs the system processed, what output it produced, and what happened next.
This data gap is not the result of negligence. It is the result of AI systems being built for operational performance, not compliance evidence. A recommendation engine optimised for click-through rate is built to be fast, accurate, and efficient. It is not typically built to generate a cryptographically-chained audit log of every recommendation it makes, with sufficient metadata to trace any future regulatory query back to the specific model version, input vector, and output confidence that produced the recommendation. Those are different engineering requirements.
What Compliance Evidence Actually Looks Like
Compliance evidence for AI systems has three properties. First, it is decision-level: it records individual AI outputs, not aggregate model performance. Knowing that your hiring AI has 91% accuracy on your test set does not tell a regulator what happened in the specific case they are investigating. Second, it is tamper-evident: a regulator must be able to verify that the record presented to them reflects what the system actually did, not a retrospective reconstruction. Third, it is retained: it must exist at the time it is requested, which may be months or years after the decision was made. Most AI logging architectures fail on at least one of these three dimensions.
Solving the Data Problem
The solution is architectural, not procedural. It requires building AI compliance infrastructure into the AI system layer — a dedicated logging pipeline that captures decision-level records at inference time, hashes them cryptographically, writes them to tamper-resistant storage, and maintains them for the required retention period. This infrastructure is independent of the AI system's production function: it operates alongside the model, not within it, so that a model update does not affect the compliance record of previous decisions.
Policies can then be written against this infrastructure with confidence — because the policies describe what the data shows, rather than what the organisation hopes happened. Compliance becomes evidenced, not asserted. And when regulators ask the question — show me what your AI system decided, and how — the answer is: here it is.