Distributed AI Development: Strategy or Drift?

In large organizations, AI development tends to split across two levels at once: strategy teams build roadmaps while business units roll out their own solutions at their own pace. Neither level is doing anything wrong – but few organizations can say with confidence whether that split reflects a deliberate choice or simply the fact that no one has decided anything at all.

That pattern has come up repeatedly this year, in conversations with people at large organizations. Last spring I worked with a global company built from several business units, each developing its own AI solutions on its own timeline and with its own resources – competently and sensibly. Still, no one seemed to hold the full picture of what other units were doing.

The distinction can sound academic. It isn't. In the first case, distribution is a strategy with a purpose, and someone tracks whether it's working. In the second, it's a byproduct of organizational structure that gets a justification invented after the fact.

Distribution Can Be an Excellent Choice

There's a strong case for distribution. Parallel, independent experiments produce a wider range of solutions than a single, centrally managed program. When each unit gets to experiment its own way, the organization learns faster which approaches work in which context, and it isn't dependent on one team's judgment.

This isn't a new idea. James March described the tension between exploration and exploitation in organizational learning back in 1991: standardize too early, and the organization locks itself into whatever solution happened to be found first. In an environment that changes as fast as AI does, the argument carries particular weight, because what counted as best practice a year ago may no longer be true today.

Practice bears this out too. In McKinsey's survey data, organizations most often report a hybrid model or partial centralization, where some resources are managed centrally and others sit with individual functions and business units. A pure version of either extreme is rare.

If distribution is a deliberate choice and gets even light coordination, it's a defensible model.

When It Isn't a Strategy

My suspicion is that in many organizations, distribution isn't a decision at all, but a consequence. Each unit owns its own subject area, its own budget, its own decisions. No one holds a role whose job is to see every AI initiative underway at the same time.

There's a fairly simple test for this: can you name the mechanism that maintains an overview of your organization's AI experiments? If you can't, distribution probably isn't a deliberate choice. It's drift.

This isn't a marginal concern. McKinsey's own guidance on the distributed model states that a central team needs to maintain visibility into what's being built, to avoid blind spots and stop two teams from building the same thing twice. Distribution, in other words, is recommended together with some form of visibility mechanism, never without one.

Two Consequences, Two Sizes

Without that mechanism, the consequences come in two sizes.

The first is wasted resources. When two units build similar solutions without knowing about each other, the work gets done twice and neither team learns from the other. That's unfortunate, but fixable. It just takes someone with the full picture to spot the overlap and connect the two projects.

The second is considerably larger, and improving efficiency won't fix it. A couple of years ago I wrote a series on the AI capabilities that can build long-term competitive advantage, among them multi-modal data processing, automation, and reasoning. None of those capabilities stay within any single unit's territory. They cut across the whole organization.

In practice, this means the most valuable applications can sit precisely between units. One unit's customer data, combined with another's process expertise and a third's market insight, is a combination none of the three can see on its own. Not because it doesn't exist, but because no one is positioned to see it.

Solving the first problem improves competitiveness. Solving the second can produce competitive advantage. They aren't the same thing, and they don't get solved the same way.

The Interfaces Have No Owner

This shows up in a concrete form as soon as any function starts planning how to use AI in its own processes.

The question often reaches beyond that function's own processes. It depends on information another function produces, and its own output feeds a third. Each function, taken on its own, is well organized, with an owner, defined processes, and clear responsibilities. What happens in the information flows between functions is a different matter; ownership there is usually much less clear.

AI doesn't consult the org chart, though. An agent built at the end of the chain inherits every problem in the information flow that came before it, including the ones at the interfaces where data changes hands and no one is clearly responsible for its quality. An agent is only ever as good as the weakest interface upstream of it.

No better language model fixes that, and neither does optimizing one function at a time.

Why a Light Mechanism Doesn't Emerge on Its Own

At this point, the fix looks easy. A regular, lightweight review. A shared register of active initiatives. One person whose job is to hold the overview without owning any individual project. None of this is expensive.

If the fixes are this light, the question is why they don't happen on their own. The reason probably isn't that no one sees the value of an overview. It's that maintaining one clearly belongs to no one.

A more likely explanation lies in organizational structure and incentives. A unit leader is measured on that unit's results, so attention naturally goes to the problems within their own remit. Without a shared forum, practice, or responsibility for sharing information, an experiment that might be useful elsewhere tends to stay local, not because anyone wants to keep it quiet, but because nothing actually points them toward telling anyone.

On top of that, the benefits of sharing usually land somewhere other than the unit that spends the time documenting its own experience. For the organization, that sharing pays off. For a single unit, it's easy to see as one more task competing for attention.

The overview benefits the whole organization, but the time it takes to maintain it comes out of individual units. Without a deliberate mechanism, it's entirely rational for information sharing to lose out to more urgent local goals.

