The Missing Layer in AI Governance: A Structural Analysis of 14 Frameworks

Regulations define obligations. Runtime guardrails constrain outputs. Neither defines the architecture of business judgment. Source: Image by the author

This article examines why — and what it means for enterprises deploying AI at scale.

The Governance Landscape in Three Layers

AI governance has evolved rapidly, but along three separate tracks that rarely connect.

Regulatory frameworks (EU AI Act [1], GDPR, J-SOX) define what organizations must comply with. They set boundary conditions. They don’t prescribe how to organize operations to meet them.

Management systems (ISO 42001, NIST AI RMF) define what processes should exist — risk assessments, role assignments, monitoring cycles. ISO 42001 Clause 5.3 [5] requires that responsibilities be assigned for AI systems. But it operates at the management system level: “ensure responsibilities are assigned” — without specifying a structural schema for how responsibility attaches to individual decision points within a process. Management systems govern the envelope. They don’t structure what’s inside it.

Runtime governance (NeMo Guardrails, Guardrails AI, LangChain Security, Bedrock Guardrails, Azure AI Content Safety, LlamaGuard) enforces constraints at execution time — token-level, prompt-level, output-level. These tools are essential. But they operate without structural context: they don’t know which business decision they’re protecting, who is responsible, or what evidence should be preserved.

Each of these layers is well-designed for its purpose. The problem isn’t with any individual layer — it’s with what sits between them.

The Structural Gap

Consider what happens when AI makes a business judgment — inventory valuation, quality inspection, credit scoring — not generating text, but making decisions that affect financial statements, product safety, or regulatory filings.

The judgment drifts over time. Not catastrophically — the AI still produces outputs within guardrail thresholds. But the pattern of decisions gradually shifts outside the boundary it was designed to operate within. A quality inspection AI’s pass rate creeps up by two percentage points over six months. A credit scoring model’s approval distribution shifts silently with input data.

An incident occurs. An auditor asks: “Who was responsible for this decision? What was the escalation path? Where is the evidence that the boundary was defined before the system went live?”

Regulatory frameworks didn’t define the decision architecture. Management systems required that roles be assigned, but didn’t specify the structural schema. Runtime guardrails blocked harmful outputs, but didn’t preserve decision-level evidence.

The gap is structural. No established layer defines how business decisions involving AI are organized: which judgments occur, who is accountable for each, under what conditions autonomous execution should halt, or how evidence is preserved.

This isn’t a hypothetical concern. In Grant Thornton’s 2026 AI Impact Survey (n=950) [3], 78% of executives reported lacking strong confidence they could pass an independent AI governance audit within 90 days — not due to insufficient investment, but because they cannot demonstrate how their AI makes decisions and who owns the outcomes.

Gartner’s AI TRiSM (Trust, Risk, Security Management) [4] recognizes this gap conceptually, calling for AI governance as a capability. But AI TRiSM describes what capabilities are needed — it doesn’t define the structural architecture that implements them.

Seven Axes for Evaluating the Gap

To make the gap precise, we need a vocabulary. The following seven structural axes represent the minimum set of architectural concerns that must be addressed between regulation and runtime:

1. Decision Unit definition. Does the framework define a fixed-granularity schema for identifying where business judgments occur? (Purpose → Decision → Evidence)
2. Responsibility boundary. Does it structurally specify who decides, who supervises, what AI is permitted to do, and what it cannot — at the individual decision-point level, not at the management-system level?
3. Fail-closed execution. Does it define a design principle where the default behavior for undefined conditions is halt, not continue? With structurally bound stop modes (abort, refuse, escalate)?
4. Drift boundary control. Does it define drift not just as a monitoring practice, but as a structural boundary relative to each decision point’s validated operating range?
5. Escalation topology. Does it define escalation as a directed graph (which decision escalates to which authority, under which conditions, with which evidence) — not just a flat “alert the human” pattern?
6. Regulatory-to-process synchronization. Does it structurally map regulatory requirements to specific decision points, so that when a regulation changes, affected processes are identified architecturally rather than through manual review?
7. Process coordination layer. Does it provide a shared coordinate system that unifies governed processes across domains (manufacturing, finance, compliance, ESG) under one judgment-structure map?

These seven axes are not arbitrary. They form a causal dependency: decision points must be defined before responsibilities can be assigned; responsibilities must be fixed before stop conditions make sense; stop conditions must exist before drift can be measured; and all of this generates the evidence trail that enables auditability.

