Enterprise AI platform operating models

Research Question

What organisational structures do enterprises use to operate multiple Artificial Intelligence (AI) platforms simultaneously, and what trade-offs emerge between (a) a single unified AI platform team, (b) a split by target customer base (business users vs developers), and (c) a split by underlying technology stack (Microsoft 365 (M365) vs Amazon Web Services (AWS)), including implications from explore vs exploit operating modes and Conway's Law?

Findings

(Populated from section 6 Synthesis above.)

Executive Summary

• Enterprises that must operate multiple AI platforms in parallel should usually adopt a hybrid hub-and-spoke model, meaning a central platform hub serving user-facing teams through shared services and enablement patterns, with one central AI platform and governance hub and customer-facing ownership split by user segment only where needs materially diverge.
• A single unified team is the best starting point when AI demand is immature and specialist talent is scarce, but it becomes a bottleneck if it keeps owning both the shared platform core and every downstream use case.
• Splitting by target customer base is usually healthier than splitting by M365 versus AWS because customer-segment boundaries preserve a shared control plane, while vendor-stack boundaries tend to duplicate controls and then harden those seams into the architecture.
• Explore work should sit in a thin enabling or incubation function near the hub, while exploit work should run on standardised shared rails with explicit governance, observability, and human-review rules.

Key Findings

1. High confidence. Most enterprises should organise multiple AI platforms around one central control plane, using Capital One's term for the central configuration, access, evaluation, observability, and policy layer, then expose separate products to users only where needs diverge materially.
2. High confidence. A single unified platform team is strongest in the early stage because it concentrates scarce talent and standards, but it degrades into a slow intake queue if it continues owning every downstream use case after demand scales.
3. Medium confidence. A split by target customer base often becomes the best scaling move because business users and developers need different workflows, support models, and product metrics even when they share one governed platform core.
4. Medium confidence. A primary split by M365 versus AWS is usually a weak default because it causes the organisation to duplicate policy, identity, retrieval, and support mechanisms, and then hardens those vendor seams into the architecture.
5. High confidence. Explore activity should be owned by a small enabling or incubation function near the hub so that experiments with models, vendors, and evaluation methods can be productised once rather than rediscovered in parallel.
6. High confidence. Financial-services firms have stronger reasons than most sectors to centralise governance, approved patterns, and accountability, while decentralising only workflow configuration and user support that must stay close to the business.
7. High confidence. The cleanest decision-rights split is central ownership of policy, vendor approval, data-access guardrails, observability, shared tooling, and cost attribution, with spoke ownership of prioritisation, integration, adoption, and benefit realisation.
8. High confidence. The most consistent anti-patterns are a permanent central team that owns all delivery, federated teams launched before a shared platform exists, and vendor-aligned teams that mirror suppliers instead of user journeys.

Assumptions

• Assumption: There is enough overlap across M365 and AWS control requirements that one shared governance and platform core is economically meaningful. Justification: if legal, residency, or customer separation is extreme, stronger structural separation could be warranted.
• Assumption: The enterprise has at least two distinct AI customer groups, business users and developers, whose workflow needs are meaningfully different. Justification: without that divergence, a customer-segment split may add cost without enough benefit.
• Assumption: Public bank disclosures describe governance and platform patterns more often than exact team charts, so some operating-model conclusions are inferential rather than diagram-level factual. Justification: the public evidence is richer on principles and controls than on reporting lines and headcount.

Analysis

• The evidence was weighted toward sources that describe operating responsibilities directly, not toward generic strategy commentary, which made Team Topologies, AWS, Google Cloud, and bank disclosures more important than consultancy narratives.
• The strongest pattern across sources is central ownership of the reusable platform core plus local ownership of the workflow edge, so competing interpretations that favour either total centralisation or unmanaged federation were rejected as weaker fits to the evidence.
• The main trade-off is between governance efficiency and local responsiveness, and the best way to manage that trade-off is to centralise the control plane while letting customer-facing teams optimise the experience for their user segment.
• Financial-services evidence was given additional weight because the sector's governance requirements are stricter and therefore expose accountability needs that more lightly regulated sectors can ignore for longer.

Risks, Gaps, and Uncertainties

• The official MAS FEAT page was inaccessible from this environment, so MAS-specific governance content was checked for accessibility but not used as primary evidence.
• Public enterprise disclosures describe principles and controls more often than exact reporting lines, so precise org-chart recommendations remain partly inferential.
• The recommendation against stack-splitting is strong but still inferential because there is no public controlled comparison of vendor-aligned and customer-aligned AI platform organisations.
• The conclusion could change in an enterprise where M365 and AWS are separated by law, geography, or customer base strongly enough that shared governance and shared services are no longer economical.

Open Questions

• What funding and chargeback model best supports a central AI hub without recreating a slow approval bureaucracy?
• Which AI decisions in financial services should always remain with central risk and architecture functions, and which can safely be delegated under pre-approved guardrails?
• What leading indicators show that a unified team has reached the point where a customer-segment split is justified?

sources

Starting points - papers, articles, videos, repos, docs.

• [x] Team Topologies key concepts — - replacement for the seeded Team Topologies platform-team URL, which returned 404 in this environment; used for platform teams, enabling teams, interaction modes, and cognitive load.
• [x] DevOps Research and Assessment (DORA) research program — - research archive and core model.
• [x] 2025 DORA report overview — - current evidence on AI-assisted software development, internal platforms, and workflow quality.
• [x] AWS Prescriptive Guidance: building a Cloud Center of Excellence (CCoE) — - replacement for the seeded AWS whitepaper URL, which has moved.
• [x] Google Cloud: Designing cloud teams — - replacement for the seeded Google Cloud Center of Excellence URL, which returned 404 in this environment.
• [x] Conway's Law — - original statement of the organisational-design principle.
• [x] Bank of England, Prudential Regulation Authority (PRA), and Financial Conduct Authority (FCA) DP5/22 — - governance and accountability questions for AI in financial services.
• [x] Monetary Authority of Singapore (MAS) FEAT page — - official page located, but blocked in this environment; checked for accessibility and recorded as inaccessible for downstream factual use.
• [x] DBS responsible AI in banking — - platform, process, people model for scaled bank AI.
• [x] DBS 2024 Chief Information Officer (CIO) statement — - operating details on resiliency, governance, and AI deployment.
• [x] Morgan Stanley OpenAI milestone — - controlled internal knowledge assistant for wealth management.
• [x] Morgan Stanley AI @ Morgan Stanley Debrief launch — - adoption and human-in-the-loop deployment pattern.
• [x] Capital One scalable data management for AI — - central control plane plus central and federated operating options.
• [x] Capital One "You Build, Your Data" — - self-service platform with central and federated deployment models.
• [x] Capital One generative AI transparency disclosure — - official disclosure on customised open-source Large Language Model (LLM) development.
• [x] J.P. Morgan on AI in payments — - board-level data governance and operating-model implications in financial services.
• [x] Enterprise AI capability model for use-case maturity decisions — - prior completed repository work on shared capability foundations.
• [x] Layered organisation Large Language Model architecture — - prior completed repository work on layered enterprise AI architecture.
• [x] The Software Factory — - prior completed repository work on internal platforms, bottlenecks, and operating-model redesign.
• [x] Exploit-explore AI portfolio framework — - prior completed repository work on separating exploratory and exploitative AI effort.