Beyond Policy: The AI Governance Stack Your Enterprise Is Missing

At a Glance

• What this covers:  The four layers every enterprise AI governance stack needs - and why most organisations have only one. How runtime enforcement fits in the stack and what each layer produces for the organisation.
• Key finding:  In our engagements, most enterprises have an AI policy. Very few have all four layers: policy, visibility, enforcement, and evidence. A stack with only the first layer is not a governance stack - it is a document. 
• Business impact:  An organisation with only a policy has told employees what to do but has no way to see what they are actually doing, no control at the moment they do it, and nothing concrete to show a regulator.
• What you’ll learn:  What each layer does, what it produces, and how a runtime governance layer like Inhibitor by Systango operates at the layers most organisations are missing. You will also learn how to tell which layers you are missing and where to start. 
• Our perspective: Informed by Systango’s experience putting runtime AI governance into production across enterprise environments.

Most organisations have one layer of AI governance. A working stack has four.

Picture a leadership team that signed off an AI policy some months ago. A board member asks what employees sent to AI tools last week, and nobody in the room can answer. The policy exists and it told people what to do. It cannot tell anyone what they actually did.

That question is now arriving from more directions. Boards, customers, and regulators are moving from asking whether an AI policy exists to asking for proof that it is applied.

A working AI governance stack has four layers: policy, visibility, enforcement, and evidence. Most enterprises have one - the policy - and assume it covers the rest. It does not.

Inhibitor by Systango is the runtime governance layer that operates at the enforcement and evidence layers - the two most organisations are missing. We will come back to what it does at each layer. First, the stack itself.

In our previous pieces, we covered why a written AI governance policy cannot stop data leakage and why traditional DLP tools miss the AI surface entirely. 

This blog answers: what does a complete stack actually look like?

Layer	Name	What It Does	What It Produces
Layer 1	Policy	Defines what employees can and cannot do with AI tools. Necessary but not enforceable on its own.	An acceptable use document. No technical control.
Layer 2	Visibility	Surfaces what AI is actually being used across the organisation - tools, users, volume, content patterns.	A real-time map of AI use. Shadow AI surfaced.
Layer 3	Enforcement	Intercepts AI interactions at the moment they happen - classifying, redacting, blocking, and applying policy technically.	Every prompt governed before it reaches a model.
Layer 4	Evidence	Produces a tamper-evident audit trail of every AI interaction, governance decision, and outcome - available on demand.	A log regulators and auditors can actually examine.

Each layer also needs a named owner. A typical split is shown below, and it will vary by organisation.

Layer	Typically owned by	The question a board or regulator can ask
Policy	General Counsel, CISO, or Chief Risk Officer	What are employees allowed to do with AI?
Visibility	CIO or IT, with security operations	Which AI tools are in use, and by whom?
Enforcement	CISO and security engineering	What stops a sensitive prompt from leaving the organisation?
Evidence	Compliance, risk, and the data protection officer	Can you show what happened, on demand?

Layer 1: Policy - necessary, but not sufficient

An AI governance policy defines acceptable use: which tools are approved, what data can be shared, what counts as a violation. It is the foundation - without it, the other layers have nothing to enforce.

But a policy has no technical mechanism to act. 

• It cannot detect a prompt, stop a transfer, or produce a log. 
• It tells employees what they should do and relies entirely on them remembering it at the moment they open an AI tool. 

Layer 1 is where most organisations stop. It is also where most governance failures begin. The exposure this leaves sits with leadership, because a policy shows intent but not control.

Action for leaders: check that your policy names approved tools, prohibited data types, and an accountable owner, and treat it as the starting point for the next three layers.

Layer 2: Visibility - knowing what is actually happening

Visibility surfaces what AI is actually being used across the organisation - which tools, which teams, at what volume, with what content patterns. Without it, a security team is enforcing a policy against activity it cannot see.

Shadow AI - tools adopted informally without IT approval - is entirely invisible to a stack that only has policy. Visibility closes this blind spot. 

And without Layer 2, Layer 3 has nothing to act on:

• You cannot enforce governance over activity you cannot observe. 
• Every unapproved tool is a place where company data can go with no contract, no retention terms, and no accountable owner. 

We typically see that the first real map of AI use looks different from what the team that wrote the policy assumed.

Because Inhibitor sits between users, systems, and the LLMs they call, every interaction it governs also feeds this map of AI use.

