Your Business Doesn't Need an AI Strategy. It Needs an AI Decision.
Most AI strategy documents describe a destination without naming a first step. The useful question is smaller and harder: which single decision in your business should stop being made by hand?
Most organisations approach artificial intelligence the same way: a strategy document, a steering committee, a survey of what competitors are announcing. Six months later there is a slide deck and no system running in production.
The document isn't the problem. The altitude is. "We will become an AI-driven organisation" cannot be built, tested, or shipped. A decision can.
So start there. Somewhere in your business is a decision that a person makes over and over, using information you already collect. Which incoming CV goes to the hiring manager. Which invoice looks wrong. Which customer is about to leave. Which stock item is about to run out. Which support message needs a human and which one has been answered identically four hundred times.
Every one of those is a candidate. Very few of them are good candidates. Three questions separate them.
Is the decision actually repeated?
Automation earns its cost through volume. A judgment call made twice a year, with different context each time, is a poor target no matter how tempting it looks- you will spend more time specifying it than you will ever recover. A judgment made two hundred times a week, largely the same way each time, is where the return lives.
Repetition also gives you something subtler: examples. A decision made two hundred times a week has a history of two hundred outcomes a week, and that history is the raw material a model learns from.
Does the data already exist, in a form someone can point to?
This is where most promising projects quietly stall. The decision is repeated, the logic is clear, and the information the decision depends on lives in three systems, two spreadsheets, and the head of one person who has been there eleven years.
Notice this is not an AI problem. It is a data engineering problem wearing an AI costume, and it has to be solved first regardless of what you build on top. That is usually the real first project- and it is worth doing on its own merits, because the reporting you have wanted for two years falls out of it as a side effect.
If the answer is wrong, what happens?
Models are probabilistic. They will be wrong sometimes. The question is not whether you can prevent that- you can't- but whether the surrounding process can absorb it.
Ranking candidates so a recruiter reviews the top of the list first is recoverable: a human sees every consequential outcome. Auto-rejecting candidates is not. Flagging a transaction for review is recoverable. Blocking it silently is not. Suggesting a reorder quantity is recoverable. Placing the order automatically, at 2am, is a decision about your working capital.
The pattern is consistent: the best early deployments put the model in front of a human, not instead of one. It shortens the queue rather than removing the reviewer. That earns trust, and trust is what buys you permission to automate more later.
What this looks like in practice
A first AI project should be legible enough to explain in a sentence, small enough to ship in weeks rather than quarters, and instrumented well enough that you can tell whether it worked. It should produce a measurable change in one process, owned by one person who cares about that process.
That is a far less impressive thing to announce than an AI strategy. It is also the only version that ends with something running.
