Overview

Dewi Santos is the Head of AI Transformation at a diversified conglomerate based in Manila with businesses spanning banking, retail, and food manufacturing. When the group's CEO asked her to "get AI working across all the businesses," Dewi's first problem was not technology. It was a structural one. Each business unit had its own IT team, its own data infrastructure, and its own priorities. The banking arm had three data scientists building models nobody outside the risk team could access. The retail unit had purchased an off-the-shelf AI demand-forecasting tool but had no one who understood it well enough to configure it correctly. The manufacturing arm was watching from the sidelines, waiting to see what the others did. "We had three different organizations trying to figure out AI," Dewi said. "None of them could learn from the others, and none of them were learning fast enough."

Why Structure Determines Speed

The decisions organizations make about where to place AI capabilities - who reports to whom, where technical talent sits, how resources are allocated, who has authority over AI decisions - determine how fast the organization can learn and how widely that learning spreads.

Technology alone does not create organizational capability. A brilliant AI team buried inside one business unit creates capability in that unit, invisible to the rest. A governance body with no technical capability creates policy without implementation. The structural arrangement of people, authority, and resources is the operating system that determines what the organization can actually do with AI.

Three organizational models dominate real-world deployments. Each has genuine strengths and real limitations. Most organizations do not cleanly fit one model - they need to understand all three to design a hybrid that fits their situation.

The Centralized Model

In a centralized model, AI capability lives in a single central function - typically under the Chief Data Officer, Chief Technology Officer, or a purpose-built AI Center of Excellence. Business units request support from the center. The center owns the talent, the tools, the standards, and the infrastructure.

What works well: Centralization prevents duplication. You build one data platform, not six. You maintain one set of standards. You develop talent in one place where people can learn from each other. For organizations early in their AI journey, or in heavily regulated industries where consistency across the enterprise is a compliance requirement, centralization creates the control necessary to move responsibly.

What breaks down: Centralized teams become bottlenecks. When every business unit's AI needs go through one team, that team cannot keep up. Business units experience the center as slow and disconnected from their real operational needs. The most capable people in the center often find that they are spending more time managing requests than doing interesting work, and they leave. Centralization scales poorly beyond the early stages of adoption.

The Decentralized Model

In a decentralized model, AI capability sits inside individual business units. Each unit builds its own team, selects its own tools, and pursues its own use cases. A small central function may exist for enterprise architecture standards and regulatory compliance, but operational AI work happens at the business unit level.

What works well: Business units move faster when they own their own capability. Technical staff develop deep domain knowledge - the retail team's data scientists learn retail, not just data science in the abstract. Use cases are closer to business problems. Experimentation is easier because approval chains are shorter.

What breaks down: Decentralization creates duplication and inconsistency. Five business units build five different data pipelines processing the same customer data. Security standards diverge. Compliance becomes difficult to enforce when AI practices vary across units. Knowledge is siloed - the breakthrough a data scientist in one unit achieved solving a problem that another unit is still struggling with never crosses the organizational boundary.

This was Dewi's situation. Three organizations trying to figure out AI, unable to learn from each other.

The Federated Model

The federated model - sometimes called the hub-and-spoke or Center of Excellence plus embedded model - tries to capture the benefits of both. A central hub provides shared infrastructure, standards, tooling, and specialized expertise. Embedded AI practitioners live inside business units, deeply familiar with business context, supported by and accountable to both their business unit and the hub.

What works well: Federated structures spread capability while maintaining consistency. Business units get dedicated technical support that understands their domain. The hub ensures that security, governance, and infrastructure standards apply everywhere. Knowledge flows in both directions: business unit learning informs the hub's understanding of real operational needs; hub learning in one area reaches all business units.

What requires careful design: Federated structures create reporting complexity. Who does an embedded data scientist report to? If they report only to the business unit, the hub's standards lose authority. If they report only to the hub, they become disconnected from business priorities. Most successful federated structures use a matrix: embedded practitioners have solid-line accountability to their business unit and dotted-line accountability to the hub - or the reverse, depending on the organization's priorities.

>
The right structure is not the most elegant one in theory. It is the one your organization can actually operate given its culture, its existing capabilities, and where it is in the AI maturity journey.

Centers of Excellence: What They Are and What They Are Not

A Center of Excellence - often called a CoE or AI CoE - is the most common vehicle for the hub in a federated model. Done well, a CoE does four things: it builds and maintains shared infrastructure (data platforms, model deployment environments, experimentation tooling), it develops and enforces enterprise standards (data governance, model risk management, security requirements), it provides specialized expertise that is inefficient to replicate in every business unit (machine learning research, advanced model development, regulatory compliance expertise), and it serves as a learning hub (capturing lessons from all business units and distributing them across the organization).

Done badly, a CoE becomes a monopoly that slows everything down, or a standards bureaucracy that creates friction without providing support. The failure modes are predictable: CoEs that are under-resourced cannot meet demand. CoEs that are over-powerful become gatekeepers rather than enablers. CoEs that lack strong business relationships produce technically excellent work that never gets adopted because it does not address actual business problems.

Dewi chose a federated model for her conglomerate. The center - a twelve-person team including infrastructure engineers, ML engineers, a legal and compliance specialist, and a change management lead - handles shared infrastructure and standards. Each major business unit has two to three embedded practitioners who report into their business unit but have a quarterly review with the center. In the first year, the retail unit's demand-forecasting breakthrough was adapted by the manufacturing arm within three months - something that never would have happened in the previous siloed structure.

Choosing the Right Model for Your Organization

Three questions help determine which model or hybrid best fits an organization at a given stage.

How mature is the organization's AI capability? Organizations early in their journey, with limited technical talent, typically need more centralization to build consistent capability before decentralizing. Organizations with established capability in multiple business units can sustain more decentralization.

How regulated is the industry? Financial services, healthcare, and regulated utilities typically need stronger central governance to ensure compliance consistency. Consumer-facing businesses with lower regulatory intensity can sustain more decentralization safely.

How interdependent are the business units? Conglomerates with largely independent businesses can decentralize more freely. Organizations where business units share customers, data, or processes need more central coordination to ensure consistent treatment across those shared elements.

Key Takeaways

• Structure determines learning speed. Where AI capability sits - and how it connects across the organization - determines how fast the organization can learn and whether that learning spreads.
  - Centralized models work early, break later. Centralization creates consistency and prevents duplication, but becomes a bottleneck as demand scales across the organization.
  - Decentralized models move fast but silo knowledge. Business unit ownership drives speed and domain fit, but creates duplication, inconsistency, and walls between units that could be learning from each other.
  - Federated models capture both benefits, but require careful design. A central hub for infrastructure, standards, and specialized expertise combined with embedded practitioners in business units is the most mature model - if reporting relationships and authority are clearly defined.
  - Centers of Excellence are enablers, not gatekeepers. A CoE that creates friction rather than capability is a structural failure, not an AI failure. Design for support, not control.
  - Choose based on maturity, regulation, and interdependence. The right model depends on where the organization is, what the regulatory environment requires, and how much business units share customers or data.
  - Structure is not permanent. Organizations evolve from more centralized to more federated as capability builds. Expect to revisit the structural model every two to three years.