The same logic shows up in what actually makes it into the register. An experiment still in progress rarely gets added, because it doesn't yet feel worth reporting. Yet it's often exactly the unfinished and failed experiments that produce the most useful learning for the organization: what didn't work, in what context, and why.

The root cause is the same as at the interfaces: responsibility and metrics usually stop at the edge of one's own unit.

What Kind of Mechanism Gets Past Local Optimization

There's no need to invent this from scratch. In many organizations, the equivalent role already has a name: an AI center of excellence, or a hub-and-spoke model, where a small central team maintains visibility and provides shared resources while the actual development work stays in the business units. The same structure appears in the McKinsey guidance on managing a distributed model mentioned earlier. This isn't a heavy new initiative. It's naming and resourcing something that already exists in practice.

It appears, though, that coordination rarely fails for lack of tools. It fails because using them isn't part of anyone's normal job or targets. The real design question isn't what the mechanism should look like. It's why a unit would bother using it.

A few possible answers. Measure the coordinating role's success by how many connections it helps surface, not by how many projects it signs off on. Route shared resources, expertise, and agreements through the mechanism, so that taking part pays for itself and doesn't need to be mandated. And make reporting a failed experiment give the unit something back, rather than costing it something.

A working mechanism, then, doesn't just collect information from units. It has to give something useful back: expertise, ready-made solutions, benchmarks, or access to shared resources.

The risk sits right in that metric. The more coordination starts to resemble an approval process, the further it drifts from its own definition of success, and the greater the risk that visibility declines. That doesn't require dishonesty from anyone. Just rational behavior.

The real trap is subtler than simple drift, though: it comes from success itself. Once a light coordinating role proves useful, it becomes tempting to expand its mandate, budget, and authority, and that expansion is exactly what can pull it toward the approval process warned about above. The mechanism can turn into precisely the bottleneck that distribution was meant to avoid in the first place: a central gatekeeper whose sign-off every initiative needs. The way to guard against this is to keep the same metric in place after the role has grown, too: the number of connections made, not the number of approvals granted. Change the metric, and the model has turned against itself.

Capability Alone Isn't Enough

I wrote earlier about the Harvard and Wharton field experiment at P&G, where both commercial and technical specialists produced more balanced solutions when using AI, regardless of their background. Without AI, product-development specialists tended to propose more technical solutions and commercial specialists more commercially oriented ones.

The same dynamic seems to repeat at the organizational level, just at a larger scale. AI can help individuals and teams think past the edges of their own expertise. It doesn't happen as easily across the boundaries between units, because what holds those boundaries in place isn't a lack of skill. It's ownership, responsibility, and metrics.

That may be the single most important thing missing from my series two years ago. I listed capabilities as if they were simply there for the organization to use. In reality, organizational structure sits between a capability and its use, and that structure is what decides whether the most valuable opportunities ever become visible at all.

Conclusion

Long-term competitive advantage may depend less on which AI capabilities an organization adopts, and more on whether that organization can see itself clearly enough, as a whole, to recognize where those capabilities would create the most value.

It's an organizational question more than a technological one.

How does your organization maintain an overview of the AI initiatives currently under way, and is your distribution a deliberate choice or a byproduct of structure? And who's looking for the opportunities that fall between units?

-- -- -- -- -- -- -- -- -- --

Sources

• Dell'Acqua, Ayoubi, Lifshitz, Sadun, Mollick ym. (2025): The Cybernetic Teammate: A Field Experiment on Generative AI Reshaping Teamwork and Expertise. NBER Working Paper 33641.
• McKinsey (2025): The state of AI: How organizations are rewiring to capture value.
• McKinsey (2024): A data leader's operating guide to scaling gen AI.
• March, J. G. (1991): Exploration and Exploitation in Organizational Learning. Organization Science 2(1), 71–87.

Previous four-part series, "Leveraging AI in Business: From Competitiveness to Competitive Advantage":

• Part 1/4: Competitiveness and Competitive Advantage with AI
• Part 2/4: Leveraging AI for Competitiveness - Long-term perspective
• Part 3/4: Unlocking Short-Term AI-Driven Competitive Edges
• Part 4/4: Building Long-Term AI-Driven Competitive Advantage

As well as my earlier piece: Can AI Break Down Expertise Silos?

Related Insights

6/11/2026•AI

The Second AI Investment: Systems, Not Models

Most organisations have made their first AI investment. The second, building reliable systems around models, is where the real work begins.

Marko PaananenRead more →

6/3/2026•AI

AI's value moved from models to workflows - where organisations should focus

The bottleneck in AI is no longer model capability but workflow judgment. Organisations must identify where repeated decisions slow the business down.

Marko PaananenRead more →

5/28/2026•AI

The approval layer in AI agents - permanent architecture

Reliability has overtaken autonomy in AI agent design. The approval layer is no longer a temporary fix — it may be the permanent architecture of successful AI systems.

Marko PaananenRead more →