Diagnose the work before buying AI
The responsible starting point is not a model or a tool. It is the repeated task, its cost, its exceptions, and the consequence of getting it wrong.
AI is not the business requirement
When leaders ask teams to “find an AI use case,” the tool has already been chosen before the problem is understood. Teams then search for work that can accommodate AI instead of examining which tasks consume time, create rework, produce inconsistent results, or constrain growth.
A better question is: “Which repeated task or decision creates enough cost, delay, or rework to justify intervention, and what is the most reliable way to improve it?” AI may be part of the answer. The better intervention may instead be a clearer process, a system integration, rules-based automation, better source data, or clearer ownership.
Start with the shape of the work
Before evaluating products, document how the task actually works: how often it occurs, how much the inputs vary, and what happens when the output is wrong. Stable, high-volume work may suit rules-based automation. Work involving variable language may be a better candidate for AI, provided the review process and failure controls match the risk.
- What exact input begins the work, and who supplies it?
- Which decisions are rules, and which require interpretation?
- Where are the exceptions, handoffs, and rework loops?
- What happens when the output is late, incomplete, or wrong?
- Who owns review, correction, and improvement after launch?
Prototype the uncertainty, not the easy path
A polished demonstration often emphasizes the normal path under controlled conditions. A useful pilot tests where the system is most likely to become unreliable: incomplete context, ambiguous requests, missing permissions, unfamiliar customer language, and decisions that depend on information the model cannot access.
Test the messy examples early and record why the system failed. Decide whether the remedy is better context, a narrower scope, a human checkpoint, a fixed rule, or stopping the experiment. A pilot is useful when it identifies failure patterns and gives the team enough evidence to continue, narrow, or stop the work.
The right answer may be smaller than the pitch
A narrowly scoped system that drafts, classifies, retrieves, or recommends can save time while leaving important decisions with a person. The entire workflow does not need to be autonomous to be useful.
Judge the work by whether it improves the workflow’s usefulness, reliability, cost, or speed—not simply by how many human steps it removes. Start with the work, make the economics and risk visible, and then choose the tool.