Most documents called an AI strategy are not one. They are a list of interesting technologies with an ambition attached — “we will use AI to improve customer experience and drive efficiency” — which commits the organization to nothing and rules out nothing.
A strategy is a choice made under constraint. It says what you are going to do, what you are consequently not going to do, what you are willing to spend and risk, and how you will know whether it worked. If a document contains no decision that closes off an option, it is a wish list.
This is how to get to a real one. It assumes you already know roughly what your organization can support — if not, that is the job of an AI readiness assessment, which comes first.
Start from the business objective, not the capability
The strategy has to begin with something the organization was already trying to achieve before AI was on the agenda: reduce the time to quote, handle more support volume without more headcount, shorten a compliance cycle, keep a plant running.
The test is simple. Write the objective down and remove every mention of AI. If what remains is still a thing the business cares about, you have an objective. If what remains is “we want to use AI,” you have a technology looking for a problem, and the resulting programme will be judged on whether it deployed rather than whether it delivered.
Two or three objectives is right for a smaller organization. More than that and none of them will get the attention needed to work.
Decide where AI will be used — and where it will not
This is the part that makes a strategy a strategy, and the part most commonly missing.
For each objective, identify the specific processes in scope. Then, explicitly, name the areas that are out of scope and say why. Candidates for exclusion in most organizations:
- Anything where an error reaches a customer or a regulator without a human in between and cannot be caught in time.
- Low-volume, high-variability work, where the effort of setting it up exceeds any plausible return.
- Decisions the organization would not be able to explain if challenged — credit, hiring, and eligibility decisions in particular.
- Processes currently held together by one person's judgment that nobody has written down. The prerequisite there is documentation, not AI.
Writing the exclusions down does two useful things: it stops the same proposals recurring, and it gives staff a defensible answer when a vendor approaches a department directly.
Build, buy, or wait
Three options, and for most small and midsize organizations the honest ranking is usually in that reverse order.
Buy is the default and should be. Capability that is already embedded in software you run — your CRM, your service desk, your document management — carries no integration project and no separate vendor relationship. It is frequently good enough, and its main risk is that it is easy to accumulate without noticing.
Build is warranted when the process is genuinely specific to your organization and is a source of advantage, when the data required is yours and not available to a vendor, or when no product addresses it. It is a real commitment: something built has to be maintained, monitored, and eventually replaced, and that cost lands on the same small team.
Wait is a legitimate strategic choice and almost never appears in these documents. It is the right answer when the readiness work is not done, when the market for a particular capability is moving fast enough that this year's decision will look poor next year, or when the organization has no capacity to absorb another change. Waiting deliberately, with a date to revisit, is entirely different from drifting.
Choosing between the three
| Choose it when | What it commits you to | |
|---|---|---|
| Buy | The capability already exists in software you run, or in a product that fits the process as it is | A vendor relationship and a recurring cost; limited control over the roadmap |
| Build | The process is specific to you and a source of advantage, or the data required is not available to any vendor | Maintenance, monitoring, and eventual replacement — by the same small team |
| Wait | Readiness work is outstanding, the market is moving quickly, or the organization has no capacity to absorb the change | A dated review, and the discipline to actually hold it |
One caution on “buy”: capability bundled into software you already own is the easiest to adopt and the easiest to accumulate without deciding. It still needs to appear in the strategy, or you will have made the decision by not making it.
Set a risk appetite
An AI strategy that does not say what risk is acceptable will have that decision made for it, one department at a time.
The questions a leadership team should answer, in advance and in writing:
- What categories of information may leave the organization's control, and which may never?
- Where must a human review output before it has effect — and what is the standard for that review?
- What is the organization willing to say publicly about its use of AI?
- What would cause us to stop a deployment?
These are business decisions, not technical ones. The controls that implement them are the subject of AI governance; the appetite itself belongs here.
Decide what success looks like, before
Define the measure at the same time as the objective, because a measure chosen afterwards is chosen to be met.
Useful measures are specific and countable, and they belong to the business rather than to the tool: how long the process takes end to end, how much of the workload clears without a person intervening, how often the output has to be corrected, and what a single completed item costs once the platform fee is included. Weak measures are adoption counts, licences deployed, and satisfaction scores — all of which can improve while the business outcome does not move at all.
Two disciplines make the measurement honest. Record the current state before anything changes, and count the review effort as a cost — output that needs heavy correction has relocated work rather than removed it.
Decide who owns it
A strategy with no named owner is a document. Someone has to be accountable for the objectives, hold the budget, and have authority to stop things.
In most smaller organizations this is not a new hire. It is an existing executive supported by whoever holds the technology brief — internal or a Virtual CIO. What matters is that the person can say no to a department, which means the role has to sit above the departments.
Who needs to be in the room
An AI strategy produced by the technology function alone will be technically coherent and commercially irrelevant, because the decisions above are not technical ones. The exclusions are a risk judgment, the build/buy position is a commitment of budget and staff, and the success measures belong to whoever owns the business outcome.
For a smaller organization the working group is small: the executive who owns each objective, whoever holds the technology brief, and someone who can speak to the legal and contractual obligations. Two sessions of a couple of hours is usually enough — one to agree objectives and exclusions, one to settle build/buy, risk appetite, and measures.
What does not work is circulating a draft for comment. Exclusions in particular do not survive an email round, because the person whose favoured idea is being excluded will object in writing and the exclusion will quietly soften.
A worked example
A forty-person insurance brokerage sets one objective: reduce the time taken to produce a renewal quotation, currently a day and a half of an account handler's time spread across a week.
In scope: extracting policy details from the documents insurers return, and drafting the client-facing summary. Explicitly out of scope: any decision about pricing or cover suitability, because the firm cannot explain a machine-made recommendation to a regulator and is not willing to try.
Position: buy, because two systems the firm already licenses offer document extraction; build nothing. Risk appetite: client documents may go to an approved vendor under a data processing agreement, but no document may be uploaded to a personal account, and every client-facing summary is checked by the handler before it is sent. Success: median time to produce a quotation, baselined this month, with escalations and errors at review tracked alongside so a speed gain that costs accuracy is visible.
That is a strategy. It is four paragraphs, it closes off options, and someone could act on it on Monday.
Write it down — and keep it short
The artifact should be three to five pages. Anything longer will not be read by the people who need to act on it, and length tends to substitute for decision. It should contain:
- The two or three business objectives, in the organization's own language.
- Where AI is in scope, and the explicit exclusions with reasons.
- The build/buy/wait position for each area.
- The risk appetite statements.
- The success measures and the current baseline for each.
- The named owner and the review date.
Notice what is absent: no vendor names, no architecture, no timeline. Those belong to the plan, not the position — and keeping them out is what lets the strategy survive a change of platform.
Review it on a date, not on a rumour
Set a review date when you write it — six months is reasonable at present — and hold to it. The alternative is that the strategy is reopened every time a competitor announces something or a board member reads an article, which produces churn without decisions and exhausts the people who have to implement whatever survives.
Between reviews, new proposals are tested against the existing position rather than triggering a rewrite. If a proposal is genuinely good and the position excludes it, that is a reason to note it for the review, not to abandon the document.
The failure mode to watch for
The most common way this goes wrong is a strategy that is really a procurement list: three named products, a budget, and a deployment schedule, with the objectives written afterwards to justify them. It is recognisable by a simple test — if a better product appeared next month, would the document change? If replacing the tool invalidates the strategy, the tool was the strategy.
The second failure is a strategy nobody can act on because it never descends from principle to specifics: worthy statements about responsible adoption and workforce enablement, no named process, no owner, no number.
From position to plan
A strategy tells you what you have decided. It does not tell you what happens in March, what has to be finished before something else can start, or what each phase costs. Turning the position into a sequence with dependencies, budget, owners, and decision gates is a separate exercise — covered in building an AI technology roadmap.
Do them in that order. A roadmap built without a settled position produces a plan that changes every time someone senior sees a demonstration, and the sequencing work has to be redone each time.
Working out where AI genuinely fits? Schedule an AI & Technology Readiness Assessment — it produces the findings a strategy needs, and a roadmap you keep.