Most AI governance fails at runtime. Not because policies are missing. Not because principles haven’t been documented. Because at the moment a decision executes, nothing technically prevents an unauthorised action from going through.

You have governance frameworks. You have monitoring dashboards. You have post-hoc audit logs and model explainability tools. And yet, if someone in your organisation asked right now — “who authorised this specific AI decision, under what mandate, with whose authority, at exactly that moment?” — most teams would reach for log files and start reconstructing.

That reconstruction exercise is forensic archaeology. It is not governance. And the gap between what organisations document and what they can actually enforce is widening every quarter that autonomous AI systems proliferate without a runtime authority plane.

This is compliance cosplay. It looks right. It photographs well for auditors. And it cannot technically prevent a single unauthorised decision from executing.

The Governance Gap: Why Post-Hoc Always Fails Structurally

Here is the brutal version of where the industry sits. Only 7% of organisations have fully embedded AI governance despite 93% using AI in some capacity.¹ Among organisations that experienced AI-related breaches, 97% had no proper AI access controls in place — despite having policies.² Seventy per cent lack optimised governance entirely, meaning they cannot demonstrate board-level risk reviews, automated monitoring, or policies updated after incidents.³

The governance gap is not primarily a policy problem. It is an enforcement problem. Organisations write policies and then discover they have no mechanism to make those policies binding at the point where it matters — execution.

The UnitedHealth nH Predict case makes this concrete. UnitedHealth deployed an AI system to guide Medicare Advantage claim decisions. The governance position was explicit: the AI guides but does not make final decisions. Humans retain authority. The policy was documented.

Then a STAT investigation found that UnitedHealth was setting targets for employees to keep patient rehabilitation stays within 1% of nH Predict’s predictions.⁴ Plaintiffs alleged the system was used “systematically and without proper oversight.”⁵ The metric that crystallised the failure: the algorithm had a 90% overturn rate on appeals — nine out of ten times a human reviewed the AI’s denial, they reversed it.⁶ The US District Court for Minnesota allowed the class action to proceed, finding that breach of contract claims involving the alleged use of AI “in lieu of physicians” were legally viable.⁷

What failed at UnitedHealth was not the absence of a policy. The policy existed. What failed was the absence of any structural mechanism that could enforce that policy at the point of decision — a gate that could look at a specific claim, a specific patient, a specific AI output, and ask: does authority exist to execute this action, right now, under the rules that govern this context?

Without that gate, the policy is a document. The log is a forensic artefact. The audit trail is evidence gathered after something has already happened. None of it governs. None of it constrains.

“If none of it is wired into a pre-execution authority gate, then at runtime the real rule is: ‘If the tool allows it and no one intervenes, it goes.’ From a regulator’s perspective, that’s governance in name only.”

— Patrick McFadden, Thinking OS (February 2026)⁸

The model explainability story compounds this. Financial services discovered early that model-agnostic explainability methods — SHAP, LIME — often provide insufficient detail for regulatory requirements.⁹ Meta’s researchers demonstrated in a 2023 study that these techniques explained less than 40% of model behaviour for complex decisions.¹⁰ The Bank for International Settlements’ Financial Stability Institute confirmed that explainability remains the top issue discussed between regulators and firms in relation to AI.¹¹

And here is the problem with asking an AI to explain itself: if you send a whole complicated prompt and a large context of data, you cannot even reliably ask the AI why it made a decision. It might not be able to reliably tell you what data it used. Self-reported explanations are not governance. They are vibes-based auditing.

This is the structural failure at the heart of post-hoc governance. Governance that runs after the decision is already too late. Governance that runs with the decision changes system behaviour. Those are not equivalent things.

Governance Has Gravity

There is a principle worth naming clearly: governance has gravity — it gets pulled to wherever execution happens.

Traditional IT systems execute deterministically. The code does what the code says. Because behaviour is predictable, governance can live upstream — in the SDLC, in change management processes, in pre-deployment reviews. You review the code before it ships. The code ships and does exactly what it was reviewed to do. Governance upstream is sufficient because determinism means nothing unexpected happens at runtime.

