SNC Development

An Enforcement-Plane Framework for Enterprise AI Governance

James Naphen | EcoStratus Technologies | StrataLayer.ai | November 2026

Part of the working paper series: AI Governance and Systems Accountability

Human review is often offered as proof that an enterprise AI system is governed. A person inspects an output, approves it, and records the decision. That supports accountability. It does not tell you whether the system’s data access, tool calls, identity permissions, or workflow actions were constrained before the output appeared.

The title is deliberately blunt. The claim is narrower: evidence that a person reviewed an output is not, by itself, evidence that the system producing it was governed across its execution chain. I am not arguing that human review is useless. I am asking what it can prove. The framework below is exploratory and has not been independently validated.

Review is the last step in a chain.

Review is visible, auditable, and reassuring, and it has real value. The risk is using it to support a broader claim than it establishes.

By review, I mean output review: a person inspects a result after the system has acted. That differs from an approval gate, where a person must authorize a specific action before it executes.

An AI system’s output ends an execution chain (Figure 1): data retrieval, model inference, tool selection, API calls, workflow execution, all under some human or service identity. A reviewer who sees only the final output may have no visibility into those earlier steps and no authority to stop them. A valid review of an accurate output can coexist with an earlier execution breach.

“Human review” also names several different things, and the same visible record can correspond to quite different governance functions (Figure 2).

In my own platform work, I have seen a related pattern: a process is documented and an approval recorded, while configuration data, integration ownership, or underlying controls remain incomplete or inconsistent. The approval shows someone reviewed the process. It does not show the controls operated as intended. This is a practitioner observation, not a finding.

Agentic AI raises the stakes, because these systems can retrieve records, invoke tools, modify data, and trigger downstream actions. The governance question becomes: what was the system permitted to do, what constrained it before execution, and what evidence shows those constraints operated?

A hypothetical: the accurate output that hides an unsafe action

An agent summarizes vendor invoices and drafts payment schedules for a finance manager. Its role is read-only. It must not change payment instructions or write to the ERP system.

The documentation says so. But the agent’s service identity has broader permissions than the task requires, and no runtime controls restrict it to approved operations. An unexpected input leads the agent to invoke an ERP write, and a vendor payment-routing record changes before the summary is generated.

The finance manager checks the calculations and approves the report. The approval is recorded.

That record shows the manager reviewed the report. It does not show which records the agent accessed, which tools it invoked, or whether the reviewer could have seen or stopped the write. The failure isn’t a bad answer. It’s a gap between intended authority and actual execution, hidden behind a review record that documents a different part of the process.

A technically enforced approval gate on ERP writes, showing the destination and amount, would likely have changed the outcome. That is a preventive control at the execution layer, not output review, which is the point.

Four enforcement planes

The framework separates AI governance into four planes (Figure 3). They are analytical categories, not a prescribed architecture.

Controls also differ by function. Preventive controls stop an action before it happens, detective controls identify it during or after, and corrective controls contain or reverse the damage. They are not interchangeable. A log shows an action occurred without preventing it, and a post-event review can find a violation without stopping it.

My working hypothesis: governance documentation can describe all four planes, while enforcement varies across them. Output review can be genuine and useful while the controls on execution and identity remain unproven. I have not tested this beyond practitioner experience.

What the evidence actually establishes

The framework includes a simple evidence-status vocabulary. It is a discovery aid, not a maturity score, certification method, or risk model. Record a status for each plane separately. A strong record on one plane must not offset a weak one on another.

“Not demonstrated” and “unknown” are different. The first is an evidence-based gap the assessment found. The second means the assessor cannot yet say. Collapsing them into a single zero hides that difference.

A status says what the evidence shows, not how good the evidence is, so I record three things alongside it. Coverage asks whether the evidence includes the relevant systems, events, and actions. Integrity asks whether it can be relied on as complete and unaltered. Independence asks whether verification is separate from the control owner. The strongest evidence is a deliberate test designed to exercise the failure mode, with results recorded. A passing test supports only the behavior and conditions tested, and a failing test shows the control did not hold under those conditions.

One legal reference point

In SCHUFA Holding (Scoring) (Case C-634/21, 2023), the Court of Justice of the European Union held that automated generation of a creditworthiness score can itself be automated decision-making under GDPR Article 22(1) where a third party draws strongly on it to establish, implement, or terminate a contract. The ruling concerns data protection for individuals. It is not a test for whether human review is effective, and it says nothing about enterprise AI governance as such. One way to read it: a formal human step downstream does not, by itself, show that the automated output wasn’t decisive. That reading is mine, not the Court’s. A later installment will cover the wider legal and supervisory context.

The question to ask

For security leaders: are an agent’s effective permissions constrained at the infrastructure or execution layer, or only described in policy? For platform architects: where do restrictions operate, when are they evaluated, and can they block the action? For program owners: can the named owner actually require remediation, revoke access, or suspend a deployment?

All three come down to one question:

Where does the control operate, and what evidence demonstrates that it operated as intended?

Human review can be a legitimate part of a governed system. It is not a substitute for governing the system’s execution. Treat it as one control within a larger architecture, and demonstrate governance where the system receives authority and takes action, rather than inferring it from the acceptability of the output.

Reference

• Court of Justice of the European Union. SCHUFA Holding (Scoring), Case C-634/21, judgment of December 7, 2023. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=ecli%3AECLI%3AEU%3AC%3A2023%3A957 (check that this link resolves before publishing)

Author disclosure: James Naphen is the founder of EcoStratus Technologies and creator of StrataLayer.ai, a patent-pending governance-first data-processing concept. This post presents an exploratory analytical framework. It is not a product evaluation, legal advice, or a claim that the framework or its assessment instrument has been independently validated.