← All insights

Behavior Isn’t Governance: The Missing Layer of Enterprise AI

Three layers of enterprise AI — structural architecture, behavioral architecture, and governance — and the five behavioral pillars: Evaluation, Steerability, Provenance, Containment, Reversibility

Five behavioral pillars only work if something enforces them. Here’s where they actually have to live.

A few weeks ago I laid out five behavioral pillars — Evaluation, Steerability, Provenance, Containment, Reversibility — as the layer AI-native systems need on top of their structural architecture. Since then I’ve asked a few technology leaders the same question I ended that piece with: which of these are operational in your organization, and which only exist in a diagram?

The answers are consistent. Most organizations have real teeth on one or two, usually Containment, because security forced it, or Reversibility, because an incident made rollback non-negotiable. The rest are agreed on in principle and enforced inconsistently. Not from disagreement. From the fact that nobody ever wrote down where in the system a pillar is supposed to live.

That’s the gap I want to close here. Not by adding a sixth pillar — by describing the architecture that turns the five you already have into something that runs, every day, on every request, whether or not anyone’s watching.

A short recap, then we move on

Two of the five pillars deserve a quick refresher because the rest of this piece leans on them.

Provenance distinguishes why an answer exists from how confident the model was about it. Confidence is the model’s own assessment of itself. Provenance is whether the value was extracted from a source you trust or inferred — and that distinction survives long after the confidence score is forgotten.

Containment means keeping authority smaller than capability, and in practice, that means not every AI decision deserves the same scrutiny. A wrong internal tag and a wrong bank routing number are not the same category of mistake, so they can’t go through the same review.

If you want the fuller argument for either one, that’s what the original pillars piece is for. What I haven’t written about yet is the part that makes them real: where they physically sit in a running system, and who’s accountable for them staying true.

Enterprise AI is splitting into three planes

Cloud computing went through this exact shift years ago. Nobody put load balancing, authentication, and encryption inside every individual application; those became shared infrastructure, built once, that every application called into. AI governance is heading the same direction, and it’s useful to name the three planes explicitly, because most organizations currently have exactly one of them.

The execution plane is where the AI actually works: the models, agents, tools, and workflows generating proposals. This is what nearly every AI investment so far has gone into. It’s also, on its own, the layer with the least trust to offer, because nothing here enforces anything; it just proposes.

The control plane decides what’s allowed to happen. This is where risk tiering lives, where the deterministic checkpoint sits, where identity and authority get checked before a write. Its defining property is that it’s dumber than the execution plane on purpose. The same input always produces the same decision, which is exactly what makes it auditable.

The evidence plane is the memory of the other two: audit records, decision lineage, evaluation history, the trail that lets you answer “why did this happen” without a war room.

Most organizations I talk to have built a strong execution plane and nothing else. That’s the whole story of why five well-reasoned behavioral pillars end up living only in a diagram. There’s no control plane for them to run inside, and no evidence plane recording that they ran.

What actually goes through the control plane

One design choice matters more than any other here. Checkpoint the authority transition, not every action along the way. If an agent runs six searches before drafting an answer, none of those searches need a checkpoint. Only the moment it tries to write something to a system of record does.

And not everything needs to happen inline. A high-risk write — anything touching money, contracts, or safety — should block until it clears. A lower-risk one can be approved and logged asynchronously without weakening anything, because the evidence plane still captures it either way. Treating every action as equally urgent is how governance becomes the bottleneck people route around.

One more thing worth building in early. When the control plane rejects a proposal, the reason should be legible to the person or team that generated it, not just a machine-readable status code. A rejected proposal nobody can explain gets worked around. A rejected proposal with a clear reason gets fixed.

Someone has to own each plane

None of this holds without names attached to it, and the split has to cross departments, not stay inside engineering.

Executive leadership owns risk appetite. How much scrutiny is enough is a business call, not a technical one, and every autonomous capability needs an owner who has explicitly accepted its risk before it ships. Business owners classify their own data and actions by what a wrong answer actually costs. Platform engineering builds the control plane once, as shared infrastructure, instead of every application inventing its own version badly. And security, legal, and compliance own the policies the evidence plane has to prove were followed.

Notice what’s not on that list. Nobody owns “AI governance” as a single job. That’s deliberate. The moment governance becomes one team’s problem, it becomes the team with the least authority to set risk appetite for the whole business.

Three questions that cut through all of it

You don’t need to recite the planes model, the pillars, or any of the above to know where you actually stand. Three questions get there faster.

What’s the last thing that happens before an AI writes to a system of record? If the honest answer is “we trust the model,” there’s no control plane yet, whatever your eval scores say.

Which decisions can this AI make entirely on its own, and where is that written down? If the boundary only exists in the code, autonomy was set by whoever wrote the code, not by anyone who owns the risk.

Could you explain one specific AI decision today, without assembling a small team to reconstruct it? If the evidence plane is real, that takes minutes. If it’s aspirational, it takes days — and you find out exactly how many the first time a regulator asks.

If you’re trying to work out which of your behavioral pillars have a control plane under them and which are still running on trust, that gap is usually visible within a day of tracing how one AI-generated value actually reaches a system of record. Happy to walk through it — get in touch.

Related

Keep reading

Let's talk

Wondering where your control plane actually is?

If any of this maps to a gap you're staring at, let's compare notes — get in touch.