Strip the seven axes to that causal core and four elements remain, in a fixed order. A decision unit must be identified; a responsibility boundary must bound it; a halt condition must say when it stops and who acts on the stop; and only then can evidence record what happened relative to all three. The remaining axes — drift control, escalation topology, regulatory synchronization, coordination — are elaborations of this spine, not independent additions. This four-element sequence is what the rest of the article tests existing and emerging frameworks against.

Evaluating 14 Frameworks

With these axes defined, we can evaluate where existing frameworks stand.

No single framework covers all seven structural axes. Runtime guardrails touch only fail-closed execution; management systems and regulation cover responsibility partially. Source: Image by the author.

(Gartner’s AI TRiSM is a capability model, not a structural framework — excluded from the comparison.)

What the Table Shows

Runtime governance addresses fail-closed behavior partially — blocking at the I/O level is fail-closed at the token level, but not at the business-decision level. No runtime framework addresses decision units, responsibility boundaries, drift control, escalation topology, regulatory synchronization, or process coordination.

A word on why runtime scores low, because it is easy to misread. The seven axes are layer concerns — constraints that have to hold consistently across many decisions. Runtime guardrails are pipeline-stage tools: they process one execution at a time, at the token or output level. Scoring them low on these axes is not a verdict on their quality. They are doing a different job on a different axis. The point is the opposite of a criticism — their low scores show that pipeline-stage enforcement and layer-level structure are orthogonal, and that having excellent guardrails tells you nothing about whether the decision layer exists.

Management systems show broader but shallow coverage. ISO 42001’s Clause 5.3 addresses responsibility at the management system level, not at the decision-point level. NIST AI RMF’s MEASURE function covers performance monitoring [6], which implicitly touches drift — but drift isn’t defined as a structural boundary relative to a specific decision point’s validated operating range. COSO GenAI shows the broadest coverage among existing frameworks, partially addressing decision units through “AI-relevant control points” — but framing these as extensions of existing COSO control activities rather than as structural primitives with defined schemas.

Regulatory frameworks mandate accountability (Responsibility: Partial across the board) and, in the case of EU AI Act, certain fail-closed behaviors for high-risk systems.

The pattern: every Partial rating reflects the same structural issue — the concept is recognized as an obligation or a practice, but not defined as an architectural primitive with a fixed schema. The distance between “ensure responsibilities are assigned” (ISO 42001) and “structurally bind responsibility to each decision point with pre-decision constraints and post-hoc immutability” is the distance between a management system and a governance architecture.

No single existing framework fills all seven columns. This isn’t a criticism — each was designed for a different purpose. But it means the structural integration between regulation and runtime is currently left to each enterprise to improvise.

Why This Gap Exists

In 1999, Lawrence Lessig argued that architecture is a modality of governance [7] — alongside law, norms, and markets. The structure of a system constrains behavior as powerfully as any statute.

If code is law, then the architecture of AI decision-making is governance. But Lessig’s architecture was deterministic — a protocol either permits a packet or it doesn’t. AI systems are probabilistic and adaptive. They drift. They learn. They produce different outputs from identical inputs.

This is precisely why the governance architecture layer has been slow to emerge. The traditional EA frameworks (TOGAF, Zachman, COBIT, ArchiMate) were designed for deterministic systems. They organize business, application, data, and technology layers — but none defines a structural layer for decision architecture: the organization of judgment points, responsibility boundaries, stop conditions, and evidence structures in systems whose behavior is stochastic.

Governance architecture for AI must define boundaries within which probabilistic behavior is acceptable, and structural responses for when those boundaries are crossed. This is a fundamentally different design challenge from traditional enterprise architecture, and it explains why the gap has persisted despite decades of EA practice.

The Layer Is Beginning to Emerge — Without Becoming a Layer

The analysis so far describes the established landscape. But the gap has not gone unnoticed. Through 2025 and 2026, a wave of frameworks — most aimed at agentic AI — began reaching toward exactly this layer. They talk about decision records, provenance, authority boundaries, halt-on-action, and drift as a structural rather than a merely statistical concern. The vocabulary of this article is no longer unusual.

That is worth saying plainly: the decision layer is not so much absent as fragmenting into existence across a dozen partial attempts, none of which yet assembles the pieces into a single causal structure. The interesting question is no longer “does anyone see the gap?” It is “has anyone fixed the ordering that makes the pieces load-bearing?”

The most developed of these attempts is the Agentic Operating Model (AOM), set out in California Management Review [8]. AOM organizes autonomous AI into four interdependent layers — cognitive specialization, coordination architecture, real-time control, and organizational governance — and makes a sharp diagnostic claim: agentic systems fail not because individual models underperform, but because these layers fall out of alignment with one another.

