Governing AI Agents Across Business Units: Centralized Policy vs. Federated Control

When an enterprise has one AI agent managed by one team, governance is a team-level concern. The team writes the policy, validates the agent, monitors production behavior, and owns the audit trail. The governance model is implicit: whoever built the agent governs the agent.

When an enterprise has forty AI agents managed by eight business units across four geographies, that implicit model breaks. Each business unit has different risk tolerances, different regulatory obligations, different customer populations, and different operational contexts. The marketing team's AI agent that generates campaign copy operates under fundamentally different governance requirements than the underwriting team's AI agent that influences credit decisions. Yet both operate under the same corporate brand, the same regulatory perimeter, and the same board-level risk appetite.

The question is not whether to govern these agents. The question is who defines the governance rules, who enforces them, and how much variation is permissible across business units. This is the governance model question, and getting it wrong produces one of two failure modes: over-centralization that stifles business units with inappropriate constraints, or under-centralization that creates ungoverned pockets where agents operate outside the organization's risk tolerance.

This article examines three governance models -- centralized, federated, and hybrid -- and maps each to the organizational archetypes where it works best. It then examines the technical requirements that all three models share: policy namespacing, inheritance hierarchies, and audit scope management.

The Governance Model Spectrum

Enterprise AI governance models exist on a spectrum defined by a single axis: where does policy authorship authority reside? At one end, a single central team authors all policies for all agents across all business units. At the other end, each business unit authors its own policies with no central coordination. Most organizations land somewhere between these extremes, and the right position on the spectrum depends on the organization's regulatory environment, organizational structure, and risk profile.

Model 1: Centralized Governance

In the centralized model, a single AI governance team -- sometimes called the AI Center of Excellence, AI Risk Office, or AI Policy Team -- authors, maintains, and enforces all policies that govern all AI agents across the organization. Every agent, regardless of which business unit owns it, operates under policies defined by the central team and evaluated by a central policy engine.

How It Works

The central team maintains a single policy store containing every rule that governs every agent. When a business unit wants to deploy a new AI agent or modify an existing one, the request goes through the central team, which defines the appropriate policies, validates them against the organization's risk framework, and deploys them to the central policy engine. The central engine evaluates every agent decision against the applicable policies and produces a unified audit trail.

Policy changes follow a central change management process: the business unit requests a change, the central team evaluates the request, implements the modification, tests it against the behavioral test suite, and deploys it through the central rollout process. No business unit can modify policies directly.

Strengths

Consistency is the primary strength. Every agent operates under policies authored by the same team using the same standards. There is no risk that two business units will define contradictory policies for similar agents, or that one business unit's lax governance will create enterprise-level risk. The audit trail is unified -- a regulator or auditor can query the central store for a complete picture of every AI decision made anywhere in the organization.

Regulatory defensibility is the second strength. When a regulator asks "how do you govern your AI systems?", the answer is concrete and singular: this team, this process, this policy store, this audit trail. There is no ambiguity about who owns governance, how policies are approved, or where the evidence lives.

Weaknesses

The central team becomes a bottleneck. Every policy change for every agent in every business unit flows through one team. As the number of agents grows, the central team's capacity becomes the binding constraint on the organization's ability to deploy and iterate on AI systems. Business units that need rapid iteration -- product teams shipping AI features on two-week cycles, for instance -- find themselves waiting weeks for policy reviews.

Domain expertise is the second weakness. The central team cannot be expert in every business domain the organization operates in. A policy team that deeply understands credit risk underwriting may lack the domain knowledge to write effective policies for supply chain optimization agents or customer service agents. Policies authored without domain expertise tend toward overly broad restrictions that reduce agent utility without proportionally reducing risk.

Organizational Archetype: Regulated Industries

Centralized governance maps most naturally to organizations in heavily regulated industries: banking, insurance, healthcare, and pharmaceutical companies. These organizations operate under regulatory frameworks that require demonstrable, unified governance -- SR 11-7 for banking, HIPAA for healthcare, FDA regulations for pharmaceutical applications. The cost of the central bottleneck is justified by the regulatory cost of governance inconsistency.

Gartner's 2025 AI governance survey found that organizations in regulated industries are approximately three times more likely to operate centralized governance models than those in less regulated sectors, and that centralized governance correlates with faster regulatory examination resolution for AI-related findings.

Model 2: Federated Governance

In the federated model, each business unit defines, maintains, and enforces its own AI governance policies. There is no central policy team. Each business unit operates its own policy store and policy engine, and produces its own audit trails. An enterprise-level governance function may exist, but its role is advisory rather than authoritative -- it may publish guidelines, share best practices, and facilitate cross-BU communication, but it does not author or enforce policies.

How It Works

Each business unit's AI team owns the complete governance lifecycle for its agents. The product team's AI engineers write the policies for product AI agents. The operations team's AI engineers write the policies for operations AI agents. Each team maintains its own policy store, runs its own policy engine, and manages its own audit trail. Policy changes are approved within the business unit according to the business unit's own change management process.

