I visited two companies in the same week. The first had a centralized AI team. All AI decisions went through them. Nothing shipped without approval. The second had distributed AI. Every business unit built its own AI. The centralized company was slow. The distributed company was chaotic.

The problem isn’t centralization or decentralization. It’s that they’re both optimizing for the wrong thing.

The centralized company thought they were optimizing for control. What they got was bottleneck.

The distributed company thought they were optimizing for speed. What they got was risk.

Neither company understood the actual constraint: you need both speed and consistency. And the structure that gives you both of those isn’t about where you put the team. It’s about where you put the decision.

Why Centralization Doesn’t Work

A centralized AI team sounds good in theory. You have one group of experts. They set standards. They approve decisions. Nothing gets shipped that violates the standards.

What actually happens:

The centralized team becomes the bottleneck. Every business unit has to wait for the AI team to say yes. The business unit thinks: “We have a problem we could solve with AI. But it’s going to take six months to get approval.” So they either don’t solve the problem, or they find a workaround that bypasses the central team.

The central team thinks: “We’re protecting the company from bad AI decisions.” What they’re actually doing is training the organization to either wait or work around them.

Also, the centralized team can’t understand every business context. They make rules that work for some problems but not others. They say “we only use approved models” but different business units have radically different requirements. They say “we monitor for fairness” but fairness metrics are different for hiring vs. lending vs. content recommendation.

The company doesn’t end up with strong governance. It ends up with slow governance that’s frequently bypassed.

Why Decentralization Doesn’t Work

A decentralized structure sounds good on paper. Every business unit moves fast. They understand their own problems. They can experiment and iterate.

What actually happens:

Every business unit builds their own version of the same solution. The hiring team builds a resume screener. The recruiting team builds another one. The L&D team builds a third. None of them talk to each other. They’re all making different choices about data, models, monitoring, governance.

One team uses a model that’s biased against a protected class and doesn’t notice because they never thought to check. Another team’s system breaks down in production and they lose customer data because they didn’t think about operations. A third team’s decisions are unexplainable to regulators because they built a black box without documentation.

The company doesn’t end up with speed and flexibility. It ends up with fragmentation and invisible risk.

And the real problem: when something goes wrong in one business unit, the company’s regulatory exposure is enterprise-wide. The hiring team’s bias problem is a company problem. The recruiting team’s data loss is a company problem. The L&D team’s black box is a company problem.

So decentralization feels fast until it’s not. Then it’s expensive.

What Actually Matters Is the Decision Point

The real question isn’t “where does the team sit?” It’s “where does the authority sit?”

And here’s the shift that changes everything: authority should be at the decision point, not at the team location.

Let me explain what I mean.

In a centralized company, authority for all AI decisions is with the central team. A business unit comes and says: “We want to build a hiring screener.” The central team decides. That’s the problem. The central team doesn’t know enough about hiring to make that decision well.

In a decentralized company, authority is with the business unit. They decide. But the company has no way to ensure consistency or manage enterprise risk. A business unit makes a decision that creates regulatory exposure for the whole company, and the company can’t prevent it.

What actually works is splitting the authority:

The business unit decides: “We have a problem and we think AI can solve it.” That’s their decision. They know their problem better than anyone. They should have authority here.

A shared standards team flags: “If you use AI this way, here’s what you need to do around data quality, fairness, explainability, operational risk.” These aren’t approvals. They’re constraints.

The business unit decides: “We’ll meet these constraints with approach X.” That’s their decision. They know how to do it.

A shared audit function checks: “Are you actually meeting the constraints you committed to?” They’re not blocking. They’re verifying.

This distribution of authority gives you what you actually want:

• Speed: business units can move fast because they’re not waiting for approval
• Consistency: everyone is building to the same enterprise constraints
• Risk management: you’re checking for problems without blocking problems
• Accountability: it’s clear who decided what, and it’s clear why it was decided

How Standards Without Approval Actually Works

The shift from “approval authority” to “standard-setting authority” is subtle but important.

Approval means: “We get to decide if you can do this.” You’re slowing down the organization.

Standards means: “Here are the constraints. Meet them, and you’re free to move.” You’re enabling the organization.

