For about twenty years, my job was to answer one question at any hour of the day: what changed, when, by whom, and can you prove it? I administered enterprise databases — the systems where a single unaccounted-for write, an unlogged change, or a missing audit record isn't an inconvenience. It's a regulatory finding, a failed audit, sometimes a lawsuit.
That discipline is why, when I started looking at how organizations “govern” AI, something felt off.
Guardrails answer the wrong question
Most AI governance today is a variation on one idea: put a probabilistic filter — a “guardrail” — around the model. Screen the prompt, screen the output, maybe run a second model as a judge. If something looks risky, block or rewrite it.
That's useful. It is not governance.
Here's the test I apply, straight from two decades of audits: can you replay the decision? When an examiner points at a single AI action from three months ago and asks “why was this allowed, exactly what rule applied, and can you prove it wasn't tampered with” — a guardrail has no answer. It made a probabilistic judgment in the moment. Ask it the same question twice and you might get two answers. There is no deterministic record of what was enforced and why.
In database terms, a guardrail is a well-meaning senior engineer eyeballing production changes. Helpful. Fast. Completely unprovable after the fact. No regulated institution runs its ledger that way — and none should run its AI that way either.
Enforcement is different from monitoring
The distinction that matters is enforcement versus monitoring.
Monitoring watches what happened and raises a flag. Enforcement decides, before the action occurs, whether it is permitted — against an explicit, versioned policy — and then produces evidence of that decision that anyone can verify later, independently, without trusting the system that made it.
Those two properties — deterministic (same input, same verdict, every time) and provable (signed, replayable evidence) — are exactly what a database administrator spends a career defending. They aren't new ideas. They're being applied one layer up, to the AI decision.
Why it's an infrastructure problem
Vendors like to frame AI governance as a model problem: fine-tune the model to be safer, prompt it more carefully, add another classifier. That framing sells more model tooling. It also fails the audit for the same reason an unlogged production change does — it can't be replayed, can't be independently verified, and can't survive an examiner who asks for evidence at the moment of the decision.
Governance a regulated institution can actually stand behind lives below the model, in infrastructure:
- A deterministic policy layer that resolves, before the model acts, whether the action is allowed — from an explicit, versioned rule set, not a vibe.
- Cryptographically signed decision evidence — a record of the verdict, the policy version, and the inputs that a third party can verify offline, without trusting you.
- A tamper-evident chain so the sequence of decisions can be replayed and audited end to end.
None of that requires the model to be “trusted.” That's the point. You stop asking the model to police itself and put control where it has always lived in serious systems: in deterministic infrastructure with an audit trail.
The question to bring to every AI vendor
If you're responsible for AI in a regulated environment — banking, lending, insurance, healthcare — here's the one question to bring to every governance conversation. It's the same one I spent twenty years answering about databases:
Show me a decision from ninety days ago. Prove what rule was enforced, that it hasn't changed, and that the record wasn't altered.
If the answer is “our model is really well-aligned,” you have monitoring, not governance. If the answer is a deterministic verdict with signed, replayable evidence, you have something an auditor can stand on.
The AI industry spent its first era making models more capable. The next era belongs to the boring, essential infrastructure underneath them — the layer that can say no, deterministically, and prove it did. That's not a model problem. It's the oldest problem in enterprise data, wearing a new hat.