You have several ideas for using AI: prepare reports, sort requests, reduce copying between systems. Each sounds useful in a presentation. Which one deserves a pilot?
Choose a task with a specific problem, usable inputs, an output someone can check and a practical reason to try AI. Compare it with the simplest plausible improvement to the current method. The result may be a limited test, a prerequisite to resolve first, or a decision to solve the problem another way.
Here is a practical selection exercise for a team considering AI assistance with drafting or classifying everyday work. It helps you decide what to test; it does not establish that the proposed tool will help.
Start with a work problem you can describe
“Use AI in customer operations” is too broad to investigate. “Prepare a category and routing explanation for routine internal service requests” identifies a task whose inputs and output you can examine.
For each idea, write down who needs the result and what currently makes it difficult to produce. The UK Government's AI Playbook recommends choosing use cases from business and user needs and assessing their feasibility, including whether established technology would solve the problem. Its public-sector guidance provides a useful starting principle for this exercise. UK Government AI Playbook.
Bring together the person doing the task and someone who receives or checks the result. Ask them to walk through a recent completed example and one that was difficult or returned for correction. These examples help you form questions; they are not a representative sample of the team's work.
Keep the conversation concrete:
- What starts the task, and what counts as finished?
- Where does someone spend effort interpreting information, copying it or checking it?
- Where does the work wait for missing information or a decision?
- What does the current method already do well?
- What change has the team already tried?
The GOV.UK Service Manual recommends learning how people complete a task through observation, interviews and existing records. Applying that approach here means understanding the work before picking a tool. Use examples you are permitted to examine and record only what you need for the selection decision. User research in discovery.
Start with a short list of candidate tasks. You need enough contrast to make a choice, without trying to map every activity in the company.
Give the existing method a fair alternative
For each candidate, name a change you could make without AI: a required field, a saved view, a template, a rule, an import or a clearer owner.
Then state what AI might contribute beyond that change. For example, varied free-text requests might make a drafting aid worth investigating. Copying the same structured fields between systems may be better addressed by an existing import. Neither possibility is a result until you check the actual workflow and available tools.
Be especially careful with late work. If a request waits because the required information has not arrived, producing a draft faster may leave the delay untouched.
You do not have to force every candidate into an AI pilot. NIST's voluntary AI Risk Management Framework Playbook includes considering viable non-AI approaches alongside the resources needed to manage AI risk. NIST Playbook: Manage 2.1.
Check whether a bounded test is possible
A promising idea can still be unready to test. Before comparing candidates, answer these questions for each one:
| Selection question | What you need to establish |
|---|---|
| Can we use the inputs? | Identify the source material and whether its use in the proposed tool and test is permitted. Access to a file alone does not settle that question. |
| Can we recognize an acceptable result? | Describe the output and the source or standard against which someone can check it. |
| Who can review it? | Identify a person with the relevant knowledge, access to the source and time to examine the output. |
| What could an error change? | Consider who could be affected, whether the error would be detectable and how the test can contain its consequences. |
| Where does the test stop? | Specify the included work, excluded decisions and the current method that remains available. |
These questions adapt NIST's emphasis on defining tasks, context, oversight and the costs of errors. They are a practical selection aid, not a certification or a substitute for your organization's approval process. A narrow scope and a named reviewer do not make a task automatically safe. NIST AI RMF Core: Map.
An unresolved prerequisite needs an owner and a next action. Do not give an idea a high “impact” score and let that cancel out missing input permission or an unavailable reviewer.
Compare three ideas from one team
Consider a fictional internal service team in a larger company. After discussing recent work, it has three proposals:
| Proposed task | What the team finds | Selection decision |
|---|---|---|
| Copy request fields into a weekly tracker | The fields are already structured. The team has not checked whether its existing export and import can carry them across. | Investigate the existing import first. There is no established reason to add AI to this step yet. |
| Draft a category and routing explanation for routine requests | Recent requests needed category corrections after coordinators interpreted their wording differently. The category definitions are agreed. A qualified reviewer is available, and the example set is permitted for use in the proposed tool and test. | Plan a limited drafting test. Compare it with the current category guide and template; the coordinator retains the routing decision. |
| Decide exceptions to access policy | Some rules conflict and the responsible approval owner is unclear. A wrong decision could grant access that should have been refused. | Defer the proposal. Resolve policy and ownership before considering a clearly defined use case. |
The second task is selected because the team has a specific difficulty and the means to examine a proposed solution. The exercise has not shown that AI categorizes requests accurately or reduces effort. It has made that question testable.
If two candidates are ready, compare the evidence that each problem matters: how often it arises, who needs the result, what it disrupts and whether that account is supported by recent work. Prefer a useful question you can investigate with manageable disruption over a large claim you cannot yet check. This is a practical judgment, not a formula for finding the highest-return project.
Write the selection brief before starting
A short record makes the choice reviewable. Here is a filled example for the fictional routing task; replace each entry with your team's evidence.
| Field | Example selection brief |
|---|---|
| Work problem and recipient | Service coordinators prepare categories and routing explanations for the receiving team. In recent work, inconsistent interpretations of request descriptions led to category corrections. |
| Evidence and limits | Completed and corrected requests show where initial category choices changed during review. The team has not yet established how common the difficulty is across all requests. |
| Current method and simpler option | Category guide plus a standard explanation template; check whether clearer intake questions would remove the ambiguity. |
| Proposed AI contribution | Prepare a category suggestion and an explanation tied to the request and category guide. |
| Test boundary | Use the example set permitted for the proposed tool and draft-review test. Do not send messages, route live requests or change access. Leave unclear cases for the coordinator. |
| Owner and reviewer | The service operations lead owns the test; the designated coordinator checks each draft against the request and guide. |
| Decision and reason | Plan a limited test: recent category corrections give us a specific problem to investigate, and the agreed guide and reviewer make outputs checkable. Benefit remains unproven. |
| Unanswered question | Does assistance produce a usable routing draft with less total work than the current guide and template, including checking and correction? |
| Next action | Check whether clearer intake questions resolve the problem. If it remains, confirm the permitted setup and reviewer time, then define the comparison and acceptance criteria before running it. |
Keep the decision brief if you choose a simpler change or defer the idea, too. Record what you selected, why, and what evidence would justify revisiting it. That gives the team a concrete next step even when the next step is not an AI pilot.