I walk into firms with AI policies sitting in SharePoint. They get cited in board decks. They show up in audit binders.

Then a model makes a decision, moves money, drafts client output, and the policy watches from the shelf.

That gap is a wiring problem.

Prose does not intercept a call. Prose does not sign an evidence record. Prose does not refuse an action because a control was not satisfied.

The Difference Between a Document and a System

A governance document describes what should happen.

A governance system enforces what does happen.

Those are two different objects. One is a record of intent. The other is an enforcement mechanism that runs at runtime, independent of whether anyone reads it, agrees with it, or remembers it exists.

The financial services industry has spent three years writing the first kind. Almost no one has built the second.

Policy documents are not built to intercept anything. They are built to describe. A policy that says "high-risk actions require human approval" does nothing at the moment a model calls a trading API at 2:14 AM on a Tuesday. The approver is asleep. The policy is on a SharePoint page that was last reviewed in Q3. The model proceeds.

This is not a compliance failure in the traditional sense. No one violated the policy. The system simply was not wired to enforce it.

That distinction matters when a regulator, an auditor, or a board asks: what actually happened, and what actually stopped it?

What the Numbers Show

AI-related incidents recorded in the Stanford AI Incident Database jumped to 362 in 2025, up from 233 in 2024. That's a 55% year-over-year increase.

AI deployment has scaled. Protective infrastructure has not kept pace.

IBM data shows 13% of organizations reported breaches specifically of AI models or applications in 2025. 97% of those breached organizations lacked proper AI access controls at the time of the incident.

Most AI security failures are preventable governance failures.

The gap is not knowledge. The gap is enforcement at the infrastructure layer.

What Governance-as-Infrastructure Requires

There are three structural components that separate real governance from documented intent.

1. Plane separation between the model and the control layer.

The model cannot be the thing that enforces its own constraints. That is a logical impossibility. A system that self-attests to compliance under pressure will attest to compliance under pressure.

The control layer must be architecturally independent. It must sit in the call path, not alongside it. When the model generates an action, the control layer evaluates it before it executes. Not after. Not during a post-hoc review. Before.

2. WORM evidence the vendor cannot rewrite.

Write Once, Read Many storage is not a feature request. It is the minimum condition for an evidence record that survives a dispute.

If the vendor holds the audit log and the vendor also holds the model, the vendor can correct the log. Not because they are dishonest, but because the system architecture allows it. That is not an acceptable structure in a regulated environment.

The evidence record needs to be hash-chained, timestamped at the moment of the decision, and written to storage the application layer cannot modify retroactively. Any log that does not meet those three conditions is documentation, not evidence.

A genuine audit log is immutable through two independent mechanisms. The first mechanism is WORM storage: Write Once, Read Many. This is a storage configuration where data, once written, cannot be modified or deleted for a defined retention period. Azure Blob Storage with a locked immutability policy enforces this at the infrastructure layer. Even the storage account owner, even Azure's own operations team, cannot delete or modify objects.

3. An independent enforcement path.

The application cannot be the thing that decides whether the application is behaving within bounds. That is the same logical trap as plane separation, applied to the enforcement mechanism itself.

An independent enforcement path means the control logic runs outside the application's trust boundary. It can halt execution. It can escalate. It can refuse. And it does those things based on the policy as encoded, not the policy as remembered by whoever built the application.

The Five Questions I Ask on Day One

When I walk into a firm that believes it has AI governance in place, I ask five questions. In order.

1) Where does the policy live?

If the answer is a document, it does not run. Policy that does not run is not governance. It is aspiration.

2) What sits between the user prompt and the model call?

If the answer is nothing, no control fires. The model receives instructions and acts on them. Every constraint in the policy document is bypassed by default.

3) Can you show me yesterday's decision record?

Not a log. A record with a hash chain and an independent writer. If the log can be edited by the application or the vendor, it is not a record. It is a draft.

4) Who approves a high-risk action at runtime, and how does the system know it was approved?

A name in a policy is not a signature in a system. If approval is not a precondition enforced by the control layer, it is a suggestion.

5) What does the agent do when a control fails?

If it proceeds, the control was never a control. It was a preference. Preferences do not appear in audit findings. Failures do.

Most programs fail on question two. The others usually fail on question three.

What the Regulator Will Ask

APRA's April 2026 AI letter signals an enforcement shift. APRA Member Therese McCarthy Hockey stated: "Where entities fail to adequately identify, manage or control AI risks in a manner proportionate to their size, scale and complexity, we will take stronger supervisory action and, where appropriate, pursue enforcement."

APRA identifies the widest gap between current practice and regulatory expectations in third-party and supply chain risk.

Under CPS 230, APRA expects material third-party risk to be managed with controls that are operative, not just documented. The July 1, 2026 deadline for pre-existing arrangements to be brought into compliance is approaching. Many AI providers will meet the material service provider threshold.

ISO 42001 requires that AI management systems include monitoring and measurement mechanisms, not just stated commitments. Clause 9 requires monitoring, measurement, analysis, evaluation, internal audit, and management review of AI management systems. Organizations must track the effectiveness of their AI risk management activities and feed results into continual improvement.

When a regulator asks to see the governance in action, they are not asking to read the policy. They are asking: show me the decision, the control that fired, the evidence signed at the moment it happened.

If the answer is a PDF, the answer is nothing.

That is not a harsh standard. It is the standard that has always applied to consequential decisions in regulated environments. AI systems that make consequential decisions are not exempt from it because they are new.

What This Looks Like When It Is Built Correctly

A governance system that actually runs looks something like this.

The model generates an action. Before that action executes, a control evaluation runs outside the model's trust boundary. The evaluation checks the action against the encoded policy: risk classification, approval requirements, scope constraints.

If the action passes, it proceeds and the decision is recorded with a hash, a timestamp, and the control result, written to WORM storage.

If the action fails, it halts. The reason is logged. The appropriate escalation path fires.

The application cannot modify the record. The vendor cannot rewrite it. The model cannot attest to its own compliance.

That is what governance-as-infrastructure means. It is not a policy update. It is an engineering project.

Why Most Firms Have Not Built It

Three reasons, in order of frequency.

First, the compliance function wrote the policy and the engineering function was never in the room. The document is thorough. The system was never specced.

Second, the vendor told the firm that governance was handled. What they meant was: the model has guardrails. Guardrails are not the same as an independent control layer. A guardrail is a preference built into the system being governed. It is the same trap.

Third, building real governance is slower and more expensive than writing a document. In a market where boards want AI deployed and auditors have not yet asked the hard questions, the incentive structure favors the document.

That changes the first time a regulator asks question three.

The Substrate

Governance-as-infrastructure is not glamorous work. There is no announcement when it is done correctly. The model acts. The control fires. The record is written. Nobody notices because everything worked.

That is the point.

The compliance theater version produces reports, slide decks, and policy updates. The infrastructure version produces tamper-evident records, independently verified decisions, and a control layer that does not require anyone to remember the rules.

One of those survives an adverse event. The other generates paperwork after one.

Writing policy is cheap. Wiring policy is engineering. The two are not interchangeable, and the gap between them is exactly where accountability disappears.