The centralized company is doing approval. The distributed company is ignoring standards. Neither is working.

What works is: clear standards that business units must meet, clear authority for business units to decide how to meet them, and clear verification that they’re actually meeting them.

Here’s what this looks like in practice:

A business unit wants to build a pricing model. The standards say: “If you use AI for pricing decisions, you need to: – Document the data sources and any known biases – Verify that recommendations don’t systematically harm specific customer segments – Have a manual override process for edge cases – Monitor recommendation outcomes against actual pricing decisions – Review outcomes quarterly with your business leader and the standards team”

The business unit says: “We’ll do all that.” Great. They don’t need approval. They can start building.

Six months later, they’re in production. The standards team reviews: “Are they actually documenting data? Are they actually monitoring outcomes? Are they actually doing quarterly reviews?” Yes? Great. No? Then you have a conversation about what’s getting in the way.

The business unit didn’t get held up by approval. They also didn’t go rogue. They built to standards.

The Scaling Problem

The reason this matters is that your company is going to deploy AI across every business unit. Not maybe. It’s happening.

If you centralize, you’ll be the slowest company in your industry because you’re approving every experiment, every iteration, every new use case. Your competitors will be 10x ahead of you.

If you decentralize without standards, you’ll have governance risk in every unit, security risk in most of them, and regulatory exposure enterprise-wide.

The middle path is: clear standards, distributed authority, shared verification.

This requires:

1. Someone owns the standards. Not approves. Owns. Writes them. Updates them based on experience. Makes sure they’re actually good standards, not theater standards.

2. Business units have clear authority. They decide to use AI. They decide how to meet the standards. They move fast. They’re not waiting for approval.

3. Verification is real. Someone’s actually checking if the standards are being met. Not by reviewing documents. By checking outcomes, talking to teams, monitoring in production.

4. Escalation is clear. If a business unit can’t meet a standard, there’s a clear escalation. Not “you’re blocked.” But “here’s the constraint, let’s figure out how to address it.”

The Mistake That Kills This Approach

Most companies can’t do this because they try to start with standards that are too prescriptive.

They say: “All AI systems must use approved models.”

That’s not a standard. That’s an approval requirement hidden in standard language. And business units will either ignore it or spend six months trying to get a model approved.

Real standards look like:

• “All AI systems must have a documented rationale for the data sources.”
• “All AI systems used for consequential decisions must have outcome monitoring.”
• “All AI systems must have a person accountable for outcomes.”
• “All AI systems must have an escalation process if they start making decisions outside their training distribution.”

These are standards that you can verify. They’re not gatekeeping. They’re clarifying what good looks like.

The Organizational Structure That Enables This

You don’t necessarily need to reorganize. But you need clarity about authority:

Business unit leaders decide what problems to solve with AI. They have authority. They move fast.

A shared standards function (could be central AI team, could be part of Risk, could be part of Architecture) owns standards, not approvals. They set expectations. They verify. They escalate when needed.

An audit or verification function checks that standards are actually being met. This could be internal audit, compliance, or a dedicated team.

Escalation authority (could be CTO, CRO, business leader, doesn’t matter who) is clear. When a standard conflicts with a business need, there’s a clear path to resolve it.

This looks different from a pure centralization or pure decentralization. It’s designed for the actual constraint: you need speed and consistency simultaneously.

What You Should Do Monday Morning

If your company has a centralization-decentralization argument going, the question to ask is: “What are we actually optimizing for?”

If the answer is “we want to move fast,” decentralization feels right until you hit risk problems.

If the answer is “we want to manage risk,” centralization feels right until you slow down the business.

If the answer is “we want to move fast AND manage risk,” then the answer isn’t about where to put the team. It’s about where to put the authority.

Ask your leadership: “Where is authority for AI decisions in our company? Is it business units? Is it the central team? Is it clear?”

If you can’t answer in a sentence, you have a structural problem.

The companies that are scaling AI aren’t solving this with better committees or more governance layers. They’re solving it by being clear about where decisions are made and why.

Centralize authority where you need consistency. Decentralize authority where you need speed. But be explicit about where each one lives.