Real-time AI breaks this model at the foundation. An AI system does not execute a fixed function. It generates a response based on whatever context, data, and prompting it receives at that moment. The same model, the same policy document, the same system prompt — different context, different outcome. The decision space is not pre-auditable. You cannot review all possible decisions in advance because the decision depends on inputs that arrive at runtime.

Business users will push towards real-time AI. That is where the value is. That is exactly where traditional IT governance and AI governance diverge completely. And the divergence creates what might be called a governance arbitrage: organisations route governance through existing SDLC processes because that is where they know how to do it — and leave the runtime decision space ungoverned.

Gartner projects that by 2026, over 40% of enterprise workflows will involve autonomous agents.¹² Every autonomous tool call by every agent is, under current governance frameworks, an ungoverned execution event. The agent calls a tool. The tool executes. Nobody checked, at the moment of execution, whether the authority existed. Nobody verified whether the data used was admissible. Nobody confirmed whether the risk threshold had been cleared.

Singapore’s Infocomm Media Development Authority published the world’s first agentic AI governance framework in January 2026, explicitly acknowledging that agents’ “access to sensitive data and ability to make changes to their environment raises a whole new profile of risks” where “complex interactions among agents increase substantially the risk of outcomes becoming more unpredictable.”¹³ UC Berkeley’s Centre for Long-Term Cybersecurity, publishing in February 2026, found that unique agentic challenges “complicate traditional, model-centric risk-management approaches and demand system-level governance.”¹⁴

The direction of travel is clear. Governance must follow execution. You cannot govern what you cannot constrain.

The three weaknesses at the heart of this are structural, not accidental:

• Untraceable Authority. At the moment of decision, there is no cryptographic or deterministic record of who authorised the action, under what mandate, with whose delegated power. The authority is assumed, not verified.
• Incalculable Risk. Post-hoc monitoring cannot compute risk before execution. It can only measure what happened after. For irreversible decisions — a claim denial, a credit rejection, a patient discharge recommendation — that is too late.
• Irreversible Decisions. The most consequential AI decisions are also the ones that cannot be undone once executed. Post-hoc governance cannot un-execute a decision. It can only generate evidence about what went wrong.

Logs generated after execution are forensic artefacts. They are necessary. They are not governance mechanisms.

Zero Trust for Decisions

The architectural shift required here is not without precedent. It has already happened once, in network security, and the pattern is directly transferable.

In 2010, John Kindervag, then a principal analyst at Forrester Research, coined the term “zero trust.”¹⁵ His core assertion was simple and devastating: “Trust is a vulnerability.” Perimeter-based security assumed that anything inside the network could be trusted. The perimeter was the governance boundary. Get through the firewall and you were in.

The problem Kindervag named was identical in structure to the AI governance problem: the governance mechanism (the perimeter) was external to the resource it was supposed to protect. Once you were past it, nothing verified your authority at the point of access. Breaches did not require attacking the perimeter — they required compromising any node that had perimeter access. One credential, one misconfigured endpoint, and the “governance” of the perimeter became irrelevant.

Google’s BeyondCorp initiative, demonstrated from 2014, implemented the architectural alternative: replace perimeter-based trust with identity and device verification at every access point.¹⁵ NIST SP 800-207, published in 2020, codified zero trust as a federal standard: no entity is inherently trusted, every access request is verified at point of access, every scope is enforced regardless of network location.¹⁶

The principle translated directly to AI governance is this: models don’t get to “do” — they only get to “suggest.” And every suggestion hits an enforcement boundary before execution.

The perimeter-to-zero-trust shift replaced “trust the network” with “verify at point of access.” The governance-to-enforcement shift replaces “trust the policy document” with “enforce at point of decision.” The structure of the problem and the structure of the solution are the same.

Current AI governance is perimeter-based. The policy lives outside the system. The principles document lives outside the system. The monitoring dashboard lives outside the system. And if you can get a decision past the perimeter — which is trivially easy because the perimeter is not technically integrated with execution — you are in. The system will execute. Nothing stops it.

Zero trust for decisions says: the LLM is a proposer, a drafter, a classifier. The enforcement gate is the arbiter. No proposal executes without passing through the gate. The gate is deterministic. The gate checks authority. The gate checks admissibility. The gate checks risk. The gate produces evidence. And the gate — not the model — decides whether execution proceeds.

