Enterprise AI Strategy: A Portfolio of Strategies, Not One Document

A bank I worked with in 2024 spent four months producing an enterprise AI strategy that was, by the lights of the framework it was built on, defensible. Six divisions, each with a labelled posture, a maturity score, a roadmap, and a capability list. The document had the shape boards expect. Three months after sign-off, the retail division was running ahead of plan on a customer-facing assistant, the investment-banking division had not started anything because the failure-tolerance section ruled out everything they actually wanted to do, and the wealth-management division was building a parallel programme outside the strategy because nothing in the document fit how their clients made decisions. The parent strategy was technically intact. Three of its six children had already gone their own way. That is what happens when an enterprise AI strategy is written as one document instead of a portfolio.

The structural problem is not that the consultants were lazy. The document was thorough. The problem is that an enterprise is not one organisation. It is six or twelve or thirty organisations under a shared brand and a shared CFO, and the AI economics in each of them are genuinely different. A retail division has a high-tolerance internal-productivity AI surface and a zero-tolerance customer-facing one. An investment-banking division has zero-tolerance everything and a budget that can absorb compliance overhead retail cannot. A wealth-management division has a regulatory perimeter that rules out half the capability stack retail uses casually. Writing one strategy that fits all three forces the document toward a generality so high that the decisions stop being falsifiable — the thing the four-question diagnostic in the parent hub is built to prevent.

The right shape is a portfolio of strategies. One parent document that fixes the decisions that bind every division — the cost ceiling at the group level, the posture vis-à-vis competitors, the regulatory floor — and per-business-unit sub-strategies that each answer the four questions in their own terms and that each falsify against the parent. The parent is short. The children are operational. The two are linked by an explicit set of contracts, written into both documents, that say which decisions are owned where.

The definition, stated once

Enterprise AI strategy is the parent decision set — posture, cost ceiling, timeline pressure, failure tolerance — applied at group level, with per-business-unit sub-strategies that each falsify against the parent. That is the working definition I have used on twelve engagements since 2023, and the one I will hold to for the rest of this page. The intent-shopper variants of this question — “what is enterprise AI strategy”, “enterprise AI strategy definition”, “AI strategy for companies” — are all the same question, and the answer that survives contact with a board is the one above. Every other definition I have read either generalises so far it stops being engineerable, or so narrowly it stops being enterprise.

The reason most published definitions are wrong is that they are written by vendors. A platform vendor defines enterprise AI strategy as “the disciplined adoption of AI capabilities across the enterprise” — which is to say, the thing the platform sells. A consultancy defines it as “the strategic alignment of AI investment with business priorities” — which is to say, the thing the engagement bills against. The operator definition is the one I am offering here, which is uncomfortable for both groups because it explicitly names what gets cut. That is the test of an enterprise AI strategy worth signing: does it name what gets cut.

Why a single document is the wrong shape

The single-document enterprise AI strategy is structurally vulnerable to three failure modes that the portfolio shape is not.

The first is generality drift. To fit six business units in one document, the posture statement gets written at a level that admits all of them. “We will adopt AI capabilities that strengthen our competitive position.” A statement at that altitude is not a posture. It is a tautology. Every subsequent capability decision becomes defensible against it, which means none of them are constrained by it. The document stops working as a falsifier, which was the whole point of writing it.

The second is cost-ceiling laundering. A group cost ceiling that has to cover both an investment-banking division and a retail division ends up as a number large enough to fund both — which means the cost ceiling does not bind either of them. The retail division spends to the ceiling on a customer-facing assistant the investment-banking division would never approve. The investment-banking division spends to the ceiling on compliance tooling retail does not need. The ceiling is technically respected. Neither division has actually been disciplined by it.

The third is governance asymmetry. A single failure-tolerance section has to accommodate the highest-tolerance use case in the enterprise (internal Slackbot in marketing) and the lowest (credit-decision model in lending). The result is uniform governance applied across both, which is the symmetric mistake the root hub names — either over-governed marketing experiments that die in compliance review, or under-governed lending models that ship without the controls they need. The portfolio shape avoids this by letting each child set its own failure tolerance against a group-level floor, not a group-level ceiling.

Conway’s law applies here in a way most strategy documents miss. The organisation will produce AI systems shaped like the organisation’s communication structure. An enterprise with six business units that report independently to a group CFO will produce six AI programmes whether or not the strategy document acknowledges this. The choice is whether to write one document and pretend it is fitting all six, or write seven documents (one parent, six children) and accept the structure that already exists.

The CIO, CTO, CAIO boundary at enterprise scale

The roles hub holds the long version of the boundary question. The short version, in enterprise context, is this. The parent strategy is owned by one of three people: a CIO with board sponsorship and group-level mandate, a CAIO if the role exists with genuine authority (which in 2026 is the exception rather than the rule), or a board-sponsored programme director reporting directly to the CEO. The per-business-unit sub-strategies are owned by the divisional CTO, the divisional head of data, or in regulated divisions sometimes the divisional chief risk officer.

