Centralised vs Federated AI Governance: Decision Rights, Approval Paths and Failure Modes

An AI governance programme fails in one of two ways: a central committee becomes a queue that teams route around, or business units approve their own AI with no common bar and nobody can say what is running. The operating model, meaning who holds which decision rights, decides which failure you are more exposed to. This guide compares a centralised model (one AI governance function approves and inventories everything), a federated or hub-and-spoke model (a central hub sets standards and handles the highest tiers, business-unit spokes approve the rest) and the transitions between them. It covers decision rights, risk-tier approval paths, ownership of the model and agent inventory, speed against consistency, the failure modes of each and the metrics that show which one is working. It is for CISOs, chief AI officers, risk leads and AI platform owners. The programme itself (frameworks, policy, oversight) is in the AI Governance Guide and the committee's charter and membership are in the AI Ethics Board and AI Review Committee Guide; this page does not repeat them.

Key takeaways

• Decide decision rights by tier, not by organisation chart. The question is not "central or local" but which tiers of use case each body may approve, and who may accept residual risk.
• Centralise early, federate when the guardrails are in the platform. Microsoft's AI Center of Excellence guidance says centralisation "at the onset accelerates AI adoption" and that moving to an advisory model is only possible once governance is embedded in platform operations.
• The inventory stays central in every model. Spokes can own entries, but there is one register, one schema and one tiering method; NIST AI RMF GOVERN 1.6 asks for mechanisms "to inventory AI systems".
• Each model has a signature failure. Centralised: the bottleneck that breeds shadow AI. Federated: inconsistent bars and quiet risk acceptance by people with an incentive to ship.
• Measure the model, not just the programme. Approval lead time, the share of use cases found outside the register, and tier-consistency of spoke decisions tell you whether the operating model fits.

The three operating models

• Centralised: one AI governance function (often a Center of Excellence plus a review committee) receives every intake, tiers it, approves it and owns the register. The UK Government AI Playbook describes this shape: "a group of senior leaders and experts to set principles and review and authorise uses of AI", supported by a use cases register. Microsoft describes the trade-off directly: "A centralized model ensures control and consistency, while an advisory approach provides flexibility."
• Federated (hub and spoke): the hub writes policy, the tiering method, control standards and the register schema, and decides the highest tiers. Spokes in each business unit or region run intake, approve lower tiers against the hub's standards and keep their entries current. US federal policy has this shape: OMB M-25-21 requires each agency to designate a Chief AI Officer and, for CFO Act agencies, an AI Governance Board chaired at Deputy Secretary level, while directing agencies to "enable trained and accountable agency officials at the lowest appropriate level" to manage AI risk.
• Advisory (mature federated): the centre stops approving most work and sets guardrails that platforms enforce. Microsoft's guidance is to "replace the CoE gatekeeper model that blocks work with an advisory group that sets guardrails", with frontline teams owning delivery while forums provide policy and oversight.

Most organisations are not purely one model. The useful description is a decision-rights matrix that says, per tier, who decides.

Side-by-side comparison

Decision rights: who decides what

NIST AI RMF GOVERN 2.1 asks that "roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented", and GOVERN 2.3 that "executive leadership of the organization takes responsibility for decisions about risks". An operating model satisfies both only if the decision rights are written per decision, not per committee. Use a matrix like this one and publish it with the policy.

Two rights should stay central whatever the model. Exceptions: M-25-21 lets the CAIO waive minimum practices for a specific application only with a written risk assessment and annual recertification, and states the responsibility "shall not be delegated down to other officials". And the stop right: the hub must be able to suspend any system, including one a spoke approved.

Risk-tier approval paths

The tiering method itself is covered in the AI Use Case Risk Tiering Guide. What the operating model changes is the path a use case takes through it.

1. Intake: a single form feeding the central register in both models. Federated organisations route the entry to the owning spoke automatically.
2. Tiering: centralised, by the centre; federated, by the spoke, with the hub sampling a fixed share of decisions and every tier-3 candidate.
3. Review: security, privacy, legal and model risk review scaled to tier. In federated models the spoke runs tier-2 review but draws on hub specialists for security and model validation rather than building its own.
4. Independent challenge: for the highest tier, a review independent of the sponsor. M-25-21 requires independent review of high-impact use cases before risk acceptance, and the same logic applies to private organisations.
5. Risk acceptance: named executive, recorded in the register.
6. Re-review triggers: model change, new data source, new tool or write permission for an agent, new user population, incident.

Regulation can force a path regardless of model. Under the EU AI Act, deployers of high-risk systems must assign oversight to "natural persons who have the necessary competence, training and authority", monitor operation, inform the provider of risks and keep automatically generated logs for at least six months (Article 26). Those obligations land on whichever unit deploys the system, so a federated model must make spokes aware of them; see EU AI Act Provider vs Deployer Obligations.

Model and agent inventory ownership

Inventory is where federated programmes most often fail quietly. Use one register for both models, with ownership of the entry separated from ownership of the register.