“Policy says: ‘You shouldn’t do X’ (detection after the fact). Architecture says: ‘You can’t do X’ (prevention by design). Governance embedded in infrastructure doesn’t need checklists. The system is the compliance.”

— SiloOS framework, LeverageAI¹⁷

Can’t beats shouldn’t. Every time.

Financial services has understood a version of this for over a decade. SR 11-7, issued by the Federal Reserve in April 2011, established that any “quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories to process input data into quantitative estimates” requires independent validation, ongoing monitoring, and governance with board-level oversight.¹⁸ This is a probabilistic engine governance framework. AI systems are probabilistic engines. The regulatory concept is not new — but only 44% of banks currently properly validate AI tools under this mandatory framework.¹⁹

If governed financial services, with a decade of SR 11-7 precedent, still has a 56% validation gap, the picture for unregulated AI governance should concern every CTO and CISO in a regulated industry.

The Four Pillars of Decision Authority Infrastructure

What does runtime governance actually look like? Not as a policy aspiration, but as an architecture that runs with the decision?

The pattern is an In-Path Authority (IPA) gate — a deterministic, model-agnostic enforcement layer that sits between the AI’s output and system execution. The LLM is the proposer. The IPA is the enforcer. The LLM’s role is to propose, draft, classify, and reason. The IPA’s role is to enforce authority, check admissibility, assess risk, gate execution, and produce evidence. Those are distinct functions that must not be conflated.

If you give the model a giant blob of context and then ask for reasons, you are hoping it self-reports accurately. Sometimes it will. Sometimes it will confabulate. That is not governance. The model must produce a structured decision object that can only reference evidence identifiers — not freeform reasoning that may or may not accurately reflect what influenced the output.

Decision Authority Infrastructure rests on four pillars, each of which must be enforced at decision time, not documented after it.

The most powerful external validation of this architecture comes from an independent practitioner source. Patrick McFadden at Thinking OS (February 2026) independently derived the same three-layer structure from first principles: Propose (intelligence layer), Commit (authority gate), Remember (audit trail).⁸ His observation: “Most organisations are pouring effort into #1 and #3. The next wave of scrutiny — from boards, regulators, and insurers — is going to land squarely on #2: ‘Who actually had the authority to let this action execute, and where is the record that proves it?'”⁸

The Commit layer is the IPA. Almost nobody clearly owns it. That is the gap.

The four pillars resolve the three structural weaknesses named earlier: Admissible Knowledge addresses untraceable evidence, Fixed Authority addresses untraceable mandate, Gated Execution prevents irreversible execution without authority, and Provable Evidence converts forensic archaeology into by-design governance output.

From Explanation to Constraint: What Actually Changes

The distinction between explaining decisions and constraining decisions is not a subtle one. It determines whether governance is real or performed.

Explaining decisions means: after the system produces an output, we generate a description of what influenced it. We attribute factors. We weight features. We ask the model to account for itself. We review the log. This is useful for post-hoc investigation. It tells you what happened. It cannot change what happened. And as the evidence shows, it often cannot even accurately describe what happened — the 40% explanation coverage limit from Meta’s research is a hard ceiling on what self-reported model explanations can provide.¹⁰

Constraining decisions means: the system cannot produce certain outputs at all. Before execution proceeds, authority is verified, evidence admissibility is enforced, risk thresholds are cleared, and a signed execution receipt is produced. The decision space is bounded by the enforcement infrastructure, not by the model’s self-assessment of what it should or should not do.

Regulators are moving — slowly but unambiguously — towards constraint language. The EU AI Act’s Article 14 requires that oversight measures be “identified and built, when technically feasible, into the high-risk AI system by the provider” — not merely available as post-hoc investigation tools.²⁰ It requires that natural persons be enabled to “decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output” — structural capability, not advisory permission.²⁰ For high-risk biometric identification systems, Article 14 goes further: no action proceeds without dual human verification at decision time.²⁰

Article 12 mandates logging — forensic readiness.²¹ Article 17 mandates a documented quality management system — process governance.²² Article 14 mandates structural human oversight built into the system itself. These are three different things. The Act requires all three. Most organisations are building only the first two.

