You do not need an AI strategy. You need one process that works better than it did last month, and you need to be able to point at it.
The strategy deck comes later, if ever. This is not anti-ambition — it is the observation that almost everything which has actually worked started as one system, and almost everything that failed started as a programme.
Why "AI strategy" is usually the wrong first move
A strategy is a set of decisions about things you have not done yet. Made before you have done any of them, it is a set of guesses arranged in a document, and its main product is delay: workshops, a roadmap, a steering group, and eighteen months later nothing in the business runs differently.
The figure that ought to inform this is that roughly 95% of enterprise AI pilots never reach production. Most of those had a strategy. What they lacked was one thing shipped and running with real users, from which the next decision could actually be made.
Pick one process
The criteria are dull and they work. It should be something that happens often, where mistakes cost you something, that takes real hours, and — the one people skip — where you would notice within a week if it went wrong.
That last criterion is the whole trick. A fast feedback loop means you find out quickly whether this was a good idea, and being wrong costs you a fortnight instead of a year.
Deliberately not on the list: whether it is impressive, whether it uses the newest model, and whether it would demo well. None of those predict whether it will still be running in six months.
Make it real, then look
Build the smallest version that does the actual job for actual people. Not a proof of concept, not a pilot with three friendly users — the real thing, doing the real work, with the failure cases handled.
Then wait, and watch what happens. What broke. What people worked around. What they asked for next. This is information you cannot get any other way, and it is worth more than any amount of planning, because it is about your business rather than about businesses in general.
After two or three of those, you will have a strategy. It will have been derived rather than imagined, and you will be able to defend every line of it.
What this is not
It is not "move fast and break things". The one system you build has to be built properly — the access rules right, the failures loud, the records kept — because a small system doing real work with real data carries real risk. Small scope, full standard.
Nor is it an argument that AI is always the answer. Frequently the honest finding is that the process needs connecting rather than predicting, and the right build has no model in it at all. That is a good outcome, arrived at cheaply.
The first question to ask
Not "where could we use AI?" — that question has too many answers and no way to choose between them.
Ask instead: what is the most annoying thing that happens in this business every week? Then ask what it would take to make it stop. The answer to that is a project, it fits in a quarter, and it produces something you can point at.
The Reality Check is that question asked properly: one week, a fixed fee, and a written answer about your business — including, when it is true, that you should do nothing yet.
This is the part we do — the crossing from a demo to a system that survives production.