Audit Will Not Make AI Safe
Ask almost anyone in compliance where the field ought to be heading and the answer comes back the same. Compliance should become proactive. It should anticipate risk rather than react to it. It should build the capability to meet obligations, not merely the paperwork to prove them.
The obligations themselves have already moved. Regulation and standards have shifted toward risk-based and outcome-based designs, and they now ask organizations to contend with uncertainty and achieve results rather than follow prescription alone. There is broad agreement on the destination.
What is remarkable is how little the practice of compliance has moved, even as the obligations already have.
I wrote a few years ago that compliance needs to change, and that the reactive model most companies still run has been quietly working against the very outcomes they are trying to achieve.
That is still true. What I did not name clearly enough at the time was the reason the reactive model persists. It persists because the audit regime holds it in place. Audit is not a neutral check on compliance.
Audit is the mechanism that keeps compliance reactive.
Reactive by Design
Consider what an audit actually does. It samples evidence after the fact. It compares that evidence against documented procedure. It produces findings, and those findings are closed through corrective action. Every part of that sequence looks backward. An audit can tell you what already happened. It cannot tell you what is about to.
I made a related point in the earlier paper. There is an important difference between verifying what has already happened and preventing what has not yet happened. Financial audit was built for the former. Safety, quality, and risk live in the latter. When we borrow the financial audit model and apply it to outcomes that have not yet occurred, we are using an instrument built to look back as though it could look forward. It cannot.
The reactivity is not a flaw in how audit is practised. It is what audit is.
The Vicious Cycle
A reactive instrument is a problem on its own. What makes it worse is that the burden does not stay fixed. It grows with every cycle.
Each finding is closed by adding something: a control, a checkpoint, a document. More procedure creates more surface to audit. More surface produces more findings. More findings produce more procedure. The apparatus grows on its own momentum, and every increment of complexity introduces new ways to fail and new things to inspect. The mechanism meant to correct the system is the same mechanism that inflates it.
This is the pattern behind the misuses I described before. When audit findings are treated as requirements, the ratchet turns, and the auditor's interpretation becomes the obligation the program must now grow to satisfy. When companies run pre-audits to prepare for internal audits to prepare for external audits, the parallel apparatus has already taken over. An entire second system now exists whose only purpose is to prove compliance to someone else's uncertain benchmark.
What I once catalogued as four common misuses are not accidents of poor practice. They are what a reactive instrument produces when a company relies on it.
Two forces make the cycle worse.
The first is that people begin to manage the measure instead of the outcome. Because the audit scores what can be documented, effort migrates toward looking compliant, and a company can become very good at passing audits while becoming no safer at all.
The second is that the work of feeding the audit crowds out the work of building capability. The busier a company is closing findings, the less time it has to prevent the next one, and so it stays perpetually behind.
Assurance Does Not Come From Audit
Here is the point we keep getting wrong.
Compliance does need assurance. Regulators, boards, and stakeholders are right to want confidence that obligations will be met, and not only that they were met once. That confidence does not come from an audit. It comes from capability.
Assurance is the confidence that a company can keep its promises today, tomorrow, and every day after.
No inspection can manufacture that. An audit can attest to a moment already past. The capacity to meet an obligation in the future is a property of how the work is designed, resourced, and operated.
It is built into the organization, or it is not there at all. A certificate on the wall says a sample looked acceptable on the day it was taken. It says nothing about whether the capability exists to keep the promise tomorrow.
This is the mistake compliance has made for decades. We have treated assurance as something an auditor confers rather than something an organization possesses. We are now about to make the same mistake, at scale, with AI.
The Same Mistake, Now Applied to AI
New regulation for AI is arriving, and the predictable response is already taking shape. The audit regime will stand up to meet it. Certification schemes, conformity assessments, and audit checklists are being assembled to answer the new obligations in the only language the existing apparatus knows, which is documented conformance verified after the fact.
We should see where this leads, because we have watched it before.
Most businesses will not build safety into their AI systems. They will hire external auditors to certify that they have the appearance of being safe. The certificate will attest to a snapshot. The behaviour of the system in the world, which is precisely the thing that matters and precisely the thing that changes, will go unaddressed.
The vicious cycle will reassert itself, the same misuses will follow, and organizations will feel more protected while becoming less safe, at a moment when the distance between appearing safe and being safe carries far greater consequences than it ever did before.
AI does not tolerate a reactive compliance model.
Its behaviour is variable, fast, and often novel. An instrument that samples the past cannot regulate a system whose risks are still forming. The range of what can go wrong outruns anything an audit checklist can hold.
Applying the audit regime to AI is not a partial solution that time will improve. It is a category error, and it will give companies confidence in exactly the wrong thing.
But We Still Need Independent Assessment
The most common objection to all of this is that organizations still need independent assessment. They do. Independence has real value, and nothing here argues against it. The objection skips over the only question that matters, which is what the independent assessor is actually assessing.
Asking this plainly.
Does the auditor assess the level of safety a system has achieved? Does the auditor assess the organization's capacity to remain safe as conditions change?
In almost every case the answer is no. The auditor checks whether the documentation is in order and whether procedure was followed. That is an assessment of the appearance of safety. It can be independent, rigorous, and still beside the point.
Independent assessment is worth keeping. What has to change is what it assesses.
An assessor should be asking whether the organization is safe and whether it can stay that way.
That is a question about real capability, not about whether the documents are in order. Point independent assessment at the capacity to be safe rather than the appearance of it, and independence becomes an asset again instead of a ritual.
What This Requires
It comes down to one question.
Where does assurance come from?
Assurance has to be built. It cannot be inspected into existence. It belongs in the first line, where managerial accountability exists. The people who do the work produce the assurance, because no one else can. That means designing compliance into the work, not bolting an audit on at the end. It means measuring capability, not just documents. It means moving the feedback ahead of the harm, so a company knows it can meet an obligation before it is tested. Verification still belongs inside this system. What changes is that it serves capability instead of standing in for it.
Audit can tell us what happened. Only capability can assure us of what will. That difference has always mattered, and with AI it becomes decisive. A system whose behaviour is fast, variable, and still forming will not be made safe by a certificate that attests to a moment already past. It will be made safe by building the capability to stay safe, and by assessing whether that capability is real.
Every organization adopting AI now faces the same choice. Build safety in, or buy the appearance of it. Only one of them makes you safe.
Building safety in has a name. I call it Forward Assurance. It builds the capability to be safe into how an AI system is designed and run, and it gives the organization ongoing evidence that the capability is real and working. It shows whether you can meet your AI obligations today and keep meeting them, not whether you passed an audit last quarter.