The EU AI Act becomes fully enforceable in August 2026, with penalties reaching €15 million or 3% of worldwide annual turnover.²³ The first major enforcement actions are expected to target high-risk systems in hiring or credit — with immediate compliance acceleration globally anticipated upon the first significant fine.²⁴

The governance direction from multiple converging sources — Singapore IMDA, UC Berkeley, the EU AI Act, SR 11-7’s extension to AI — is consistent: define action boundaries requiring human approval before execution, not human review after execution.¹³ Effective AI governance in 2026 will look much more like an operating model than a policy deck — “clearly defined boundaries for autonomous action, explicit escalation paths for human oversight, and transparent validation of AI models and decisions.”²⁵

The most revealing test for any AI governance claim is this: can the system prevent the decision, or can it only describe it afterwards? If it can only describe, you have post-hoc explanation. If it can prevent, you have governance. The difference between those two things is not a matter of degree. It is a structural distinction that determines whether your organisation can answer “who authorised this?” with evidence, or with an investigation.

Governance that runs after the decision is already too late. Governance that runs with the decision changes system behaviour. Only one of those is governance.

The Architecture That Closes the Gap

Decision Authority Infrastructure is not another policy layer. It is an execution constraint. The architecture is model-agnostic, which means it does not depend on which LLM you are running. It is non-autonomous, which means the IPA gate does not itself make decisions — it enforces the decision authority of those who have it. It is authority-aware, which means it checks delegated mandates, not just permissions. And it is irreversibility-sensitive, which means it applies the most stringent gating to the decisions that cannot be undone.

The operational effect is the resolution of the three contradictions that governance theatre produces:

Governance rigour versus deployment speed. Runtime governance infrastructure enables faster autonomous operation, not slower. A highway with structural guardrails is faster than a highway with a human flagging every car. When authority is verified by structure, decisions within the authorised envelope proceed without committee review. Only decisions that fall outside the envelope pause for human assessment. Structural governance is a throughput enabler, not a throughput blocker.

AI autonomy versus human accountability. Decision Authority Infrastructure resolves this by making accountability a property of the architecture, not a property of the human org chart. The system produces provable evidence of authority at decision time. Accountability is not a retroactive investigation — it is a structural output. The question “who is accountable?” has a deterministic answer because the architecture produces that answer as a mandatory artefact of every decision.

Real-time execution versus governance depth. Runtime governance runs with the decision, not after it. Policy-as-code implementations can enforce governance checks in parallel with inference requests with sub-millisecond latency impact.²⁶ The performance argument against runtime governance is a solved problem. The remaining argument is architectural: organisations have not built the IPA layer, not because it is impossible, but because they have not prioritised it over the easier path of documentation and monitoring.

The biggest risk in AI is not the model. It is the authority we give it without verifying that the authority existed.

What To Do With This

The framework is not theoretical. Zero trust networking was theoretical before Kindervag named it and Google proved it. SR 11-7 made probabilistic engine governance operational in financial services over a decade ago. The IPA pattern — LLM as proposer, deterministic gate as enforcer — is implementable with current technology. AWS AgentCore demonstrates deterministic policy enforcement at the gateway for AI agents.²⁷ Policy-as-code frameworks applied to AI deployment pipelines extend this further.²⁶

What is missing, in most organisations deploying AI-assisted decisions in regulated industries, is the commitment to build the enforcement layer rather than the documentation layer. The commitment to treat governance as infrastructure rather than compliance artefact. The commitment to ask — before the first regulatory inquiry, before the first audit failure — whether the governance documented can actually prevent what it claims to govern.

If you are working with AI systems where decisions cross legal, operational, or ethical boundaries, the diagnostic question is simple: what technically prevents an unauthorised decision from executing right now?

If you need to think about it, you have your answer.

The next article in this series examines how Decision Authority Infrastructure connects to the decision decomposition problem — how to break AI-assisted decisions into separately governable units, each with its own evidence bundle and execution gate, so that governance is tractable rather than theoretical.

Scott Farrell is the founder of LeverageAI, where he works with regulated-industry organisations on AI architecture and governance infrastructure. Prior articles: Architecture, Not Vibes · Agent Provenance Stack · The Simplicity Inversion