Trust is not evidence.

Vendor controls matter. Bias testing protocols, documentation standards, incident response procedures — most AI vendors we work with take this seriously, and it usually looks solid in the sales deck. None of that tells you what level your own organization is actually operating at.

The real test of AI governance isn't whether policies exist. It's whether you can prove the AI operated within its authorized boundaries when it mattered — on a timeline set by whoever's asking, not by whoever's answering. Proof beats intention the moment anyone with real standing actually looks: an auditor, a regulator, opposing counsel, a customer's security team.

Inherited governance vs. operational governance

At Inherited, the vendor's framework is the program. You're protected exactly as much as their documentation promises, and you find out what that promise was worth during an incident — not before one. Most companies buying AI features today are sitting at Inherited without realizing it's a tier at all.

Moving to Operational doesn't mean replacing the vendor's framework. It means three specific things change:

• The contract requires the vendor to meet standards your organization defines — not just the ones they already grade themselves against.
• Your team can see how the feature performs in production — how it behaves in customers' hands, not only whether it passed acceptance testing before it shipped.
• Governance track record factors into renewal and selection — the same way cost and uptime already do, instead of sitting outside the commercial conversation entirely.

If an AI feature from a vendor produced a bad outcome for a customer tomorrow, would your contract already tell you who owns what happens next? Or would that conversation start from zero, in a room, under pressure, with legal on the line?

The harder problem: whoever holds the evidence can edit it

Most logging pipelines can be edited by the same party being asked to answer for the incident. The evidence exists — but its custody is controlled by the interested party, which is exactly what fails the moment it reaches anyone with real standing.

That points to a distinction most governance conversations skip past entirely. Ops logs answer "what happened for us." Governance evidence has to survive a party who wants it to be wrong. That's a different bar, and a different architecture — one you cannot retrofit after the incident, only build in ahead of it.

And attestation doesn't remove the trust problem, it just relocates it. The moment you introduce a system that proves the AI behaved, someone has to prove that system behaved too. Whoever solves this next has to answer "who attests the attester" on day one, or they've just moved the gap one layer over and called it solved.

Why the EU AI Act just made this more urgent, not less

In May 2026, EU negotiators reached a provisional agreement to push back some of the Act's own high-risk compliance deadlines — the kind of delay that reads, on the surface, like permission to slow down. It's the opposite signal.

The regulation is still catching up to its own ambition. What's shifting underneath it isn't the question "can we use AI this way," the one AI governance has spent the last few years answering with policies, principles, and named accountability. It's a second, quieter question: what does the AI actually rely on? Is the data accurate and complete? Does the system have the right business context? Do we know where any of it came from?

Call the first one AI Governance — the guardrails around the system. Call the second one Governance for AI — the foundation underneath it. Both are necessary, and the market is only now starting to realize how much weight the second one is carrying. A regulatory delay doesn't pause that work. It just removes the deadline as an excuse to keep deferring it.

Governance has to travel with the work

Even accurate, well-governed data can produce the wrong understanding if meaning, timing, relationships, provenance, or authority get lost on the way to a decision. And even correct data, correctly understood, doesn't answer the operational question underneath the governance conversation: can this specific agent take this specific action, against this resource, under these conditions, right now?

That question doesn't live in a single policy document. It lives across three layers, and most governance programs are strong on the first two and thin on the third:

• The organization sets the rules — risk tolerance, accountability, prohibited actions, minimum controls, approval standards.
• The agent carries an identity — who owns it, what it's approved to do, what systems and data it can reach, what tools it can invoke.
• The workflow carries the controls — what the agent can do in this specific process, when human approval is required, what triggers escalation, when execution has to stop.

The same agent, with identical permissions, represents very different risk depending on which of these it's operating inside. It might summarize information in one process, recommend an action in the next, and execute a transaction in a third. Same agent, same identity, three different risk profiles — because a policy can require human review, and an agent profile can define permissions, but only the workflow layer actually stops execution when the required review never happens.

We wouldn't let the same agent propose an action, authorize it, execute it, and then independently attest that the execution was valid — that collapses segregation of duties into a single autonomous actor. And a permit granted for one action, under one set of conditions, shouldn't quietly become reusable authority just because the agent still holds it. Authority has to be bounded by scope, context, time, purpose, and state, with expiration and replay prevention built in from the start — not policies and committees hoping the technical layer catches up.

Runtime is where governance stops being a document and starts being architecture. It's where effective authority gets resolved before the action happens, not explained after it — and the audit trail is the evidence of that decision, not a substitute for making it.