An enterprise AI governance board may exist as a coordination function, meeting periodically to share lessons learned, identify cross-BU risks, and align on broad governance principles. But the board does not have approval authority over individual BU policies -- it operates by influence rather than control.

Strengths

Speed is the primary strength. Business units can iterate on AI agent policies without waiting for central review. A product team that discovers its AI feature needs a policy adjustment can implement, test, and deploy the change within its own sprint cycle. There is no organizational dependency on a central team's capacity.

Domain expertise is the second strength. The people writing the policies are the people who understand the business domain. The underwriting team writes underwriting policies. The customer service team writes customer service policies. Each policy reflects the domain knowledge of the team closest to the operational context.

Weaknesses

Inconsistency is the primary risk. Without central coordination, different business units may define contradictory governance standards. One business unit may permit AI agents to take autonomous actions that another business unit prohibits for the same risk level. Data handling policies may vary across BUs, creating compliance gaps when data flows between units. The organization's governance posture is only as strong as its weakest business unit's implementation.

Enterprise-level audit is the second weakness. When a regulator asks "how do you govern your AI systems?", the answer is not a single, unified narrative. It is "each business unit governs its own systems according to its own processes." Assembling an enterprise-level view of AI governance requires aggregating across multiple policy stores, multiple audit trails, and multiple governance processes. For organizations that need to demonstrate enterprise-wide AI governance -- which is an increasing regulatory expectation -- federated governance creates significant evidence assembly overhead.

Organizational Archetype: Product-Led Growth Companies

Federated governance maps most naturally to product-led growth companies where speed of iteration is the primary competitive advantage. These organizations -- typically SaaS companies, platform businesses, and technology companies in less regulated sectors -- prioritize autonomous team velocity over centralized consistency. Each product team ships independently, and governance is one of many functions that the team owns end-to-end.

Stanford HAI's 2025 AI Index Report notes that federated governance models are most prevalent among technology companies with fewer than 5,000 employees and limited regulatory exposure, where the organizational cost of centralization outweighs the risk reduction benefit.

Model 3: Hybrid Governance

The hybrid model separates governance into two tiers: a central team defines shared governance primitives (foundational rules, constraints, and standards that apply to all AI agents), and business units compose these primitives with BU-specific rules to create the complete governance policy for their agents.

How It Works

The central AI governance team maintains a library of policy primitives: rules that encode enterprise-wide requirements. These primitives might include:

• Data classification rules: what data categories can be processed by AI agents, with what protections
• Authority boundaries: maximum action severity that any AI agent can take without human approval
• Audit requirements: minimum trace schema that all agents must produce
• Regulatory compliance rules: constraints required by regulations that apply to the entire organization
• Cross-BU interaction rules: governance for agents that operate across business unit boundaries

Business units inherit these primitives and compose them with BU-specific rules. The underwriting team adds credit-specific decision rules to the enterprise primitives. The marketing team adds content-specific safety rules. The customer service team adds escalation and authority rules specific to customer interactions. The resulting policy for each agent is a composition: enterprise primitives plus BU-specific rules.

The critical design principle is that BU-specific rules can narrow enterprise primitives but cannot override them. If the enterprise primitive specifies that no AI agent may commit financial transactions above $10,000 without human approval, a business unit cannot create a rule that raises that threshold. It can lower it -- the underwriting team might set its threshold at $5,000 -- but it cannot exceed the enterprise constraint. This inheritance model ensures that enterprise-level risk boundaries are maintained while giving business units flexibility within those boundaries.

Strengths

The hybrid model captures the primary strengths of both centralized and federated approaches. Enterprise-wide consistency on foundational governance requirements is maintained through the shared primitives. Business unit autonomy for domain-specific governance is preserved through BU-level composition. The central team's workload scales with the number of enterprise primitives, not the number of agents -- adding a new agent in a business unit does not require central team capacity unless the agent requires new enterprise-level primitives.

Audit scope management becomes tractable. Enterprise-level auditors can query the shared primitives to understand the governance floor that applies to all agents. BU-level auditors can examine the complete composed policy for specific agents. The audit trail can be federated (each BU stores its own traces) while providing enterprise-level aggregation through the shared trace schema enforced by the enterprise audit primitive.

Weaknesses

Complexity is the primary cost. The hybrid model requires infrastructure that neither the centralized nor federated model requires: a policy inheritance system that correctly composes enterprise primitives with BU rules, a validation system that prevents BU rules from overriding enterprise constraints, and an audit system that can operate at both enterprise and BU scope. This infrastructure is not trivial to build and maintain.

Boundary disputes are the second cost. When is a governance requirement an enterprise primitive versus a BU-specific rule? The central team and business units will inevitably disagree about where the boundary should be drawn. Clear criteria for what qualifies as an enterprise primitive -- typically, requirements driven by regulation, board-level risk appetite, or cross-BU impact -- reduce but do not eliminate these disputes.

Organizational Archetype: Large Diversified Enterprises

Hybrid governance maps most naturally to large, diversified enterprises that operate across multiple business lines with different risk profiles but share a common regulatory and reputational perimeter. Financial services conglomerates with retail banking, wealth management, and insurance divisions. Healthcare systems with hospital operations, insurance, and pharmaceutical research. Technology conglomerates with consumer products, enterprise software, and cloud infrastructure.

