How to Build an AI Strategy for Your Organisation

Most documents that get called "the AI strategy" turn out, on inspection, to be a list of pilots with a vision slide attached. They rarely answer the questions that actually decide whether AI becomes an organisational capability or a recurring round of disappointing pilots: how ambitious the organisation is willing to be, what it would have to build to get there, how it plans to make the build-vs-buy choices that come up monthly, and where AI work sits inside the operating model when there are five teams using it differently.

A real AI strategy is the document that holds the portfolio together. It tells the use-case selection process which ideas matter most, the governance process which controls have to scale with the work, and the readiness process which gates have to be built once rather than reinvented at every deployment. Without it, each new AI project is essentially a one-off, and the organisation never compounds what it learns from one project to the next.

Five questions, answered in writing and at the right level of seniority, are what separate a strategy from a slide deck. Skipping any one of them is what creates the next round of disappointing pilots.

The first is ambition: what kind of AI organisation does the leadership team intend to be in three years. Three honest options sit on the table, and they are not interchangeable. Assist: AI helps existing roles do their existing work faster (drafting, summarising, retrieving). Automate: AI takes over routine workflows end to end, with humans on exception. Transform: AI is part of how the organisation creates value, with new products, new pricing models or new operating models that did not exist before. Each tier costs an order of magnitude more than the one below it, requires very different capability, and asks a very different governance question. Pretending all three are the same target is the most common origin of a failing strategy.

The second is the capability gap: what the organisation has today versus what the chosen ambition actually requires. Data quality, data accessibility, engineering depth, MLOps, change management, and the ability to run a real product team are the most common gaps. The strategy that lists desired use cases without honestly costing the capability gap underneath them is a wish list, not a plan.

The third is build vs buy, framed at the strategy level rather than per-deployment. For which categories of AI work is the organisation comfortable depending entirely on a vendor (third-party API, third-party model, third-party data flows). For which categories is it strategic enough to invest in fine-tuning, retrieval pipelines or in-house infrastructure. The wrong answer is to leave this question to whoever ships first; what you get is silent vendor lock-in across the portfolio.

The fourth is the operating model: where AI work lives in the organisation. A central AI team that owns delivery. Embedded AI engineers inside business units. A small centre of excellence that supports federated teams. A hybrid that combines them. Each model fits different organisational shapes, and each one has predictable failure modes if forced onto a context it does not fit.

The fifth is talent: which roles to hire, which to retrain, which to source externally, and which to leave intentionally on hold until the work justifies them. Most organisations over-hire data scientists and under-invest in the product, ML engineering and change-management roles that decide whether the data scientist's work ever reaches a user.

The single most consequential decision in the strategy is the ambition tier, because everything else flexes around it.

Assist is the lowest-cost, lowest-risk tier. Drafting tools for sales, summarisation for legal, code completion for engineering. The investment is mostly in licensing, training and a light governance layer. Returns are real but bounded, and the strategy only has to hold for as long as the underlying tools remain best-in-class. This is the right starting tier for most mid-sized organisations.

Automate is significantly more expensive and slower. End-to-end automation requires reliable upstream data, a willing operational owner, a real validation set, and a fallback path. It also demands a change management programme on the workforce side, because automation reshapes roles. Strategies that promise automation but fund it as if it were assist are why so many "AI transformations" stall at the first incident.

Transform is rare and serious. It is what happens when AI changes how the organisation makes money or delivers its mission, not how its existing employees do their existing jobs. Transformation-tier strategies need executive ownership, multi-year capital, and the willingness to redesign products, pricing or operating models. They are not a marketing position, they are a strategic commitment, and most organisations are better off explicitly choosing assist or automate for now and revisiting transform later when the foundations are real.

The honest answer for most organisations is "assist for the next twelve months, automate in two specific places by month eighteen, transform not yet". Writing that down, and saying no to the rest, is more strategic than a forty-slide ambition deck.

Build versus buy at the strategy level is not the same conversation as build versus buy on a single deployment. It is the conversation about which categories of AI capability the organisation is willing to depend on the market for, and which it is willing to invest in owning.

A useful way to draw the line is by distance from the core. Capabilities far from what makes the organisation distinctive (general drafting, generic summarisation, off-the-shelf code completion) are almost always better bought. Capabilities close to the core (the model that values your specific assets, the system that routes your specific operational decisions, the assistant trained on your specific institutional knowledge) are often worth the investment in owning, even at higher cost, because they encode something the organisation does not want a vendor to take away.

The operating model is what makes those decisions repeatable. A central AI team that owns delivery works for organisations with a small number of high-stakes use cases. A federated model with an enabling centre of excellence works for organisations with many distinct business units, each with its own use cases. A pure embedded model (AI engineers in every team, no central function) is fast but consistently produces fragmented architectures and vendor sprawl. The right answer depends on the shape of the organisation, and the wrong answer is to copy the model from a company that does not look anything like yours.

The most common sequencing mistake in AI strategies is to start with use cases and let the capability follow. The pattern looks productive (pilots ship quickly, executives stay engaged), and it produces consistently disappointing results twelve months in, because each pilot keeps re-discovering the same capability gaps and re-paying the cost of solving them in isolation.

A stronger sequencing puts the capability waves first, then runs use-case waves on top of them. Wave one is foundational: data accessibility, a single approved set of vendor models with appropriate contracts, a basic governance and incident process, and a small enabling team. Wave two adds depth where the strategy needs it: retrieval pipelines, validation sets that scale, MLOps, and an honest assessment of which roles the organisation is going to invest in. Wave three is the use-case portfolio at scale, drawing on capabilities the organisation now actually has, rather than capabilities it keeps hoping will materialise.

This is also where the AI strategy meets the wider transformation discipline of the organisation. The capabilities are governance, sequencing and operating-model decisions in their own right, and they do not get easier the third time the same gap is rediscovered.

An AI strategy is not a list of pilots, an ambition deck, or a vendor-influenced reference architecture. It is the document that decides what kind of AI organisation you intend to be in three years, what you are willing to build to get there, and what you are explicitly choosing not to do. The organisations that get measurable value from AI are not the ones with the most pilots, they are the ones where the strategy is specific enough that someone could actually disagree with it.

The wider context, including how strategy connects to governance, readiness, use-case selection and operating model, is collected in the AI strategy and automation insights cluster. And when the question moves from "we should have an AI strategy" to "we have one and we now need someone to translate it into a portfolio that ships and a capability that compounds", that is exactly what my project management and digital strategy practice is built for.