Sometimes the answer is AI. Often it is not
Most AI programmes fail before any technology is involved, at the point where nobody wrote the business problem down. This practice takes the question seriously in both directions, including the direction where a process change, a data fix or a better-run supplier gets you there faster and cheaper.
The costume, and the question underneath it
An AI question usually arrives already answered. The board has seen a demonstration, a competitor has issued a press release, and the brief that lands is "what is our AI strategy" rather than "what is the problem we are trying to solve".
Turned back around, a good number of these are questions about data quality, process design or decision rights, with AI as one candidate lever among several. Some of them genuinely are AI questions, and those deserve to be done properly rather than piloted into the ground.
Telling the two apart early is worth more than any model or tooling decision made later.
Four kinds of work, only some of which end in a model
Only two of these necessarily end with anything deployed, and that is the point of doing them in this order.
Use case discovery and prioritisation
Which candidates are worth funding, ranked on value you could actually realise rather than on novelty, and which are better solved without AI in them at all.
The data foundation underneath it
Whether your data can support the use case you have in mind. This is where programmes discover a year of work nobody costed, usually after the licence is signed.
Governance and regulatory exposure
EU AI Act risk tiering, board oversight, and being able to answer an auditor's question without a scramble, built in at the start rather than retrofitted after go-live.
Vendor and tool portfolio
Consolidating an estate that accumulated one individually-justified purchase at a time, and reviewing AI vendor contracts commercially before they quietly renew.
We will tell you when the answer is not AI
There is no model here to sell, no platform partnership, and nothing that pays better if the recommendation is more ambitious. Where the honest answer is a process change, a data fix, or leaving it alone this year, that is the answer you get.
It is an odd thing for an AI practice to say out loud. It is also the only reason the recommendation is worth anything on the occasions it does point at AI.
A scored baseline, before a roadmap
The AI Readiness Assessment scores seven dimensions: strategy and sponsorship, use case suitability, data quality, data architecture, application and technology architecture, delivery capability, and governance and risk. It puts a report in your inbox with no call attached to it.
It is a self-assessment and directional by design. The full audit reviews the actual data, systems and documentation against those same seven dimensions, which is a different depth of answer to the same question.
Either way the sequence holds: know where you stand before you fund a roadmap, and know what the roadmap is for before you choose anything to build it with.
AI questions are rarely only AI questions
A use case is limited by the data underneath it and by who is allowed to act on what it produces. That is two other disciplines, and pretending otherwise is how pilots stall.
Who leads this work
Board-level ownership of AI: governance, the portfolio, and deciding what gets shut down.
See the leadershipWhy 97% cannot show AI value
Why the gap between adoption and demonstrable value is widening rather than closing.
Read the researchThe estate underneath it
Data architecture, integration and the run cost of whatever an AI roadmap adds to the estate.
See the practiceStart by finding out where you actually stand
Seven dimensions, a scored report, and an honest answer about whether AI is the right lever for the problem you have. Or, if you would rather just describe the problem, a direct conversation about it.