Erik Caldwell
Connect on LinkedIn
Menu

The Topic Catalog · 1

Enterprise AI Strategy & Operating Model

Last updated · 9 min read

1.1 AI Operating Models: Centralized vs Federated vs Hub-and-Spoke (incl. Center of Excellence)

Priority: Must Understand

Executive Definition: An AI operating model defines who builds AI capability, who decides what gets funded, and who is accountable when something breaks. Centralized means one team owns AI end-to-end; federated means each business unit builds its own with light shared standards; hub-and-spoke (the most common enterprise pattern) puts a central team in charge of platform, governance, and hard problems while embedded "spoke" practitioners sit inside product teams and ship. A Center of Excellence (CoE) is the hub in that pattern, not a synonym for the whole model.

Why It Matters: At meaningful organizational scale, the wrong model produces either duplicated tooling and inconsistent risk controls (pure federation) or a bottlenecked hub that business units route around with shadow AI (pure centralization). DORA's 2025 research found platform investment is a prerequisite for AI value capture (90% of high-performing organizations had adopted an internal platform before AI paid off) which is effectively an argument for a hub that owns platform and guardrails regardless of how build work is federated.

What I Need to Understand:

  • The distinction between owning the platform/guardrails (hub) vs. owning delivery (spoke): most real deployments split these, they aren't mutually exclusive
  • Where governance, model access, security review, and cost controls sit vs. where use-case selection and build work sit
  • How the model changes as adoption matures (early: centralize to move fast and control risk; later: federate delivery once guardrails are proven)
  • The failure modes of each: centralized = bottleneck and shadow AI; federated = duplicated spend, inconsistent risk posture, no shared learning; hub-and-spoke = unclear accountability if the split isn't explicit
  • How this interacts with your existing platform engineering org: a new "AI CoE" that duplicates platform engineering's job is a red flag

Questions I Should Be Able to Ask My Team:

  1. When two business units want conflicting model configurations or exceptions to our guardrails, who has the authority to say no, and has that ever actually happened?
  2. What decisions does the central AI team make versus what decisions do product teams make on their own: can you show me the line, not just describe it?
  3. If we shut down the central AI team tomorrow, what would silently break, and what would nobody notice was gone?

Technologies / Standards / Companies to Know: Team Topologies (platform team / stream-aligned team vocabulary), DORA AI Capabilities Model, internal developer platforms (Backstage, Port).

Recommended Learning:

Time Investment: 2-3 hours

1.2 AI Portfolio Management, Use-Case Prioritization & Build vs Buy vs Configure

Priority: Must Understand

Executive Definition: Portfolio management is treating your AI initiatives as a funded, prioritized set of bets rather than a scattered list of pilots: with the same rigor you'd apply to a product or capital portfolio. Build vs. buy vs. configure is the decision, per use case, between building custom (highest cost/control), buying a vendor product (fastest, least differentiated), or configuring a platform/agent framework around your data (the now-common middle path).

Why It Matters: McKinsey's 2025 global survey found only 39% of organizations attribute any measurable EBIT impact to AI and just 6% qualify as "high performers" (5%+ EBIT impact): the gap is overwhelmingly a portfolio-discipline problem, not a technology problem: too many low-value pilots, unclear ownership, no kill criteria. The same survey found coding agents are shifting the calculus: 32% of respondents report forgoing a software purchase because an internal team could build it with AI assistance: inflating the "build" option's apparent attractiveness in ways that need scrutiny (build still carries maintenance, security, and model-drift costs a vendor absorbs).

What I Need to Understand:

  • The difference between a pilot (proof of concept, no production commitment) and a scaled deployment, and what percentage of your pilots are actually converting
  • A defensible scoring framework for use cases: value (revenue, cost, risk reduction) against feasibility (data readiness, integration complexity, change-management load): and that no single framework is industry-standard
  • Why "buy" often wins even when "build" looks cheaper up front: ongoing model updates, security patching, and support are recurring costs a vendor amortizes across many customers
  • What "configure" actually means for agentic systems: buying a platform (e.g., an agent framework or Copilot-style product) and building thin business logic on top, versus building the whole stack
  • Kill criteria: what causes you to sunset a pilot, and whether anyone currently owns that decision

Questions I Should Be Able to Ask My Team:

  1. Of our current AI initiatives, how many have an assigned business owner accountable for a measured outcome, versus how many are "IT is running a pilot"?
  2. For this build-vs-buy decision, what's the fully loaded 3-year cost of building (including model updates, security review, and the engineer-hours to maintain it) not just the initial build estimate?
  3. Which of our current pilots have we killed in the last two quarters, and why did we kill them?

Technologies / Standards / Companies to Know: McKinsey/BCG/Bain AI value-tracking research (treat as industry survey data, not standards), internal AI platforms (Backstage-style catalogs), vendor agent platforms (Microsoft Copilot Studio, Salesforce Agentforce, ServiceNow AI Agents) as reference points for "configure."

Recommended Learning:

Time Investment: 2-3 hours

1.3 Multi-Model Strategy & Vendor Dependency

Priority: Must Understand

