AI Strategy: What It Looks Like When It Actually Works
Nearly every mid-market and enterprise company now has AI somewhere in the plan. Budget has been approved, pilots are running, someone has been asked to “own AI.” Much of that activity is legitimate. The problem starts when the activity outruns the decisions behind it: which outcome each pilot is meant to move, which use case comes first, what the data has to look like for it to work, and who calls it when it doesn’t.
That is the gap between having an AI plan and having an AI strategy. And it is measurable.
S&P Global’s AI and Labor Landscape 2026, published in June 2026, put a number on it. Of the AI initiatives organisations launched over the previous twelve months, just 37% were live and delivering value. Another 46% were rated on track to reach a return within a year. The rest were stuck in development or partial deployment. In Germany the ROI figure fell to 38%.
The same S&P research points at what separates those groups, and it is not model quality. Among organisations with 10,000 or more employees, 44% report a clear, documented AI strategy aligned to core business goals, with defined roles and career paths for AI specialists. S&P found a direct relationship between that discipline and three things: how often AI projects succeed, what return they produce, and whether AI ends up recognised as an organisation-wide capability at all.
That is an unusually direct finding. The document is not the point — the decisions it forces are. This guide covers what those decisions are, how to sequence them, and how to tell whether what you have qualifies.
What is an AI strategy?
An AI strategy is the set of decisions that make delivery possible. It is distinct from an AI plan, which lists activity, and from a technology roadmap, which starts from capabilities rather than outcomes. In practice a working AI strategy answers five questions in writing:
- Which business outcomes are we buying? Not “improve efficiency” — a named metric with a current value.
- Which use cases, in what order? A ranked list, not a backlog.
- What has to be true about our data and systems for each of them to work?
- What do we build, what do we buy, and what do we assemble from existing parts?
- Who owns the decision when this conflicts with something else?
Anything that does not resolve into one of these is background material. Useful for context, but not strategy.
The common failure is not a bad answer to any of these. It is a document that answers none of them while reading as though it answers all of them.
The six parts of a working AI strategy
A complete AI strategy covers six areas: outcomes, use case ranking, data readiness, sourcing, ownership, and funding. Each section below sets out what that area has to resolve and what the available research says about getting it wrong.
1. Outcomes tied to a number someone already reports
An outcome belongs in an AI strategy only if someone in finance can already measure it. Start from a metric your CFO or COO tracks today: cost per ticket, days to close, gross margin on a service line, first-response time, error rate in a manual process.
MIT’s Project NANDA study, published in July 2025 — the source of the widely cited finding that 95% of enterprises saw no return on $30–40 billion of generative AI spend — was unusually specific about where returns did appear, and it was not where most budgets went. The documented back-office wins included elimination of business process outsourcing worth $2–10 million annually in customer service and document processing, a 30% reduction in external creative and content spend, and around $1 million a year saved on outsourced risk checks at a financial services firm. Front-office gains were real but smaller: roughly 40% faster lead qualification, a 10% improvement in customer retention.
The pattern underneath those numbers matters more than the numbers themselves. The gains came without material workforce reduction. Teams got faster; structures and budgets stayed the same. Value showed up as reduced external spend — cancelled BPO contracts, lower agency fees, work brought back in-house from expensive consultants.
S&P Global’s 2026 survey data says the same thing from the buyer’s side: process efficiency (64%) and employee productivity (59%) are the dominant objectives for AI initiatives, while head count reduction is cited by 24%.
That gives a useful filter. If a business case depends on eliminating roles, it will be harder to deliver and harder to defend internally than one that removes an outsourced line item.
The test for any stated outcome: could a finance business partner verify the result from data they already have? If proving the value requires building new reporting first, the outcome is not yet concrete.
2. A ranked use case portfolio
The strategy is the ranking, not the list. Most organisations can produce a long list of AI opportunities; far fewer can say which three come first and why the fourth did not make it.
MIT’s 2025 study surfaced a misallocation worth checking against your own plan. Roughly half of generative AI budget was going to sales and marketing, while the sharper returns showed up in back-office automation. The reason is not that anyone believes sales AI is more valuable — it is that sales metrics are easier to attribute. Demo volume and email response time map directly onto board-level KPIs. Fewer compliance violations and a faster month-end close do not.
A VP of Procurement quoted in the report put the problem plainly: justifying a tool that helps a team work faster is difficult when it does not obviously move revenue or measurable cost.
Two axes do most of the ranking work:
- Feasibility — is the data available, is the process stable enough to automate, does a model actually solve this?
- Value — how much does the outcome move, how many people or transactions does it touch, how quickly?
One correction worth making early. S&P Global’s 2026 data found that only 22% of AI projects target a fully autonomous end state; the largest share sit at minimal autonomy, where AI recommends and a human decides. Ranking use cases as though each one removes a process end to end will produce a portfolio that cannot be delivered. Most value available in 2026 comes from augmentation, and the business case should be written that way.
What usually survives ranking is three to five candidates worth funding, a longer tail worth revisiting in six months, and a set of ideas that should be explicitly killed. The third category matters as much as the first. An unranked backlog quietly consumes attention forever.
3. Data and platform readiness, assessed honestly
Data readiness is where most strategies get optimistic. A use case that looks trivial on a slide often depends on data scattered across three systems, inconsistently labelled, or owned by a team with no capacity to help.
Every large study points here. Gartner’s Q3 2024 survey of 248 data management leaders found 63% either did not have the right data management practices for AI or were not sure whether they did. Gartner’s 2025 prediction, published in February that year, was that through 2026 organisations would abandon 60% of AI projects that are not supported by AI-ready data. Read that carefully — the 60% applies to projects lacking AI-ready data, not to all AI projects. It is a statement about a decision you control, not a general odds forecast.
S&P Global’s 2026 numbers describe the same constraint from inside the projects. Asked what limits generative AI models in practice, respondents named data privacy and security (51%), response accuracy and quality (46%), and data quality (38%). On the skills side, 57% reported that gaps in data management and governance had a moderate or severe impact on AI initiatives.
Readiness is not a single score. It has five parts: is the data accessible, is it accurate enough for this specific decision, is there enough history, can it legally be used this way, and does anyone own it. A use case can pass on four of those and still be blocked by the fifth.
Working through this before committing budget is the point of an AI readiness assessment — establishing what is genuinely available rather than what is assumed to be.
Not sure which use cases are actually feasible?
4. Should you build, buy, or assemble?
Sourcing is the decision with the strongest evidence behind it, and the evidence is uncomfortable for anyone who builds software. In MIT’s 2025 sample, external partnerships with customised, learning-capable tools reached deployment about 67% of the time. Internally built tools managed roughly 33%. Employee usage rates were nearly double for externally built tools. The report states it directly: “Strategic partnerships are twice as likely to succeed as internal builds.”
It is worth quoting the authors’ own caveat, because most people citing this number leave it out. They note that the difference may reflect organisational capability rather than the approach itself — companies choosing external partners may differ in risk tolerance, procurement sophistication, or internal technical capacity. Their words: the correlation does not necessarily prove causation.
That caveat is the useful part. Read carefully, the finding is less about build versus buy and more about isolation versus experience.
The practical framing:
- Buy when the capability is undifferentiated and a mature product exists. Most transcription, translation, and general-purpose drafting sits here.
- Assemble when the value comes from your data rather than the model — retrieval over internal documentation, domain-specific classification, workflow integration. The model is a component; the differentiation is the plumbing around it.
- Build when the capability is the product, when data residency or latency rules out third-party services, or when the workflow is specific enough that no vendor will ever fit it.
The constraint that most often forces the decision is not cost. It is where data is allowed to go, and how much of the workflow is genuinely specific to you.
A worked example. A global consumer goods company ran client and vendor support on a custom-built legacy system. It required ongoing maintenance, could not scale with rising request volumes, and had no built-in automation — so a large share of routine, repetitive cases were being handled by hand across multiple markets.
The instructive part is what the answer turned out to be. The organisation already had a custom build. The fix was not a better one. CodeIT assessed the existing infrastructure, mapped case volumes and request types, and replaced the legacy system with Microsoft Dynamics 365 Customer Service and Copilot Studio — a vendor platform, configured and integrated by an external team, with AI agents handling routine inquiries and voice channels unified across regions.
The results: 50–65% of support cases automated, response times 25–35% faster, support costs down 20–30%. A team of four delivered it.
That shape — an ageing internal build replaced by a configured vendor platform with partner-led implementation — is precisely the pattern MIT found in the successful third. It also sits squarely in the back office, where the same research located the stronger returns. The full write-up is here: AI support automation for a global FMCG company.
Not every case resolves this way. Where data residency, latency, or genuinely idiosyncratic workflow rules out the vendor market, the architectural questions come first: model selection, self-hosting trade-offs, retrieval design. Those are expensive to reverse, which is why generative AI and LLM consulting belongs before delivery rather than during it. The delivery itself sits with custom AI development.
5. Ownership and operating model
Two findings look contradictory here until you read them together.
S&P Global’s 2026 research found that large organisations with a formal, documented AI discipline — defined roles, career paths, a strategy aligned to business goals — show measurably better project success rates and returns. MIT’s 2025 study found that the successful minority did not route everything through a central AI function that picked use cases on the organisation’s behalf. They let budget holders and domain managers surface problems, evaluate tools, and lead their own rollouts, paired with executive accountability rather than executive selection.
The two describe the same thing from different angles. Formal discipline means documented structure, named roles, and clear accountability. It does not mean central selection of what gets built. Organisations that confuse the two end up with an AI committee that owns the roadmap and no domain owner who wants what is on it.
MIT also noted that many of the strongest deployments began with employees already using consumer AI tools on their own initiative. Those people understood both the capability and its limits, and became credible champions for a sanctioned version.
Practically, the strategy needs to name three things: who decides when security and delivery disagree, who maintains what gets built, and what happens when a pilot succeeds but no team has capacity to run it. Not a committee for each — a person, with an escalation path.
One resourcing note. S&P Global’s 2026 skills-gap data ranks cybersecurity as the most acute shortage affecting AI initiatives, with 64% reporting moderate or severe impact, ahead of machine learning and AI development (59%) and software engineering (58%). Plans that assume the constraint is model expertise frequently discover it is security review capacity.
6. Funding and measurement
Fund in stages rather than approving a programme up front: a small validation budget per use case, a larger build budget released only after validation clears an agreed bar, and a separate line for running what already exists.
The measurement design matters more than the number. MIT’s 2025 finding of 95% rests on a roughly six-month window to a measurable result, and the authors flag that this may be too short for complex enterprise systems. S&P Global’s 46% uses a twelve-month ROI horizon. Neither window is correct in the abstract — the point is to set yours deliberately rather than inherit one, agree what would count as failure before work starts, and agree who will call it. Initiatives without a defined stop condition tend to continue regardless of results.
Worth factoring in: S&P Global recorded a marked decline in confidence in AI outputs since 2023. In 2026, 16% of respondents said they completely trust third-party AI models, down from 24% three years earlier. Adoption plans that assume trust grows automatically with exposure are running against the trend.
What a completed AI strategy entry looks like
The six parts above become useful when they resolve into specific answers for a specific initiative. The table below shows the seven decisions each initiative should carry, and what they looked like in the FMCG engagement described earlier.
The right-hand column is limited to what has been published. Four of the seven were internal to the client and are not disclosed — which is itself instructive, since those four are the ones most often missing from strategy documents that never reach delivery.
| Decision | What a complete answer specifies | FMCG engagement |
|---|---|---|
| Outcome | A metric finance already reports, with its value today | Support cost and response time. Delivered: costs down 20–30%, response 25–35% faster |
| Use case | One process, scoped to a specific step and channel | Routine, repetitive client and vendor support cases across multiple markets |
| Data owner | The named person who can approve access and answer quality questions | Client-internal, not published |
| Build / buy / assemble | The sourcing decision and the constraint that drove it | Buy. Microsoft Dynamics 365 Customer Service and Copilot Studio, configured and integrated by an external team, replacing a custom legacy build |
| Decision owner | The person who resolves conflicts between security, delivery, and the business | Client-internal, not published |
| Measurement window | The date by which the outcome is assessed | Client-internal, not published |
| Stop condition | The result that would end the initiative, agreed before work starts | Client-internal, not published |
An entry with all seven filled is a strategy. An entry with the first two filled is a plan.
AI strategy vs AI business strategy
The two terms get used interchangeably, but the distinction is worth keeping.
An AI business strategy asks how artificial intelligence changes what the company sells, who it competes with, and where margin comes from. It belongs to the executive team and sits alongside the corporate plan.
An AI strategy, in the sense most organisations need first, is narrower and more operational: which capabilities to build, in what order, on what foundation. It belongs to a CTO, CIO, or transformation lead.
Most companies do not need to finish the first before starting the second. Waiting for a complete AI business strategy before making any delivery decision is a common and expensive form of stalling.
What do the first 90 days look like?
The first quarter should end with one validated use case and a funded roadmap, not with a completed analysis. A workable sequence:
Weeks 1–2 — Frame. Agree the outcomes, gather the candidate use cases, identify the constraints that are genuinely non-negotiable — data residency, regulatory, contractual.
Weeks 3–5 — Assess. Test the shortlist against data reality. Most shortlists lose one or two candidates here, which is the assessment doing its job.
Weeks 6–8 — Decide. Rank what survives, resolve build, buy, or assemble for each, size the work, and produce something a budget owner can approve or reject.
Weeks 9–12 — Validate one. Take the top candidate to a working prototype rather than another round of analysis. A proof of concept answers questions no amount of planning will.
Speed is itself a differentiator. MIT’s 2025 study observed mid-market top performers moving from pilot to full implementation in about 90 days, while enterprises — firms above $100 million in revenue — commonly took nine months or longer. The enterprises ran more pilots and assigned more staff, and reported the lowest pilot-to-scale conversion of any group.
How to tell whether your AI strategy is real
Run your current strategy against these eight questions. Each should have a specific answer, not a direction.
- Name the metric that moves if the first initiative succeeds, and its value today.
- Name the top three use cases, in order, and say why the fourth did not make it.
- Say what share of the planned spend goes to back-office work versus sales and marketing.
- For the top use case, name the systems its data comes from and who owns them.
- Say whether the target state is augmentation or full automation, and what that implies for the business case.
- Say whether you are building, buying, or assembling it, and what would change that decision.
- Name the person who resolves a conflict between security and delivery on this work.
- State the measurement window and what result would cause you to stop.
Fewer than five solid answers usually means what you have is an AI plan rather than an AI strategy. That is a normal place to be — it just should not be mistaken for readiness to build.
Organisations that want a second opinion on the ranking, or an outside view when internal teams disagree on sequencing, often bring in AI advisory services for the decision points rather than the whole programme.
Explore AI strategy consulting
FAQ
An AI strategy is the set of decisions that make AI delivery possible: which business outcomes to target, which use cases to pursue in what order, what data and platform work each requires, and who owns delivery. It differs from an AI plan in that a plan lists activity while a strategy resolves the decisions behind it. It differs from a technology roadmap in starting from outcomes rather than capabilities.
Because of data readiness and workflow integration, not model capability. S&P Global’s 2026 research found only 37% of AI initiatives launched in the previous twelve months were live and delivering value, with data privacy, response accuracy, and data quality the most cited constraints. Gartner’s 2025 prediction points at the same root cause: abandonment of 60% of AI projects unsupported by AI-ready data through 2026. MIT’s 2025 study reached it from the pilot side, tracing failure to data readiness, weak workflow integration, and the absence of a feedback loop after launch.
Two to three weeks for framing and assessment, when the relevant people are available. Longer timelines usually reflect difficulty locating data owners rather than analytical complexity. A full first cycle — through to one validated prototype — runs about 90 days.
An AI business strategy concerns how AI changes the company’s market position, offerings, and economics, and belongs to the executive team. An AI strategy in the operational sense concerns which capabilities to build and in what order, and belongs to a CTO, CIO, or transformation lead. Most organisations start with the second and do not need the first completed before they begin.
Yes, according to S&P Global’s 2026 research, which found a direct relationship between a formal, documented AI discipline and project success rates, return on investment, and whether AI was recognised as an organisation-wide capability. Among organisations with 10,000 or more employees, 44% reported having one. The document itself is not what produces the result — the decisions it forces are.
Buy undifferentiated capability where a mature product exists; build where the capability is the product or where data residency, latency, or workflow specificity rules vendors out; assemble in between. MIT’s 2025 study found partner-led deployments reached production about twice as often as purely internal builds, while cautioning that the difference may reflect organisational capability rather than the approach itself. Read that way, it argues less against building than against building alone.
Check five things: whether the data is accessible, accurate enough for the specific decision, sufficient in history, legally usable for the purpose, and owned by someone who can support the work. A use case failing any one of those is not ready, regardless of how attractive the value case looks.