Operating Model, Talent, and Adoption

An enterprise can deploy the best foundation model available and still produce near-zero P&L impact if the organisational structure routes AI capability to the wrong places, creates accountability vacuums, or generates friction between central AI teams and business units.

The structural question — how to organise the AI function — is not a technology question. It is a governance and incentive question. The three dominant archetypes (centralised, federated, hub-and-spoke) make different tradeoffs between consistency, speed, and business-unit ownership. None is universally correct. The right choice depends on the firm's existing data architecture, the maturity of its AI talent, and how tightly coupled its business units are. Getting this wrong wastes 12–18 months of organisational energy before anyone admits the structure isn't working.

The following table summarises the dominant structural patterns and their real-world tradeoffs:

| Structure | Description | Strengths | Failure Modes | |---|---|---| | Centralised | One AI team owns all models, infrastructure, and deployment | Consistency, reuse, strong governance | Slow to business units; perceived as ivory tower; bottleneck at scale | | Federated | Each business unit owns its own AI capability | Fast to market; deep domain context | Fragmented tools, duplicated costs, inconsistent risk practices | | Hub-and-spoke | Central platform team (infra, governance, shared models) + embedded AI leads in each BU | Balances speed and consistency | Requires strong coordination; hub can become gatekeeper; spoke roles are hard to hire and retain |

Most large enterprises that have scaled AI beyond the pilot phase have converged on some variant of hub-and-spoke, for the same reason that cloud infrastructure teams converged on platform engineering: shared infrastructure with distributed ownership. The failure mode to watch for in hub-and-spoke is the hub becoming a bottleneck that negates the advantages of the spokes.

A practical signal: if business-unit teams are hiring their own "shadow AI" capability alongside the official AI team, the centralised or hub model is failing on speed.

The build-vs-buy question in enterprise AI is rarely binary. The relevant axis is: where in the stack does proprietary advantage live?

Buy (or use API/SaaS) when:

• The capability is not a source of competitive differentiation (e.g., document summarisation, meeting transcription).
• The vendor's model will improve faster than your internal team could match.
• The integration surface is manageable (API call, not deep system rewiring).
• Data privacy and regulatory constraints can be met through contracts and configuration.

Build when:

• The use case requires proprietary data that cannot leave the firm's perimeter.
• The model's output quality on your specific task is materially better with fine-tuning or specialised architecture.
• You are in a regulated environment where model auditability is required and vendor black boxes are non-compliant.
• The capability is a genuine moat — a differentiated workflow that competitors cannot replicate by subscribing to the same vendor.

The most common mistake is building when buying would serve — motivated by engineering pride or a vague sense that "owning the model" is strategically important. The second most common mistake is buying in a domain where the firm's data is the actual asset, and handing that data to a vendor erodes the advantage.

A useful forcing question: if our competitor subscribes to the same API tomorrow, does this AI initiative still create value?

The AI talent market in 2024–25 is characterised by severe scarcity at the top (frontier ML researchers, RL specialists) and rapidly commoditising supply in the middle (prompt engineers, RAG developers using off-the-shelf frameworks). For most enterprises, the talent strategy should not be competing for the scarce top tier — it should be building a broad base of AI-literate operators while contracting for specialist depth.

What the evidence suggests about reskilling:

• The BCG/Harvard jagged-frontier study found that consultants who over-trusted AI on out-of-frontier tasks performed worse than those with no AI access. Effective reskilling is not just "how to use the tool" — it is calibration: knowing when the tool is likely to be wrong.
• The METR (2025) perception gap finding — developers believed AI had sped them up while it had actually slowed them down — shows that self-reported learning is an unreliable signal. Effective reskilling programs include measurement, not just training.
• Microsoft's internal surveys (cited in their AI transformation communications, 2024) suggest that the employees who gain most from AI tools are those who restructure their workflows around AI, not those who add AI as an optional step on top of existing processes.

Reskilling programs that focus purely on tool proficiency without workflow redesign will underperform.