The boundary that matters is between decisions that bind every division and decisions that bind one. Decisions that bind every division: the group cost ceiling, the regulatory floor (every division must meet at least this level of governance), the posture vis-à-vis external competitors, the procurement standards for AI vendor contracts (more on this in a moment). Decisions that bind one division: which capabilities to build, which models to use, which vendors to evaluate, which use cases to prioritise. Confusing the two is the single most common dysfunction I see in enterprise AI governance — either a parent strategy that tries to pick capabilities for each division (which the divisions will quietly ignore), or a set of per-division strategies with no parent (which produces six incompatible governance regimes and a procurement function that cannot enforce any of them).

The named role I would avoid at enterprise scale is the same one the root hub names: “AI Center of Excellence Lead.” A CoE defaults to a hub-and-spoke structure in which the centre picks capabilities and the divisions adopt them. That structure works for software platforms and almost never works for AI capabilities, because the divisions’ AI economics are too different to share a capability stack at the level a CoE assumes. The CoE either becomes a tooling-procurement function (useful but mis-titled) or an advisory function (useful but powerless), and in neither case does it own the parent strategy. The parent strategy needs an owner with budget authority across all six divisions, which a CoE almost never has.

Shared-services budget allocation

The structural fight in every enterprise AI strategy I have run is the same: which costs sit in the group budget, and which sit in the divisional budgets. The fight matters because the group costs are subject to group cost-ceiling discipline and the divisional costs are subject to divisional discipline, and the two ceilings are usually set by different people for different reasons. The fight produces predictable distortions if it is not resolved at the parent-strategy stage.

The defensible allocation, in my experience, looks like this. Group budget owns: the procurement function for AI vendor contracts (centralised because the leverage is centralised), the governance baseline (centralised because the regulatory exposure is centralised), the data infrastructure shared across divisions (centralised because the unit economics are centralised), and the parent strategy production itself. Divisional budget owns: the capability investments specific to that division, the per-division MLOps and platform work, the divisional governance overhead above the group floor, and the operating-budget transition for division-specific AI work (which the roadmap hub covers as the most predictable failure point in any enterprise programme).

The line I have seen drawn wrongly most often is the platform line. A group CIO who pays for “the AI platform” and expects every division to use it is recreating the data-platform-first sequencing mistake the roadmap hub names. The platform built for an imagined cross-divisional use case rarely fits the real divisional use cases. The honest version is: pay for the data platform that several divisions already need, and let the AI-application layer sit in divisional budgets where the application owners can shape it. Group platform investment makes sense when the platform is observably useful to three or more divisions already. Group platform investment for a platform whose users do not exist yet is a research project in a CIO budget.

Procurement contracts that fail at scale

The single most expensive mistake I have seen in enterprise AI procurement is reusing the SaaS contract template. SaaS contracts assume per-seat pricing, predictable usage, stable vendor capabilities, and an exit motion that is logistically irritating but commercially feasible. AI contracts violate all four assumptions.

Per-seat pricing on an AI tool does not capture the real cost driver, which is per-call inference cost and the verbosity of the context window. Usage scales nonlinearly with adoption, not linearly with seats. A SaaS-templated enterprise contract signed in month one with a forecast of 50,000 calls per month is sitting at 800,000 calls per month by month twelve, and the renegotiation conversation happens with no leverage because the vendor knows the team has built workflows on top of the tool.

Stable vendor capabilities is the assumption that breaks most loudly. The model behind the tool is upgraded twice a year. The pricing is upgraded with it. The capability boundary shifts — features that were enterprise-tier in the original contract move to consumer-tier, and features that were not in the contract at all become the reason the division renewed. SaaS exit clauses assume the contract describes what you bought; AI exit clauses have to assume the contract describes what you bought eighteen months ago.

The three clauses I would write into every enterprise AI vendor contract, and the ones I would refuse to sign without: usage caps with renegotiation triggers tied to specific volume thresholds, not annual review cycles; data-residency clauses that survive model-provider changes (the vendor’s underlying model provider can change without notice, and the contract has to bind the residency commitment to the vendor, not the upstream provider); and exit terms that explicitly address the case where the vendor’s underlying model is deprecated. The EU AI Act raises the regulatory floor on the second of these for high-risk systems specifically, but the operational case for all three applies across the stack.

These clauses live in the parent strategy as procurement standards every division has to use. They do not live in the divisional sub-strategies, because the divisions do not have the leverage to negotiate them individually. This is one of the cleanest examples of a decision that has to bind every division — the group has procurement leverage the divisions do not, and the leverage is wasted if every division negotiates its own contract.

How to come up with one, in twelve steps that do not look like a McKinsey deck

The intent-shopper variant — “how to come up with an enterprise AI strategy” — usually arrives at this page from a search that expected a process. The honest process is this.