• Register owner: always the hub or central function. It owns the schema, the tiering fields, the reconciliation process and reporting. The AI Register and AI Inventory Template gives a starting schema.
• Entry owner: the accountable business owner of the use case, in the spoke for federated models. Not the vendor, not the data scientist.
• Agents: agents carry identities, credentials and tool permissions, so their entries must link to the identity record; see the AI agent registry and AI Agent Registry vs CMDB vs IGA.
• Third-party AI: NIST GOVERN 6.1 calls for policies addressing "AI risks associated with third-party entities". SaaS features and connected AI apps are entries too. The Vercel Context.ai breach began with an AI tool an employee had connected to a corporate account with full access, exactly the kind of system a spoke-only view misses.
• Reconciliation: the hub compares the register against discovery sources (SSO and OAuth grants, network and gateway logs, cloud AI service usage, agent platform tenants) and assigns anything unmatched to a spoke. See Shadow AI Discovery.

Speed against consistency

The core trade-off is real but often mis-stated. Centralised models are not slow because central teams are slow; they are slow because volume grows faster than specialist capacity. Microsoft warns to "watch for approval delays and knowledge bottlenecks where AI experts in the CoE can't support all teams". Federated models are not fast because spokes are careless; they are fast because low-tier decisions are made close to the work.

The pattern that works in both models is to make the safe path the fast path: approved building blocks reviewed once centrally, with each use case reviewed only for what it adds.

Failure modes

Centralised: the bottleneck. Intake queues lengthen, teams experiment on personal accounts or unsanctioned tools, and the register describes a shrinking share of reality. The Samsung ChatGPT leak shows the cycle from the other side: staff pasted source code into a public chatbot, and the response was a temporary restriction on generative AI tools, which pushes demand towards unsanctioned routes unless an approved option follows. Signals: rising lead time, falling intake volume while AI usage in discovery data rises, and committee agendas full of tier-1 items.

Federated: divergent bars. Spokes tier the same kind of use case differently, approvers sit inside the line that wants the system, and residual risk is accepted by people rewarded for shipping. Entries go stale because nobody outside the spoke checks them. Signals: tier distribution varies widely between spokes with similar work, hub sampling finds re-tiered cases, exceptions appear that the hub never granted.

Both: governance that ignores identity. An approved agent runs under a shared service account or a person's token, so the register says "approved" while nobody can revoke its access cleanly. See the Citizen Developer and Internal AI App Governance Guide for the citizen-built case.

Choosing: decision guidance

Small organisations should not build spokes: one accountable lead, a short policy and a fast track are enough. Large organisations usually end up federated for tiers 1 and 2 with central decisions for tier 3, exceptions and stopping.

Worked scenario: moving from centralised to federated

An illustrative insurer with four business units ran a central AI review committee meeting fortnightly. After eighteen months the backlog was 70 items with a median lead time of nine weeks, while the gateway logs showed AI usage from 40 tools not in the register.

1. Diagnose: 80% of backlog items were tier 1 or 2; the committee was spending its time on chat assistants and summarisation.
2. Build guardrails first: an approved model list behind a gateway with data loss prevention, an agent tool allow list, and pre-approved patterns for internal summarisation.
3. Delegate: each business unit appoints an AI risk owner and a small review board for tier 2; tier 1 becomes self-certification against a checklist, logged in the register.
4. Keep central: tiering method, register, tier 3 (claims decisions, pricing, agents writing to policy systems), exceptions and the stop right.
5. Calibrate: the hub re-tiers a monthly sample from each unit and publishes disagreements as worked examples.
6. Result to watch: lead time for tier 1 and 2 falls, unregistered tools in discovery data fall, and hub sampling disagreement stays low.

How to implement: phased approach

1. Write the decision-rights matrix before changing any committee. Get executive sign-off, since GOVERN 2.3 puts risk decisions on executive leadership.
2. Fix the register and tiering method centrally. Federation without a shared schema produces several registers that cannot be compared.
3. Put guardrails in the platform: gateways, approved models, agent identity and permission standards.
4. Pilot one spoke with delegated tier-1 and tier-2 rights for a quarter, with the hub reviewing every decision in parallel (shadow mode) before trusting it.
5. Extend to other spokes once pilot disagreement is low, keeping sampling on.
6. Rollback: the hub can withdraw a spoke's delegated rights by tier if sampling disagreement or incidents rise; write that into the matrix from day one.

For the role assignments themselves, use the AI Governance RACI Template.

Detection and measurement

Programme-level measures are in AI Governance Metrics; the table above is only what distinguishes the models.

Framework mapping

Practitioner checklist

• Publish a decision-rights matrix per tier, signed off by the executive committee.
• Keep one register, one schema and one tiering method, owned centrally.
• Keep exceptions, the highest tier and the stop right with the hub in any model.
• Require independent review before accepting risk on the highest tier.
• Build pre-approved patterns and platform guardrails before delegating approvals.
• Sample and re-tier spoke decisions monthly; publish the disagreements.
• Reconcile the register against discovery data and assign every unmatched system an owner.
• Link every agent entry to an owned identity and its permissions.
• Track lead time and shadow usage together: one without the other misleads.

Standards and references

• NIST: AI Risk Management Framework Core
• OMB: M-25-21 Accelerating Federal Use of AI through Innovation, Governance, and Public Trust
• EU AI Act: Article 26 Obligations of Deployers of High-Risk AI Systems
• NIST: Cybersecurity Framework 2.0
• Microsoft: Cloud Adoption Framework, AI Center of Excellence
• UK Government: AI Playbook for the UK Government

Related NHI Mgmt Group resources: AI Governance Guide, AI Ethics Board and AI Review Committee Guide, AI Model Risk Management Guide, AI Agent Governance Health Check.