McKinsey's enterprise AI governance analysis identifies the hybrid model as the fastest-growing governance pattern among organizations with more than 10,000 employees, noting that it addresses the central bottleneck problem that causes centralized governance to break down at scale while maintaining the enterprise-level consistency that federated governance lacks.

Technical Requirements Across All Three Models

Regardless of which governance model an organization adopts, three technical capabilities are required to implement it effectively: policy namespacing, inheritance hierarchies, and audit scope management.

Policy Namespacing

When multiple teams define policies -- whether in a federated or hybrid model -- naming collisions and scope confusion are inevitable without explicit namespacing. A policy named "max_transaction_limit" means different things in the retail banking division than in the wealth management division. Policy namespacing assigns each policy a hierarchical identifier that encodes its organizational scope:

// Enterprise-level primitive
enterprise.data_classification.pii_handling_rule_v3

// Business unit composition
enterprise.retail_banking.credit.max_auto_approve_amount
enterprise.wealth_management.advisory.suitability_check_v2

// Agent-specific policy
enterprise.retail_banking.credit.underwriting_agent.thin_file_handling

The namespace hierarchy makes the policy's scope self-documenting: anyone inspecting the policy can immediately identify whether it is an enterprise primitive, a BU-level rule, or an agent-specific configuration. The namespace also provides the structure for inheritance: rules at a higher namespace level apply to all entities at lower levels unless explicitly narrowed.

Inheritance Hierarchies

In the hybrid model, BU-level rules inherit from enterprise primitives. This inheritance must be explicit, verifiable, and constraint-preserving. The system must guarantee three properties:

• Completeness: Every agent's effective policy includes all applicable enterprise primitives, not just the BU-specific rules. An agent cannot operate under a policy that omits an enterprise requirement.
• Monotonic narrowing: BU rules can only narrow enterprise constraints, never widen them. This property must be enforced by the policy composition engine, not relied upon as a convention.
• Conflict resolution: When a BU rule and an enterprise primitive address the same decision dimension, the resolution rule must be deterministic and documented. Typically: the more restrictive rule applies.

The NIST AI RMF Govern function addresses this requirement by specifying that organizations must establish clear accountability hierarchies for AI governance, including the relationship between enterprise-level and operational-level governance functions. The inheritance hierarchy is the technical implementation of that organizational requirement.

Audit Scope Management

Different stakeholders need different views of the governance audit trail. An enterprise risk officer needs to see policy violations across all business units. A BU compliance officer needs to see all agent decisions within their unit. An individual agent owner needs to see the detailed decision traces for their agent. A regulator may need any of these views depending on the scope of their examination.

Audit scope management requires that decision traces be tagged with sufficient metadata to support filtered queries at any organizational level: enterprise, business unit, team, agent, and individual decision. The trace schema must include:

• Organization identifier
• Business unit identifier
• Agent identifier and version
• Policy namespace and version for every rule evaluated
• Whether each rule is an enterprise primitive or a BU-specific rule
• The evaluation outcome and the action taken

With this metadata, audit queries can be scoped to any organizational level without requiring separate audit infrastructure for each level. A single trace store serves enterprise-wide, BU-level, and agent-level audit needs through filtered queries rather than replicated data.

Choosing the Right Model

The governance model decision is driven by three factors: regulatory intensity, organizational structure, and AI maturity.

Organizations early in their AI journey -- with fewer than ten agents across two or three business units -- should start centralized. The overhead of building inheritance hierarchies and policy namespacing is not justified when the central team can directly manage the policy set. As the number of agents and business units grows, the central bottleneck will signal when to evolve toward the hybrid model.

Organizations with existing federated AI deployments that are encountering governance inconsistency should not attempt to centralize overnight. The migration path is to introduce enterprise primitives incrementally: start with the highest-risk governance requirements (data classification, maximum authority boundaries, minimum audit standards), build the inheritance infrastructure, and gradually expand the enterprise primitive library as the organization identifies which governance requirements must be consistent and which can remain BU-specific.

The Governance Model Is an Architectural Decision

The choice between centralized, federated, and hybrid governance is often framed as an organizational design question -- who reports to whom, which committee approves what. But it is fundamentally an architectural decision. The governance model determines the technical infrastructure required: a single policy store or many, a single evaluation engine or distributed engines, a unified audit trail or federated traces, an inheritance system or not.

Organizations that treat the governance model as a reporting-line decision and defer the technical architecture find themselves with governance policies that cannot be enforced consistently, audit trails that cannot be aggregated, and policy changes that cannot be validated across organizational boundaries. The reporting lines matter, but they are effective only when the technical infrastructure supports the governance model they describe.

For the technical architecture that supports governed agent decisions -- the policy evaluation engine, the decision trace infrastructure, and the safe rollout process that underlies all three governance models -- see Infrastructure for Deterministic AI Decisions. For the specific challenge of governing agents that delegate to other agents across organizational boundaries, see Multi-Agent Governance: Who Is Responsible When Agents Delegate to Agents?.