Federated AI Governance: One Standard, Many Teams

TL;DR: AI governance usually stalls with nobody being wrong. Four teams each hold a defensible piece, and no one owns the whole. The fix is a federated model: one named center owns the standard, the approved patterns, exception authority, and the off switch, while business units execute against it.

Last updated October 5, 2026. This piece was rebuilt from the ground up around the operating model, with a 30-day plan you can start without a single meeting.

Here's a call from 2026 that will sound familiar. The presenting problem wasn't shadow AI or a bad vendor. It was that nobody could get the stakeholders pointed in 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. Four teams, four correct answers, no program.

Why does AI governance stall when nobody is wrong?

Because each team is optimizing for a real obligation, and the obligations don't overlap. Nothing in the list below makes anyone responsible for the whole, so the work that falls between obligations doesn't get done, and it doesn't get escalated either, because no one's failing.

Each artifact survives its own review. Stacked together, they still don't answer the only question that counts: what agents exist, and what are they allowed to do? And underneath that sits a second failure. 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 conformant 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 it works because it doesn't ask anyone to give up their obligation. Enterprise risk keeps the register, now with a defined source. Security governance keeps monitoring, now with a written statement of what conformant looks like to compare against. The cyber team keeps the inventory, fed by registration. Platform teams get a pattern catalog instead of a case-by-case queue.

The center owns four things, and should resist owning a fifth:

1. The standard.

   A written definition of conformant 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.

2. The approved patterns.

   A short catalog of sanctioned ways to build and expose an agent. This is what makes the standard livable.

3. Exception authority.

   One place grants exceptions, each with an expiration date and a named requester. Exceptions that never expire are how a standard dies without anyone voting on it.

4. The off switch.

   The stated right to disable anything unregistered. It gets used rarely. Its value is that everyone knows it exists.

Everything else the center takes on becomes a queue, and a queue is what turns a governance function into a bottleneck people plan around. The center doesn't build agents or run platforms, and it doesn't review every use case.

What does a menu of approved patterns look like?

A small published set of ways you're allowed to expose an agent, written so a team can pick one and go. Four entries are enough to start: a read-only agent against a sanctioned data set with logging on; an agent that proposes a change and waits for human approval; an agent with write access inside one system, scoped to one record type, with an undo path; and an agent calling an external tool through a registered gateway. Each entry names the identity model, what gets logged, who approves it, and the undo path.

Publish the menu before anybody asks. Governance that only exists as answers to individual questions doesn't scale past the person answering. And this is why a pattern catalog beats a policy document: a policy tells people what not to do and leaves them to design the alternative, while a catalog hands them a design that already passed. Most teams will take the shortcut when the shortcut is the approved one. Every pattern should still clear the four approval questions in how security says yes to AI agents.

What happens when the team raising the alarm can't fix anything?

They file the concern and nothing moves. 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 an org chart problem wearing a governance costume. The team that feels the pain has no authority over the controls that would reduce it, and the teams with authority feel none of the pain, so the request sits in their queue as somebody else's priority. No policy language fixes that arrangement.

A federated model helps in a way that's easy to miss. When the center owns the standard, an analyst's finding stops being a request between peers and becomes a conformance fact. "The proxy can't enforce path-level rules" is a complaint when it goes team to team. Measured against a published standard, it's a documented shortfall with somewhere to go.

What should you do in the next 30 days?

1. Write one page defining conformant and circulate it as a draft with a response deadline.

   Waiting for consensus is how these efforts stall for two quarters. Silence means agreement, stated up front.

2. Publish four approved patterns.

   Read-only, propose-and-approve, scoped write with an undo path, and external tools through a registered gateway.

3. Name one person as exception authority.

   Every exception gets an expiration date. A register of open exceptions with dates on it is a real management tool.

4. Map each existing artifact to one defined job.

   The spreadsheet becomes the register of record for use cases. The inventory becomes the register of record for running agents. The monitoring product becomes the evidence source for one named control. Nobody loses their tool.

5. 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.

6. State the off switch in writing.

   Unregistered means disableable. Say it once, clearly, then leave it alone.

Frequently asked questions

Isn't a federated model just a committee with extra steps?

The difference is where decisions rest. A committee deliberates and produces a recommendation somebody else has to act on. A center publishes a standard and grants exceptions with dates. It can also switch things off. One name holds that authority, which is 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, not a review queue. One accountable person with part-time help from identity and platform teams covers the early version. Size problems start when the center takes on per-use-case review, so keep that off its plate as long as possible.

What if enterprise risk refuses to give up the spreadsheet?

Let them keep it, with a defined job. The spreadsheet becomes the register of record for approved use cases, fed by registration. The problem was never the spreadsheet. It was that four artifacts each claimed to be the whole picture.

Where does Zero Trust fit in a federated model?

Zero Trust is the foundation the standard gets written against: verify every request, grant the least access needed, assume something inside is already compromised. The approved patterns turn those principles into specific builds a unit can ship. Agents add one more judgment on top, which is how much autonomy each one has earned.

Key takeaways

• AI governance stalls because four teams each hold a defensible partial obligation and nobody is accountable for the whole.

• A federated model gives the center four things: the standard, the approved patterns, exception authority, and the off switch. Units execute.

• Approved patterns beat policy documents because they make the secure path the fast path.

• Every exception needs an expiration date and a named requester, or the standard erodes without anyone deciding to abandon it.

• A circulated draft with a response deadline beats waiting for a meeting the calendar will never produce.

Before you write the standard, see where your agents actually stand. The free self assessment takes about ten minutes and gives you the baseline the draft can point at. For the person whose name goes on each agent, start with who owns your AI agent.

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. Be the organization that names somebody.