‘We want AI’ is a statement about a tool, not a problem definition. Behind it may sit unanswered messages, difficult document searches or pressure to produce content. These are different problems requiring different kinds of support. A valuable application starts by identifying who needs help, at which moment and with which task. Only then does choosing a model become a useful conversation.
Separate a specific task from a broad ambition
Suppose an organization wants better customer support. ‘Build an intelligent assistant’ does not yet explain the difficulty. Perhaps staff cannot access product information, return rules are unclear, or repetitive questions consume attention. A narrower goal could be finding a draft answer from approved documents, with the final decision remaining with an agent. This is a hypothetical example, not a claim about a completed client project.
The MAP function in NIST's voluntary framework addresses the use context, purpose and business value. The practical proposal here is a problem sentence: this person faces this obstacle while doing this task and needs this kind of help. That sentence should make sense without naming a model. NIST: the AI risk-management core
- Decision
- Relevant data
- Simpler alternative
- Limited experiment
Put simpler alternatives on the table
For that example, clearer answers, better search or a revised policy might resolve part of the difficulty. Comparing alternatives is not opposition to AI; it helps establish what AI would add. If a model simply restates disorganized information with confidence, the original problem remains, and responsibility for the answer can become less clear. The comparison should concern usable work, not impressive output.
GOV.UK's technology-selection principle includes ownership cost and the ability to change choices later. Our comparison therefore extends beyond subscription price: consider data preparation, evaluation, human review, support and an exit route. A tool that is easy to start using is not necessarily easy to operate responsibly. GOV.UK: choosing and sustaining technology
Define errors and authority before deployment
In customer support, an unsuitable draft is not the same as a false promise already sent to a customer. Specify what the model only suggests, what it may not do and when it must hand work to a person. Reviewers need actual time and access to verify a result. Writing ‘human review’ in a document does not, by itself, create an operational control.
NIST's generative-AI profile addresses evaluation in relevant use conditions and verification of output sources. The interpretation here is to build test examples covering ordinary questions, incomplete information and requests outside the system's authority. Assess fluency separately from correctness, supportability and practical usefulness. NIST: the generative-AI risk profile
A pilot must be allowed to stop
Compare a limited pilot with the current method, not an idealized future. Can staff find an answer? Does reviewing it create additional work? What happens when it is uncertain? Which information must stay outside the tool? Before starting, name the person who can decide to continue, revise or stop, so the appeal of a demonstration cannot replace evidence.
A pilot's useful outcome can be modest and specific: dependable help with a bounded task and errors that can be noticed and corrected. Expanding the application is another decision requiring further evaluation. If a clear rule or improved workflow turns out to be the better answer, that is progress too. The goal is not possession of AI; it is better work for the people involved.