Practical guide

Find an AI use case by tracing a real work decision

An AI use case is worth exploring when a recurring task has a clear owner, a useful output, available and permitted inputs, a way to check the result, and a failure the team can recognize. Start with the work decision rather than the tool feature or a list of prompts. Discovery should produce a bounded candidate card and a decision to investigate, redesign, defer or decline. It is not a forecast.

By Two Prune

An AI use case is worth exploring when a recurring task has a clear owner, a useful output, available and permitted inputs, a way to check the result, and a failure the team can recognize. Start with the work decision rather than the tool feature or a list of prompts. Discovery should produce a bounded candidate card and a decision to investigate, redesign, defer or decline. It is not a forecast of productivity or permission to place sensitive data in a model.

Observe the work before listing possibilities

Ask a worker to walk through one recent instance of the task. What triggered it? Which documents, systems and people supplied the inputs? What did the worker deliver, to whom, and what happened if the result was wrong? Identify the slow or error-prone step, but also the human judgment that should remain. A task with several handoffs may be better improved by fixing access or policy before adding AI. Capture a real example and its source locations without copying confidential material into an unapproved discovery tool.

NIST's AI Risk Management Framework Core frames the Map function around intended purpose, context, users, potential benefits, risks and human oversight. The UK Government AI Playbook advises examining whether AI is suitable for the problem and considering alternatives and impacts. Both are broader organizational guidance; neither supplies a ready-made ranking of use cases for this team.

Sources: [1] [2]

Build a candidate card with a disqualifier

Consider a synthetic customer-operations team that creates a weekly summary of recurring support questions. The worker currently reads approved, anonymized theme notes, groups similar issues and drafts a manager brief. A possible AI contribution is a first-pass grouping and draft outline from those notes. The human still decides whether two complaints are truly the same issue, checks counts against the underlying log, and signs off the recommendation. The card names the task owner, audience, approved input set, output, AI contribution, retained human decision, check method and stop condition.

The stop condition matters. In this fictional case, if the only available notes contain identifiable customer stories without approved handling, the candidate is deferred until the responsible data owner provides an authorized route or a synthetic pack. If counts cannot be reproduced from the source log, do not publish the AI-generated trend statement. The card also records a non-AI alternative: a better tag taxonomy or a simple spreadsheet pivot may solve the grouping problem. The discovery question is whether AI adds a specific useful step under the constraints, not whether AI can produce plausible prose.

Compare candidates on evidence and reversibility

Use a small decision table, not an inflated score. For each candidate, record task frequency, consequence of error, input readiness, checkability, owner, and whether a narrow reversible trial is possible. A weekly summary made from approved synthetic notes may be suitable for a controlled exercise; an unsupervised message to customers may not be. The comparison should include the work someone must do to verify output. Moving effort from drafting to review can be worthwhile in some contexts, but it is not automatically a gain.

For the example, the team chooses “investigate” rather than “deploy.” The next step is to run a synthetic exercise with two known duplicates and one deceptively similar but distinct issue. The acceptance question is whether the worker can correct the grouping and cite the notes in a brief. A poor result would lead to a narrower task, a better source pack or a decision to decline, not a claim that the organization has failed at AI adoption. NIST's Map playbook discusses documenting use context, assumptions and limitations; the candidate card is our illustrative way to keep those elements visible during a small discovery exercise.

Sources: [3]

Hand the candidate to the right owner

Before any pilot, the operational owner checks that the task is worth changing; the data and security owners decide whether materials and tooling are permitted; the end user tests whether the output actually helps them complete the work. Record who can halt the exercise and how feedback will change the brief. A candidate card without an owner or verification route is not ready merely because the model can draft an answer. Revisit the card if the source set, audience, tool, or error consequence changes.

This guide covers early use-case discovery for knowledge work. It does not establish deployment approval, legal compliance, measured return on investment, or a universal priority order. Two Prune may use a synthetic case to observe how a participant frames and checks an AI-assisted task; the resulting report describes bounded assessment evidence for human interpretation, not the success of a live customer rollout.

Sources

  1. 1.NIST's AI Risk Management Framework Core · National Institute of Standards and Technology
  2. 2.The UK Government AI Playbook · UK Government
  3. 3.NIST's Map playbook · National Institute of Standards and Technology