Every company I talk to wants an AI strategy. Most of what I've seen labelled as one is a list of places where AI could theoretically be applied, with no prioritisation, no evaluation criteria, and no honest assessment of whether the investment would actually create value. "Use AI everywhere" isn't a strategy. It's a wish list.

Building a genuine AI strategy requires the same rigour you'd apply to any technical strategy. The frameworks don't change just because the technology is exciting.

Start with Diagnosis

Richard Rumelt's strategy framework, diagnosis, guiding policies, coherent actions, applies directly. Before you decide where to use AI, you need to understand where AI actually creates value in your specific context.

Not every problem benefits from AI. The problems that benefit most tend to share characteristics: they involve processing large volumes of unstructured data, they have tolerance for imperfect outputs, they currently require significant human time on repetitive cognitive tasks, and the cost of errors is manageable.

The problems that benefit least are the ones where precision is critical, where the domain is narrow and specialised, where the data is limited or proprietary, and where the cost of errors is high. Applying AI to these problems isn't impossible, but the investment required to make it reliable is often much higher than the marketing suggests.

Your diagnosis should honestly assess: where in our business do the characteristics of good AI problems exist? Where are we currently spending human time on work that AI could genuinely do well? Where would AI create risk that we're not equipped to manage?

Guiding Policies

Once you have a diagnosis, you need guiding policies that help the organisation make consistent decisions about AI adoption. Here are the ones I've found most useful:

Default to wrapping, not building. Unless you have a genuine competitive advantage in AI model development, your default should be to use existing models and APIs rather than training your own. The cost and expertise required to build and maintain custom models is enormous, and for most organisations, the marginal improvement over existing models doesn't justify it.

Require a clear value hypothesis before investing. Every AI initiative should have a specific, testable hypothesis about what value it will create. "This will improve customer satisfaction" is too vague. "This will reduce average support ticket resolution time by 30% for tier-1 issues" is testable.

Set evaluation criteria before building. How will you know if the AI application is working? Define success metrics upfront, including acceptable error rates, performance thresholds, and user satisfaction targets. Without these, you'll end up with AI features that nobody can objectively evaluate.

Budget for ongoing costs. AI isn't a one-time investment. Model APIs cost money per call. Models degrade over time as the world changes. Monitoring, evaluation, and maintenance are ongoing. Budget for the full lifecycle, not just the initial build.

Coherent Actions

The actions that follow from your strategy should be focused rather than scattered. Pick the two or three highest-value applications, invest properly in them, and prove the value before expanding. The organisations that try to do ten AI projects simultaneously end up doing none of them well.

For each initiative: assign a clear owner, define the success criteria, set a timeline for evaluation, and be willing to kill it if the results don't justify continued investment. The same discipline you'd apply to any technical project applies here, perhaps more so, because the hype around AI makes it harder to be objective about results.

The Vendor Question

The AI vendor landscape is chaotic and fast-moving. The platform you choose today might not exist in two years. This makes vendor selection genuinely difficult, and the traditional approach of deep evaluation and long-term commitment doesn't work well.

My approach has been to minimise lock-in wherever possible. Use abstraction layers. Keep your prompts and workflows portable. Avoid building critical business logic that depends on a specific model's behaviour. Treat AI vendors the way you'd treat any rapidly evolving dependency, with appropriate caution and exit planning.

Saying "Not Yet"

The hardest part of an AI strategy is the things you decide not to do. There will be pressure, from executives, from competitors, from the market, to adopt AI in places where it doesn't yet make sense. A good strategy gives you the framework to say "not yet" with confidence: "Our diagnosis shows that this problem doesn't have the characteristics that make AI effective, and our guiding policies say we don't invest without a clear value hypothesis."

That's not being a Luddite. That's being strategic. And it's the difference between an AI strategy and an AI wish list.