Executive Definition: A multi-model strategy means your organization's AI systems can run on more than one foundation model provider (e.g., Anthropic, OpenAI, Google) without a full rebuild: achieved through abstraction layers, model routing, and portable interfaces like the Model Context Protocol (MCP). The alternative is single-vendor dependency: faster to start, but it concentrates pricing power, outage risk, and roadmap risk in one company's hands.

Why It Matters: Model quality, price, and capability leadership have changed hands repeatedly across Anthropic, OpenAI, and Google over the past two years, and that volatility is a documented pattern, not a one-off: locking your architecture to one model's API means re-architecting every time the leaderboard shifts or a vendor changes pricing or terms. At the same time, genuine multi-model portability has real engineering cost (prompt behavior, tool-calling conventions, and safety behavior differ across models), so "multi-model everywhere" is itself a cost decision, not a free hedge.

What I Need to Understand:

  • Where in your architecture model choice is actually abstracted (a routing/gateway layer) versus where it's hard-coded into application logic: most enterprises overstate their real portability
  • The Model Context Protocol (MCP), an open standard originated by Anthropic in late 2024 and since adopted by OpenAI, Google, Microsoft, and others for connecting models to tools and data: the closest thing to an interoperability standard this space has, though it is barely two years old and still evolving
  • Supply-chain risk in the LLM sense: OWASP's LLM Top 10 flags "Supply Chain" (LLM03) as a top-tier risk category, covering third-party model, plugin, and data dependencies
  • The real cost of multi-model: different models have different tool-calling behavior, safety refusal patterns, and prompt sensitivity: testing and maintaining behavior parity across models is nontrivial ongoing work, not a one-time integration
  • When single-vendor is actually the right call (regulated data residency, a specific model's capability lead on your workload) versus when it's just inertia

Questions I Should Be Able to Ask My Team:

  1. If our primary model provider raised prices 40% tomorrow or had a multi-day outage, what would happen to our production systems, and how long would switching actually take?
  2. Where does model choice live in our codebase: is it a config value or is it baked into prompts and business logic across dozens of services?
  3. Are we paying the ongoing cost of testing multiple models for behavioral parity, or did we buy "multi-model support" from a gateway vendor and never actually validate it?

Technologies / Standards / Companies to Know: Model Context Protocol (MCP), OWASP Top 10 for LLM Applications, model gateway/router products (e.g., LiteLLM, Portkey, cloud-native model gateways from AWS/Azure/GCP), Anthropic, OpenAI, Google DeepMind, Meta.

Recommended Learning:

Time Investment: 2-3 hours

1.4 AI Maturity Models & Transformation Governance

Priority: Should Understand

Executive Definition: An AI maturity model is a staged framework (typically 4-5 levels, from ad hoc experimentation to fully governed, scaled deployment) used to assess how far an organization's AI capability has actually progressed, as distinct from how much it has spent or piloted. Transformation governance is the decision-rights and oversight structure (steering committees, risk gates, funding reviews) that moves an organization through those stages deliberately rather than by accident.

Why It Matters: McKinsey's 2025 survey data (37% attributing any EBIT impact to AI, only 6% "high performers") is itself evidence that most enterprises are stalled at pilot maturity regardless of spend: maturity models exist precisely to diagnose why, since the blockers at each stage (data readiness, then talent, then process redesign, then governance) are different problems requiring different interventions. Treat any single vendor's maturity model as a diagnostic lens, not a certification: there is no ISO or NIST-equivalent standard for "AI maturity" the way there is for, say, information security (the ISO/IEC 27001 standard, jointly published by the International Organization for Standardization and the International Electrotechnical Commission (IEC)).

What I Need to Understand:

  • No maturity model is neutral: most are published by consultancies or vendors selling the services to move you up their own ladder; use them to structure a conversation, not as an external audit
  • The common stage pattern across most models: (1) experimentation/pilots, (2) scaled pockets, (3) integrated into core processes, (4) governed and measured enterprise-wide, and that most organizations, including sophisticated ones, sit at stage 1-2
  • Governance maturity is a distinct axis from technical maturity: an org can have advanced models in production with no risk review process, which is its own red flag (see Acceptable Use Policies topic)
  • What "transformation governance" should concretely produce: a funding gate, a risk/security review gate, and a measurement standard applied consistently across initiatives: not a steering committee that meets and produces no decisions

Questions I Should Be Able to Ask My Team:

  1. Which specific gate did our last three AI initiatives fail to clear before reaching production, and did any actually get stopped, or does everything eventually ship?
  2. If you had to justify our maturity stage using only evidence (production usage numbers, measured outcomes, governance artifacts) not intentions, what would you point to?
  3. Who besides IT/engineering sits on our AI governance body, and what's the last decision they actually made that changed a project's direction?

Technologies / Standards / Companies to Know: ISO/IEC 42001 (AI management systems: the closest thing to a certifiable standard in this space), NIST AI Risk Management Framework (RMF) (risk-focused, not maturity-staged, but the closest US government reference), McKinsey/Gartner maturity frameworks (useful, vendor-authored).

Recommended Learning:

Time Investment: 1 hour