The dominant failure mode in enterprise AI programs is not model quality. It is adoption — specifically, the gap between deployment and genuine workflow integration.

A well-documented pattern in enterprise software adoption (documented in ERP and CRM rollout literature, and now repeating in AI) is the adoption valley: initial enthusiasm, followed by a dip as users encounter friction, followed by either sustained use if the friction is resolved, or quiet abandonment.

For AI tools specifically, the adoption valley is deepened by three factors:

1. Trust calibration takes time. Users who get one bad AI output early tend to disengage. Users who are given calibration guidance ("this tool is reliable for X, unreliable for Y") adopt more sustainably.
2. Workflow disruption is real cost. Adding an AI step to an existing workflow creates friction before creating value. Users weigh this cost against the perceived benefit, and in the early weeks, the cost often wins.
3. Incentives may not align. If a team's performance metrics reward output volume, and AI initially slows them down (see METR), there is a rational case to avoid it. Adoption requires realigning metrics or reducing the friction enough that the value appears before the incentive clock runs out.

Organisations that treat AI deployment as a technology launch — announce, train, ship, monitor usage metrics — typically get adoption spike followed by cliff.

Why AI tool adoption dips before it rises — and where to intervene.

The productivity paradox pattern (Brynjolfsson 1993, revisited in the MIT 2025 GenAI Divide analysis) is clear: technology deployments that do not change workflows do not change outcomes. The PC did not improve white-collar productivity until firms redesigned processes around it — which took roughly a decade.

For AI, the workflow redesign principle has a specific implication: AI should change what tasks people do, not just how fast they do the old tasks. A customer-support team that uses AI to answer tickets 20% faster, but still answers the same types of tickets in the same sequence, captures speed gains. A team that uses AI to pre-classify and route tickets, enabling agents to focus only on complex escalations, captures a structural cost and quality improvement.

The second case requires redesigning the workflow — rethinking roles, decision rights, and metrics. It takes longer. It requires management sponsorship. It encounters resistance. It is also the only path to the P&L outcomes that survive a measurement audit. The first case shows up well in 30-day adoption dashboards and disappears in 12-month business-unit P&L reviews.

Adoption is an incentive problem as much as a technology problem. The incentive misalignments that kill AI adoption are predictable:

• Teams measured on throughput will resist tools that slow them down initially, even if long-run productivity is higher.
• Teams whose performance reviews don't include quality metrics have no incentive to use AI for quality improvement rather than speed gaming.
• Middle managers whose headcount determines their status will resist AI-driven efficiency improvements that reduce their team size.
• Frontline workers who believe AI is auditing their performance will use it strategically to look compliant rather than to improve work.

None of these problems are solved by a better model. They are solved by explicit incentive redesign — and by leaders who are honest that AI adoption may require uncomfortable changes to how teams are measured and how managers are rewarded.

The practical implication: before launching an AI program, map the existing incentive structure and identify which incentives create rational resistance. Address those explicitly in the change-management plan, not in the technology rollout plan.

Synthesising across the structural, talent, and adoption dimensions:

Structure: Hub-and-spoke is the modal best practice for enterprises >5,000 employees. Central platform team owns infrastructure, governance standards, model access, and shared tooling. Embedded AI leads in each BU own use-case prioritisation, data sourcing, and adoption management.

Talent: Hire for AI-literate domain experts, not just AI specialists. A supply-chain AI lead who understands both ML and logistics is more valuable than a pure ML researcher who doesn't know what a bill of lading is. Calibration training is more important than tool-usage training.

Adoption: Treat adoption as a change-management program with its own budget, success metrics, and leadership accountability — not as a feature of the technology rollout. Measure workflow change, not just login rates.

Incentives: Explicitly redesign the metrics that govern the teams and managers in scope. The AI program's success depends on those metrics more than on the model.

Measurement: Every AI initiative needs a pre-committed P&L-adjacent metric, a counterfactual design, and a kill criterion. Operating model decisions that cannot be connected to a measurement plan are hypotheses, not strategies.