Many organisations come to me with a concrete idea: a document should be analysed automatically, an assistant should prepare answers, or a process should become AI-supported. The motivation is understandable. Not every one of these ideas should become an initiative.
A sound use case needs more than an impressive workshop. It needs a clear point of friction, a role that benefits, and an environment in which the result can be operated responsibly.
When no is more useful than a pilot
I more often advise against building when one of these signals dominates:
1. The process is not stable enough yet
When the underlying workflow is still unclear, AI tends to amplify ambiguity rather than quality. Process work should come first — not model selection.
2. The data basis is not approved
Without clear permissions, sources, and freshness, you quickly get a solution that works technically but cannot be owned operationally.
3. The expected benefit depends on perfection
If the initiative only makes sense when the system is right in almost every case, the use case is usually too broad or too risky as a starting point.
4. Nobody owns operations
A prototype without later accountability for quality, adjustments, and questions remains an experiment — regardless of model quality.
What helps instead
Rather than building immediately, a tighter step often pays off: define the use case in writing, name the role affected, review the data sources, and agree which signal would show that a pilot is worthwhile.
Sometimes that leads to a smaller, more viable initiative. Sometimes to the insight that the right next step is not AI at all.
Both are useful outcomes.