Action for leaders: ask your security team for a list of the AI tools in use this month, by team. If they cannot produce one, Layer 2 is your first gap.

Layer 3: Enforcement - control at the moment of interaction

Enforcement is the layer that acts - at the moment a prompt is sent, before it reaches a model, with no log review the next morning needed to catch it. 

When an employee sends a prompt containing confidential data, enforcement intercepts it, classifies the content, applies the organisation’s rules, and logs every decision.

Inhibitor, the runtime governance layer Systango built, operates at this layer - sitting between an organisation’s users, systems, and the LLMs they call. The NIST AI Risk Management Framework identifies “govern, map, measure, manage” as the four functions of AI risk management. 

Enforcement is the ‘manage’ function - and it requires technical controls, not documents.

Layer 4: Evidence - what you can show when asked

Evidence is the layer that makes governance demonstrable. 

A regulator or auditor asking “can you show us how you govern AI use?” needs a record of what actually happened - not a policy document.

Evidence means a tamper-evident log of every AI interaction, every governance decision, and every outcome. It means answering, within hours: “What did your systems send to an AI model last Tuesday?” Without Layer 4, governance cannot be demonstrated - and in a regulated environment, governance that cannot be demonstrated is governance that does not exist.

What the stack produces when something goes wrong

A financial services firm receives a regulatory inquiry. With only a policy, it can show a document - it cannot show what was sent to an AI model, whether sensitive data was involved, or whether any control was active. 

With all four layers, it produces a complete log: what was sent, what the governance layer decided, what was redacted - and the EU AI Act Article 9 documentation is available on demand.

Real-world reference: 

A UK WealthTech platform needed all four layers active before a single model went live. 

The compliance team’s question - “can we demonstrate governance in practice?” - had an answer before any regulator asked it. 

Full case study available on the Systango website.

Where does your organisation stand, and where should it start?

The four layers work as a maturity ladder. Find the row that describes you today.

Layers you have	What happens when a regulator or an incident arrives	Sensible next step
Policy only	You can show a document. You cannot show what was sent to any AI model.	Build visibility, so you know what is in use.
Policy and visibility	You know which tools are in use. You cannot stop a sensitive prompt or prove what happened.	Add enforcement at the point of use.
Policy, visibility, and enforcement	Risky prompts are handled in the moment, but decisions may not be held in a form an auditor will accept.	Make the record tamper-evident and retrievable on request.
All four layers	You can show what was sent, what was decided, and what was redacted, on demand.	Extend coverage to internal applications, APIs, and agents.

• Build the layers in that order, with one exception: design the evidence layer from the start, because it defines what enforcement has to record.
• When Layers 3 and 4 are the priority: staff or systems send customer, financial, health, or other regulated data to AI tools, or you operate under audit obligations.
• When they can wait: AI use is limited to public information and no regulated data is involved. In that case a clear policy plus visibility may be enough for now.
• A simple decision test: if you cannot produce, within a day, a record of what was sent to AI models last month and what was decided about it, treat Layers 2 to 4 as open gaps before you expand AI use further.

Treat the four layers as a working AI governance framework you can score yourself against. 

A control layer built for the enforcement and evidence layers

Inhibitor, the runtime governance layer Systango built, operates at Layers 3 and 4 simultaneously - enforcing policy at the moment of interaction and producing the evidence record that makes governance demonstrable. 

It operates at the prompt layer across browsers, internal applications, and APIs - the full AI surface.

Deployed across 18+ enterprise environments, logging 50,000+ LLM interactions weekly, with 92% of PII and confidential data prevented from reaching models.

Source: Systango internal deployment data. 

View Inhibitor - or get in touch to understand how this works for your organisation.

What leaders should ask about their current governance stack

• Does our organisation have all four layers - policy, visibility, enforcement, and evidence - or just the first one?
• Can we produce a log of every AI interaction from last month, including what was sent and what governance decision was made?
• Is our AI policy technically enforced at the point of use, or does it rely on employees remembering it?
• If a regulator asked us to demonstrate AI governance in practice tomorrow, would we have something to show beyond a document?
• Do we have visibility into AI use across internal applications and APIs, not just browser tools?
• Do we know who in the organisation is accountable for each layer?
• Are the logs we keep protected from being edited after the fact?

If your governance stack is missing any of the four layers, that gap is worth identifying before a regulator or incident identifies it for you. Systango’s AI Governance Layer, built around Inhibitor, covers the enforcement and evidence layers.