AI strategy starts with the decisions that matter

An AI strategy should begin with the decisions an organisation needs to improve. Choosing a model, buying licences, and asking every department for use cases can create activity quickly. They do not establish why one application deserves scarce investment before another. Leaders need a business argument that survives a change of vendor or technology.

My starting point is a decision with a recognisable consequence: committing a delivery date, allocating constrained material, assessing a service exception, or deciding which maintenance work takes priority. Each has an owner, an information requirement, and a cost when the decision is late or wrong. Those features give an AI proposal something concrete to improve.

Build a decision brief before a technology brief

For a delivery commitment, the central problem might be that planners cannot reconcile inventory, capacity, and engineering changes quickly enough. The first question is whether the available information supports a reliable answer. An AI assistant could explain conflicting records while a conventional planning system performs the underlying calculation. The useful design may combine several methods.

I would ask the business owner to document the current decision, its frequency, the people involved, the evidence they use, and the consequences of error. The brief should also explain what an improved decision would enable. A faster answer has limited value if the organisation still lacks authority to act on it or the answer arrives after a commitment has become irreversible.

This discipline separates a genuine decision problem from a process that simply needs clearer rules. If the same exception can be resolved through an agreed threshold and dependable data, a small process change may be enough. AI remains an option to evaluate against that simpler alternative. The comparison should include the work required to maintain either approach.

Prioritise the surrounding capability

In my CEAF capstone, I proposed tracing AI from strategic objectives into enterprise capabilities and execution. Applied to investment, that means looking beyond the model. A proposal depends on data ownership, workflow integration, employee judgment, monitoring, and support. Weakness in one of these areas can become the binding constraint on value.

Consider two proposed uses. One promises a large theoretical saving but depends on information nobody maintains consistently. The other addresses a smaller, recurring decision with clear ownership and usable records. The second may offer a more credible starting point. That does not eliminate the first; it identifies the capability work that must precede it.

The portfolio should therefore distinguish experiments from operational commitments. An experiment earns funding to answer a question. An operational service earns funding to deliver a defined outcome within agreed limits. Treating both as the same kind of project obscures what evidence the organisation should expect and when it should stop spending.

Make the strategic choice visible

Each funded initiative needs a business owner, a baseline, an evaluation period, and a decision about continuation. The owner should be able to explain the intended benefit without referring to model size or technical novelty. Better commitment reliability, fewer avoidable escalations, or reduced time resolving an exception are possible objectives; the appropriate measure depends on the work.

A leadership review should compare these commitments with the capabilities the strategy needs most. It should also identify proposals being deferred and why. That makes the AI agenda an expression of strategic choice rather than a collection of independently attractive demonstrations.

The test I would apply is straightforward: if the technology name disappeared from the proposal, would its business purpose remain clear? When the answer is yes, the organisation has a foundation for choosing technology intelligently.