That diagnosis is correct, and it is the same failure this article has been describing. But AOM stops at the diagnosis. It establishes that misalignment across layers is the problem; it does not specify the mechanism that holds the layers in alignment.

AOM explains where organizational misalignment emerges; the four-element sequence explains how a single decision stays governable across AOM’s layers. Diagnosis and mechanism, not rival models. Source: Image by the author.

This is the gap the four-element sequence fills. Decision Unit → Responsibility Boundary → Halt Condition → Evidence is not a fifth layer stacked on top of AOM’s four. It is a cross-cutting thread: a single decision unit — carrying its responsibility boundary, its halt condition, and its evidence — runs through all four AOM layers and forces them to refer to the same thing. AOM tells you that real-time control and organizational governance must not contradict each other. The causal sequence is what makes that non-contradiction structural rather than aspirational, because the same decision unit is the reference point in both. Diagnosis and mechanism, not rival models.

The same holds for the rest of the wave. Runtime governance stacks now ship evidence layers and action-level halt checks; assurance frameworks now bind decisions to tamper-evident provenance. Each implements one or two of the four elements, often well. What none of them asserts is the ordering — that evidence is inert unless it refers back to a halt condition, a responsibility boundary, and a decision unit defined before it. The pieces exist. The sequence that makes them load-bearing does not.

What a Governance Architecture Layer Would Look Like

Based on the analysis above, a governance architecture layer (occupying the structural gap between regulation and runtime) would need to:

• Define decision points at a fixed granularity across all domains, creating a shared coordinate system for judgment
• Structurally bind responsibility to each decision point — not as policy, but as architectural constraint
• Default to halt for undefined conditions, with explicitly defined stop modes per decision point
• Define drift as a structural boundary, not a monitoring practice — making it observable and triggerable
• Define escalation as a directed graph with evidence attachment, not a flat alert mechanism
• Map regulations structurally to decision points, enabling architectural impact analysis when regulations change
• Provide a domain-independent coordination layer that unifies all governed processes

The seven elements above are not a menu to pick from. They form a causal chain — decision points before responsibilities, responsibilities before stop conditions, stop conditions before drift, all of it generating the evidence trail. An architecture that fills the gap between regulation and runtime has to implement all seven as first-class primitives, not as policy bolted on after the fact.

In Practice

Consider a manufacturing line where AI performs visual quality inspection. The decision point is “pass/fail judgment on product appearance.” Responsibility is structurally bound: AI judges, a human quality manager holds final accountability, and the AI cannot override a human rejection. If the AI’s confidence falls below threshold, the item routes to escalation — it is not passed. Drift is tracked as pass-rate deviation from the validated baseline. Escalation routes to the QA lead with drift data attached. Regulatory mapping connects this decision point to EU AI Act Article 9 and J-SOX controls. The process coordination layer holds this alongside the financial close, ESG data collection, and every other governed process.

The same structural schema applies to credit scoring, fraud detection, or ESG data validation. Different domains, identical architecture.

Three Questions

For anyone deploying AI across an enterprise:

• Can you show an auditor exactly which business decisions your AI systems make — not which APIs they call?
• For each decision, can you demonstrate who is responsible, what the stop conditions are, and where the evidence lives?
• When a regulation changes, can you identify every affected decision process without a manual review?

If the answer is “not yet,” the gap between regulation and runtime is where the problem lives. Filling it requires not more tools or more policy — but an architecture.

References

[1] European Parliament and Council of the European Union, “Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act),” Official Journal of the European Union, 2024. Available on the EUR-Lex portal.

[2] European Commission, “Corporate Sustainability Reporting Directive (CSRD) and European Sustainability Reporting Standards (ESRS),” 2023. Available on the European Commission corporate sustainability reporting page.

[3] Grant Thornton Advisors LLC, “2026 AI Impact Survey,” April 2026. Based on self-reported responses from 950 senior business leaders across 10 industries in the US. Available on the Grant Thornton insights page.

[4] Gartner, “Market Guide for AI Trust, Risk and Security Management (AI TRiSM).” Available on the Gartner research portal.

[5] International Organization for Standardization, “ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system,” 2023. Available on the ISO website.

[6] National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework (AI RMF 1.0),” NIST, 2023. Available on the NIST website.

[7] Lawrence Lessig, Code and Other Laws of Cyberspace, Basic Books, New York, 1999.

[8] California Management Review, “Governing the Agentic Enterprise: A New Operating Model for Autonomous AI at Scale,” 2026. Available on the California Management Review website.