TL;DR: AI governance usually stalls without anyone being wrong. Enterprise risk keeps the list in a spreadsheet, security governance wants a monitoring product, the cyber team wants an agent inventory as asset management, and IT is split by platform. The answer isn't a tool that unifies them. It's a federated model where one center owns the standard and the units execute against it.
Four teams. Four correct answers. No program.
That's the shape I keep seeing, and it's more common than the version where somebody's being obstructive. On one 2026 call the presenting problem wasn't shadow AI or a bad vendor. It was that nobody could get the stakeholders pointed the same direction.
Enterprise risk was, in their own words, quite happy managing AI use cases in a spreadsheet. Security governance wanted a monitoring product. The cyber team wanted an agent inventory and treated it as asset management. IT was organized by platform, so each platform team had its own view. The person on the call wanted help getting everyone to one picture.
Every one of those positions is defensible. That's exactly why this doesn't resolve on its own.
Why does AI governance stall when nobody is wrong?
Because each team is optimizing for a real obligation, and the obligations don't overlap. Enterprise risk owes the board a register. Security governance owes evidence of monitoring. The cyber team owes an accurate asset list. Platform teams owe uptime for their platform. Nothing in that list makes anyone responsible for the whole.
So the work that falls between those obligations doesn't get done, and it doesn't get escalated either, because no one's failing.
Watch how it plays out. The spreadsheet is accurate and incomplete. The monitoring product covers one traffic path. The asset inventory counts things that registered themselves. Each artifact is defensible in its own review, and stacked together they still don't answer the only question that counts, which is what agents exist and what they're allowed to do.
There's a second failure underneath this one. The teams also can't be convened. On more than one call the starting point wasn't disagreement, it was that the right people had never been in one meeting about this at all.
What is a federated operating model for AI governance?
One center owns the standard and defines what compliant means. The business units execute against it. Approved patterns are the fast path, so following the standard is the quickest way to ship. The center keeps two powers: it grants exceptions, and it can switch off anything that isn't registered.
That's the whole model. It fits on an index card, and the reason it works is that it doesn't ask anyone to give up their obligation.
Notice what the center does not do. It doesn't build the agents. It doesn't run the platforms. It doesn't review every use case, which is the trap most central governance teams fall into and then drown in. Its product is a written standard plus a small number of pre-approved ways to build.
Enterprise risk still keeps the register, and now the register has a defined source. Security governance still monitors, and now there's a written statement of what compliant looks like so monitoring has something to compare against. The cyber team still owns the inventory, and registration feeds it. Platform teams still own their platforms, and they get a pattern catalog instead of a case-by-case queue.
What does the center actually own?
Four things, and it should resist owning a fifth.
The standard. A written definition of compliant that a unit can read and self-assess against. If a team can't tell whether they pass without calling you, it isn't a standard yet.
The approved patterns. A short catalog of sanctioned ways to build and expose an agent. This is the thing that makes the standard livable.
Exception authority. One place grants exceptions, with an expiration date and a named requester attached to each one. Exceptions that never expire are how a standard dies without anyone voting on it.
The off switch. The stated right to disable anything unregistered. It gets used rarely. Its value is that everyone knows it exists.
Keeping the list this short is deliberate. Every additional thing the center owns becomes a queue, and a queue is what turns a governance function into a bottleneck people plan around.
What is a lunch menu of approved patterns?
It's a small published set of ways you're allowed to expose an agent, written so a team can pick one and go. A team picks from the menu and gets the fast path. A team that wants something off the menu files for an exception and accepts the wait.
Publish the menu before anybody asks for it. Governance that only exists as answers to individual questions doesn't scale past the person answering.
The items on the menu are specific, not categorical. Read-only agent against a sanctioned data set with logging on. Agent that proposes a change and waits for human approval. Agent with write access inside one system, scoped to one record type, with an undo path. Agent calling an external tool through a registered gateway. Each entry names the identity model, what gets logged, who approves it, and what the undo path is.
Here's why this beats a policy document. A policy tells people what not to do and leaves them to design the alternative. A pattern catalog hands them a design that already passed, which means the secure path is also the path of least resistance. Most teams will take the shortcut if the shortcut is the approved one.
What happens when the team raising the alarm can't fix anything?
They file the concern and nothing moves, which is a specific failure worth naming. On a September 10, 2026 call, the people describing the problem were incident response and threat analysts. They had no working line to the proxy team, the endpoint team, security engineering, or anyone else who could change a rule. When the conversation turned to incentives, the answer was silence.
That's not a governance gap. That's an org chart problem showing up as a governance gap.
It counts because it inverts who's motivated. The team that feels the pain has no authority over any of the controls that would reduce it. The teams with authority feel none of the pain, so the request lands in their queue as somebody else's priority. No policy language fixes that arrangement.
A federated model helps here in a way that's easy to miss. When the center owns the standard, the analyst's finding stops being a request between peers and becomes a compliance fact. "The proxy can't enforce path-level rules" is a complaint when it goes team to team. It's a gap against a published standard when it goes to the center. The second version has somewhere to go.
How do you start when you can't even get everyone in one meeting?
Write the standard first and circulate it as a draft. Waiting for consensus before writing anything is how these efforts stall for two quarters. A draft gives people something to react to, and reacting is much easier than convening.
Send it with a deadline and a default. Silence means agreement, stated up front.
Then take the artifacts that already exist and map them, rather than replacing them. The risk spreadsheet becomes the register of record for use cases. The asset inventory becomes the register of record for running agents. The monitoring product becomes the evidence source for one specific control, named explicitly. Nobody loses their tool, and each one gets a defined job instead of an overlapping claim.
The last piece is the hardest and it isn't technical. Somebody has to be named as the center. Not a committee. Committees deliberate, and what's needed here is a decision about who decides. One name, with the authority to grant an exception, is worth more than a six-person working group with a charter.
What should you do in the next 30 days?
Write one page defining compliant and send it out as a draft with a response deadline. The draft does more work than the meeting would have.
Publish four approved patterns. Read-only, propose-and-approve, scoped write with an undo path, and external tool calls through a registered gateway. Four is enough to start.
Name one person as exception authority and give every exception an expiration date. A register of open exceptions with dates on them is a real management tool.
Map each existing artifact to one defined job. The spreadsheet, the inventory, the monitoring product, and the per-platform views each get a written role, so the overlap stops being an argument.
Ask the team that filed your last AI concern whether they can reach the people who own the fix. If the answer is no, you found the actual blocker and it isn't policy.
State the off switch in writing even if you never use it. Unregistered means disableable. Say it once and clearly. Then leave it alone.
Key takeaways:
AI governance usually stalls because four teams each hold a defensible partial obligation and nobody is accountable for the whole picture.
A federated model gives the center the standard, the approved patterns, exception authority, and the right to disable anything unregistered, while units execute.
Approved patterns beat policy documents because they hand teams a design that already passed review, making the secure path the fast path.
Exceptions need an expiration date and a named requester, or the standard erodes without anyone deciding to abandon it.
When incident response raises a concern but has no line to the proxy or endpoint teams, that's an org chart problem, and a central standard converts the complaint into a compliance gap with somewhere to go.
Starting with a circulated draft standard and a response deadline beats waiting for a meeting that the calendar will not produce.
Frequently asked questions
Isn't a federated model just a committee with extra steps?
The difference is where decisions land. A committee deliberates and produces a recommendation that somebody else has to act on. A center publishes a standard, grants exceptions, sets expiration dates, and can switch things off. One name holds that authority, and that's what keeps it from becoming a meeting.
How big does the center need to be?
Smaller than people expect, because its output is a document and a pattern catalog rather than a review queue. One accountable person with part-time help from identity and platform teams covers the early version. The size problem starts when the center takes on per-use-case review, so keep that off the list for as long as possible.
What if enterprise risk refuses to give up the spreadsheet?
Let them keep it and give it a defined job. The spreadsheet becomes the register of record for approved use cases, fed by registration, and the running agent inventory lives with the cyber team. The problem was never the spreadsheet, it was that four artifacts each claimed to be the picture.
Does this work when business units have their own security teams?
It works better, because federation assumes local execution. Unit security teams become the people who apply the standard and route exceptions upward. What breaks the model is a unit that writes its own competing standard, which is why defining compliant centrally is the one thing that can't be delegated.
How do you handle a vendor that promises to unify all of this?
Evaluate it as evidence for one control, not as the operating model. Tools can show you traffic or hold an inventory, and that's useful. What they can't do is decide who grants an exception. Buying before the model exists usually produces a product that reports on a standard nobody wrote.
Where does Zero Trust fit in a federated model?
Zero Trust is the foundation the standard is written against. Verify every request and grant the least access needed. Assume something inside is already compromised. The approved patterns are how those principles turn into specific builds a unit can ship, which is what makes the standard enforceable instead of aspirational. Agents need one more check on top of that foundation, which is a judgment about how much autonomy each one has earned.
The uncomfortable part of this model is that it only works if one person is willing to be named, and most organizations would rather run a working group than name somebody.