// in this post
This is the third piece in a series, and it was promised twice: the one on how to actually write an AI strategy, the working document rather than the vision slide. The first piece argued that AI capability is an organisational design problem, not a training problem. The second named the five things that design problem actually involves: distributed fluency, quality oversight, strategic use-case selection, adaptive learning, and workflow redesign. Both pieces ended the same way: the next one would be about the document that turns those five into an actual plan. This is that piece.
What a strategy is, and what it usually is instead
Most things called an "AI strategy" are a vision statement with a roadmap graphic. Ambition, a few named technologies, a slide about culture. Nobody's job changes because of it. It gets presented once, filed, and referenced again only when someone asks whether AI is "on the roadmap."
A working AI strategy does something different: it's a small set of decisions, written down, specific enough that someone could read it and know what to do differently on Monday. Which use cases get real investment this year. Which ones don't, on purpose. Who signs off on what. What gets measured, and by when.
If a document doesn't let you point to a decision it drove, it's the deck version wearing a strategy's name.
This isn't only a documentation problem. Rana el Kaliouby, an AI scientist who's built and sold AI products for two decades, makes the same case from a completely different angle: the organisations that struggle aren't short on technology, they're short on the human decisions around it.
The pattern shows up whether you arrive at it from organisational design, as the first two pieces in this series did, or from building the models themselves, as she has.
What actually goes in an AI strategy
Five sections, each answering a specific question, each short enough that a leadership team could produce a first draft in a few working sessions.
The use cases you're actually investing in, and the ones you're not. Name three or four, specifically. "Improve customer service with AI" isn't a use case; "reduce first-response time on billing queries using AI-drafted replies with human sign-off" is. For each one you name, say what you're deliberately not doing this year, and why. The second half is easy to skip and is usually the more useful sentence in the document, since it stops every team from treating their own AI idea as automatically in scope.
The workflow redesign each one needs. Not "roll out the tool", the actual sequence: what changes at the step AI touches, and what has to change downstream because that step is now faster. This is where most strategies go quiet, and it's the single biggest reason pilots don't turn into results. A use case without a redesigned workflow around it is a demo, not a plan.
The review tier for each use case. Not every piece of AI output needs the same scrutiny. Internal drafts, customer-facing content, and anything regulated need different sign-off levels, and the document should say which is which, in one line per use case. This is what turns "we'll be careful" into something a reviewer can actually check against.
Who owns which decisions. Not just who owns the programme overall. Who decides whether a new use case gets added to the list. Who decides when to pull one that isn't working. Without this, decisions happen by whoever's loudest in the room, and the strategy stops being the thing that actually governs what happens.
What you're measuring, and by when. Outcome metrics, not activity metrics. Not "how many people were trained", but the number the use case was chosen to move: response time, error rate, hours reclaimed on a specific task. Put a date on when you'll look at it. A strategy with no review date is a strategy nobody's accountable to.
The one line most documents are missing
Put a date in the document for when it gets revisited, and mean it. Quarterly, not annual. The tools and the workflows underneath this document will have moved by the time a year's passed, which is exactly the adaptive-capability competency from the previous piece in this series. A strategy that only gets looked at once a year is already behind by month three.
Doing this yourself, or not
The five sections above are enough to draft a real first version without anyone's help. Most leadership teams can get through it in a handful of focused sessions if they're honest about the second half of section one, the things they're choosing not to do.
Where outside help tends to earn its cost is the room, not the framework: getting a leadership team to actually agree on trade-offs, rather than everyone's favourite use case making the list, is the harder part in practice than writing the document itself. That's the bulk of what a Discovery engagement does: the same five sections, worked through with your actual team, on your actual workflows, in a fixed two-week scope. If you'd rather talk it through first, get in touch.
FAQ
What should an AI strategy document actually include?
A short, named list of the use cases you're investing in and the ones you've deliberately ruled out, the workflow redesign each use case needs, the review tier and sign-off level for each, who owns which AI decisions, the outcome metrics you're tracking, and a fixed date to revisit the whole thing. If a document doesn't let you point to a decision it drove, it isn't a strategy.
How is an AI strategy different from an AI vision statement?
A vision statement describes an aspiration. A strategy is a set of choices: which three or four use cases get investment, which ones don't, who's accountable for each, and what you'll measure. If nothing in the document would change what someone does on Monday, it's a vision statement wearing a strategy's name.
Should I write my AI strategy myself, or get help?
The framework here is enough to draft a first version yourself, most leaders can produce something workable in a few focused sessions. Where outside help earns its cost is facilitation (getting a leadership team to actually agree on trade-offs) and pattern-matching from having done it with other organisations before.
How often should an AI strategy be reviewed?
Quarterly, not annually. The tools and workflows underneath the strategy change faster than an annual planning cycle can track, which is one of the five organisational competencies in the previous piece in this series. Build the review date into the document itself rather than waiting for it to feel out of date.