What a Governed AI System Actually Looks Like

Part 4 of a 4-Part Series on AI in Production

In Part 3, I walked through what breaks.

Not because the systems don’t work.

Because they weren’t designed to operate under constraint.

At some point, that stops being an implementation problem.

It becomes a control plane question.

Where does policy live, and how far does it actually reach?

I’ve been in recent briefings with vendors building toward this. VAST is a good example. Their architecture makes complete sense when everything lives inside the platform—data, agents, policy, governance all in one boundary. You get clean control.

But I pushed on the boundary question directly: what happens when the data isn’t inside VAST? What happens when an agent needs to reach something external?

Their answer was honest and useful. You have two paths. Import the data into VAST, and you get the full native governance experience—policy engine, audit logs, end-to-end attestation. Use MCP to reach external sources, and you still get centralized policy enforcement, but you lose some capability by nature of the data not being on the platform.

That’s not a criticism. That’s the engineering tradeoff stated clearly.

And it illustrates the exact problem this series has been building toward.

Because the system you’re trying to govern doesn’t live in one place. It spans data, models, and execution environments.

And just like with cloud, the question becomes: did control move with the system?

If the answer is no, you don’t have a governed system. You have a system that behaves differently depending on where it runs.

At that point, architecture starts to matter in a different way.

Not what tools you use. Not what model you pick. But what is actually owned.

If you want a system you can trust, a few things have to be true.

You have to be able to isolate decisions—to know what the system is trying to do before it does it. You have to evaluate those decisions in the moment, against rules you define, not after the fact. You have to control not just what context the model gets, but how that context is structured, and you have to be able to trace not just the output, but the path that produced it.

And you have to know who owns each part. Because if no one owns control, the model will.

This doesn’t require a specific vendor. It doesn’t require a specific architecture. It doesn’t even require the control plane to live outside the platform.

IAM doesn’t live outside AWS. It lives inside it.

But it’s explicit. It’s owned. And it’s enforced everywhere.

That’s the standard.

AI hasn’t reached that level yet.

So every team is solving it differently. Every platform is solving it within its own boundary. And every enterprise is left stitching those boundaries together.

That’s the real problem.

If you can’t define policy, evaluate decisions, and enforce constraints across your system, you don’t have a governed AI platform. You have a collection of capabilities.

And that’s fine for a demo.

But not for production.

Across these four parts, the pattern is pretty clear.

AI doesn’t fail because it lacks capability. It fails because we haven’t built systems to control it.

We’ve seen this before.

Cloud didn’t scale because compute got better. It scaled because control became programmable.

AI is at that same point.

The question isn’t whether the models will improve. They will.

The question is whether we build the control systems around them that make them usable.

Because until we do:

AI doesn’t fail in the demo.

It fails the first time you have to trust it.