Most organizations approaching artificial intelligence ask a version of the same question: which use case should we start with? It is a reasonable question and it is usually the wrong one to answer first, because the constraint is rarely imagination. It is almost always the data underneath.
A generative AI assistant that answers questions about internal policy is a straightforward idea. It becomes difficult the moment you ask which policy documents are current, who is entitled to see each one, and what happens when two of them disagree. A predictive model that flags cases needing attention is a straightforward idea until you discover that the field it would depend on is populated by hand and is empty a third of the time.
None of that is an argument against adopting AI. It is an argument for asking a different set of questions before committing to a use case.
Five questions worth answering first
1. What decision or task would this actually change?
“Improve efficiency” is not an answer that can be designed against. “Reduce the time between a request arriving and a case worker having the information needed to act on it” is. The more specifically the target is stated, the easier it becomes to tell whether the result worked — and the easier it becomes to notice when it stops working.
2. Does the data exist, and is it trustworthy?
Ask where the information would come from, how current it is, how consistently it is populated, and whether the same entity is described the same way across the systems involved. This question ends more AI proposals than any other, and it ends them cheaply — which is far better than discovering the answer after the build.
3. Is the organization permitted to use it this way?
Data that exists is not always data you may use for a new purpose. Contractual restrictions, privacy obligations and the terms under which information was originally collected all constrain what can legitimately be done. Establishing this early is considerably less painful than establishing it during review.
4. Who is accountable when the output is wrong?
Every system that produces judgments produces some wrong ones. The question is not whether that will happen but who owns the consequence when it does, and what mechanism exists for a person to notice and intervene. If the honest answer is that nobody in particular owns it, the design is not finished.
5. How will you know whether it is working?
Model quality degrades as the world changes around it. Deciding in advance what would be measured, how often, and what threshold would trigger review turns that from a surprise into a routine operational activity.
Readiness is usually a data problem wearing an AI costume
Working through those questions tends to produce one of three outcomes. Sometimes the use case is sound and the data supports it, and the work can proceed. Sometimes the use case is sound but the data is not ready, in which case the honest first project is a data project — less exciting, and the only route to the thing that was actually wanted. And sometimes the use case does not survive contact with the questions at all, which is a good outcome discovered cheaply.
The organizations that get the most from artificial intelligence are rarely the ones that started earliest. They are the ones that were honest with themselves about which of those three situations they were in.
Starting smaller than feels satisfying
A narrow first application — one process, one department, one clearly bounded decision, with a person reviewing the output — teaches an organization more than a broad programme does. It surfaces the data problems at a survivable scale. It establishes the governance patterns while the stakes are low. And it produces something people actually use, which is the only evidence that ultimately matters.
The ambition can be large. The first deployment should not be.