Most organisations we speak to are past the question of whether to use AI. The harder question is where to point it first — and that decision is being made badly, over and over, for a predictable reason.
Pilots are usually chosen by what is technically interesting or what a vendor demonstrated well. They are rarely chosen by which decision in the business is currently being made slowly, inconsistently, or with incomplete information. Those are two very different selection criteria, and they produce very different results twelve months later.
Start with a decision, not a capability
A useful discipline: before discussing models, write down the specific decision or task that will change. Not “improve customer service” but “the agent currently opens four systems to answer a billing question, and gets it wrong often enough that we re-contact.” That sentence tells you what good looks like, who is affected, and how you will know whether it worked.
If the sentence cannot be written, the use case is not ready. This is not bureaucracy — it is the cheapest possible way to discover that an idea has no owner and no measurable outcome, before a delivery team spends a quarter on it.
Three filters worth applying early
Frequency. A task performed hundreds of times a day tolerates a modest improvement far better than a task performed monthly. Small percentage gains compound where volume is high, and volume also gives you the evaluation data you will need.
Tolerance for being wrong. Every probabilistic system is sometimes wrong. The question is what happens next. Drafting an internal summary that a person reviews is a very different risk profile from an automated decision that reaches a customer or a regulator unreviewed. Early use cases should sit where a human is already in the loop, because that is where you can learn safely.
Data proximity. If the information the task depends on is already accessible, governed and reasonably clean, you are solving one problem. If it is spread across systems with unclear ownership, you are solving two — and the second one will dominate the timeline. That is not a reason to avoid the use case, but it is a reason to be honest about what you are signing up for.
The data conversation happens whether you plan for it or not
Teams are often surprised by how much of an AI initiative turns out to be data work. It should not be surprising. A system that reasons over your information inherits every ambiguity in that information: two definitions of “active customer”, a field that three regions populate differently, a document store where the current version is not obviously the current version.
None of this means a data programme must finish before AI can start. It means the first use case should be chosen partly for the data it touches, and the data work it exposes should be treated as part of the initiative rather than as an unwelcome discovery.
Design for the person who has to use it
Adoption is where value is actually realised, and it is consistently under-planned. A tool that produces a good answer but sits outside the workflow will be opened twice and then forgotten. The questions that matter are unglamorous: where does this appear in the person’s day, what does it replace, how do they correct it when it is wrong, and does correcting it make the system better or merely fix one instance.
The last point deserves attention. Feedback that goes nowhere trains people to stop giving it. If a user flags a bad output, something should visibly happen — a routing change, a prompt adjustment, an added source. That loop is the difference between a system that improves and one that quietly degrades as the business changes around it.
Oversight is a design input, not a review gate
Responsible use is easier to build in than to retrofit. Decide early what the system is allowed to do autonomously, what requires review, what is logged, and who can answer a customer or auditor asking why a particular output occurred. In regulated environments this is not optional, but even where it is not mandated it tends to be the thing that determines whether a successful pilot is allowed to scale.
What good progress looks like at ninety days
Not a model in production necessarily. More usefully: one clearly defined decision, a measured baseline for how it is made today, a working prototype in front of real users, an honest list of the data problems it surfaced, and agreement on what would justify expanding it. Teams that can produce that are in a much stronger position than teams with three impressive demos and no baseline to compare them against.
The organisations getting value from AI are not, in our experience, the ones with the most ambitious plans. They are the ones that picked a real problem, instrumented it, and were willing to learn something inconvenient in the first eight weeks.