One. Decide who owns the parent. Not the title; the person. If you cannot name them, the strategy will not be defensible.

Two. Resolve the CIO-CTO-CAIO boundary in writing, before the first framework page is written. The boundary is the bottleneck.

Three. Convene the divisional heads who will own the children. Not the CEOs of the divisions; the operators. Heads of data, divisional CTOs, divisional chief risk officers in regulated divisions.

Four. Write the parent posture in one paragraph. Not chapter-length. Not a table. One paragraph, with the leader/follower/absentee tell explicit.

Five. Get the group CFO to sign off on the group cost ceiling in writing, with a year attached. The ceiling is an input, not an output. The frameworks hub labours this point because most consulting frameworks treat it as an output, which is the trick that lets the engagement scope expand.

Six. Write the governance floor — the minimum every division must meet — against the NIST AI Risk Management Framework and the EU AI Act high-risk obligations where they apply. This is the only section where consulting frameworks are reliably useful, because the regulatory references are stable.

Seven. Have each divisional owner write a one-page draft sub-strategy answering the four questions against the parent constraints. One page. Not a deck.

Eight. Reconcile. The reconciliation surfaces the divisions that cannot fit under the parent constraints as written, which is the most useful output of the whole process. Either the parent constraints change (rare) or the divisional ambitions change (common).

Nine. Negotiate the shared-services budget allocation. Write the lines explicitly. Do not leave platform investment ambiguous.

Ten. Sign the procurement standards into the parent document. The three clauses above, and any others the group procurement function adds.

Eleven. Date the document. Schedule the six-month review. Inside that review, name the circuit breaker explicitly: the three signals — budget overrun beyond the cost ceiling, a regulatory breach, or a missed milestone past the assumption-kill threshold — that trigger an immediate suspension of a sub-strategy rather than a polite re-plan. The parent should hold for two to three years; the children should be re-cut every six.

Twelve. Publish internally. The strategies that survive are the ones the engineering leadership has read. Strategies that live in a shared drive and are circulated by exception do not survive.

Twelve steps. None of them require a framework choice in the McKinsey-or-Gartner sense; all of them require operator discipline. The framework choice — Microsoft CAF, Gartner labels, the operator-built diagnostic — is the second-order question covered in the parent frameworks hub and the effective-vs-theatrical comparison. The framework gives you vocabulary. The twelve steps give you a working portfolio.

What enterprise AI strategy leadership actually requires

The intent-shopper variant “enterprise AI strategy leadership” deserves a direct answer. The leadership question is not what slides to present. It is whether the named owner has the standing to make the cuts that the strategy implies. Every enterprise AI strategy that survives has at least one painful divisional cut in the first eighteen months — a capability investment that has to be killed because the unit economics do not work, a vendor relationship that has to be churned because the contract clauses bite, a division that has to slow down because the parent cost ceiling tightens. Leadership in this context is the standing to make those cuts without spending political capital the programme cannot afford.

The CIO with twenty years of platform credibility can make those cuts. The newly-named CAIO without budget authority cannot. The board-sponsored programme director with explicit CEO backing can. The CoE Lead reporting to a divisional CIO cannot. The titles are not the answer; the political economy is. When I am asked to help structure the leadership for an enterprise AI strategy, the question I ask first is which divisional capability the named owner can credibly kill in the next quarter. If the answer is “none, that would be too political”, the leadership is not yet in place. Stop. Resolve the political economy. Then write.

The strategies I have seen succeed at enterprise scale all share this property. They were owned by someone who had already made an unpopular technology decision in the prior eighteen months and survived. The standing was earned, not delegated. The strategies that failed were owned by appointees whose political capital was still notional, whose first hard cut had not yet been made, and whose authority was assumed to extend across divisions without ever being tested. The test always comes; the only question is whether it comes during a planned cut or an emergency one.

That is the operator’s read on enterprise AI strategy. A portfolio, not a document. A parent and children, not a monolith. A named owner with earned standing, not an org-chart appointment. The four questions, applied at two levels. The twelve steps, run in order. The framework choice, secondary.

---

Sources & methodology

• NIST AI Risk Management Framework, v1.0 — the public-domain floor for the governance baseline in the parent strategy
• EU AI Act, Regulation (EU) 2024/1689 — August 2026 high-risk system obligations that set the regulatory floor for procurement contracts
• Microsoft Cloud Adoption Framework — AI workloads — the framework that ports cleanest onto enterprise multi-business-unit structures, with caveats
• Conway, M. E. (1968), “How do committees invent?” — the law underneath the portfolio-shape argument
• Methodology: claims drawn from twelve fractional CTO and CIO enterprise engagements 2023-2026, anonymised; the twelve-step process is published CC-BY-4.0 alongside the effective-framework scoring sheet

Disagreements are useful. Send the alternative and I will publish the fork from the next refresh.