What you can explore
1. What problem would this solve?
Everyone has AI ideas, but there is no agreed first task or safe starting point. Teams often propose too many experiments at once. This review narrows the choice to one task with a clear source, owner, permitted example and human check.
2. What could become easier?
- See which everyday tasks are suitable.
- Avoid experimenting with restricted information.
- Choose one achievable next step.
The aim is to make a clearer decision, with practical checks before relying on AI output.
3. What practical support could include
A possible starting point: A first-use-case discovery and task-ranking discussion. A scoped engagement might produce:
- Task inventory with exclusions
- Five-factor first-task scoring sheet
- A shortlist of suitable experiments
- Data-permission and review checklist
- Next-task recommendation with open questions
Any practical support would be scoped to the task, available information and agreed responsibilities.
4. Why this approach?
We compare a small number of candidates on repeatability, evidence, consequences and review readiness. A simple spreadsheet score can expose disagreements, but never overrides data restrictions.
5. What evidence supports these recommendations?
The accompanying example separates discovery from pilot design and company-wide planning. Published NIST guidance provides a framework for considering risk; it does not endorse a specific service.
6. How might we work together?
Describe three work tasks; rank them; exclude prohibited uses; record the first experiment worth considering.
Practical guide: how to make this decision
Worked sample: choose one sensible first AI task
The following worksheet is illustrative, not a measured customer result. A business owner lists three tasks and scores each from 1 (unfavourable) to 5 (favourable) against four questions: repetition (25%), availability of approved source material (30%), ease of human review (25%), and reversibility (20%). Separately, a hard exclusion applies if sensitive information lacks an approved handling route, a required decision has no accountable owner, or a result could cause material harm without review.
| Candidate task |
Repetition |
Source readiness |
Reviewability |
Reversibility |
Weighted example score |
Exclusion |
| Draft a weekly update from approved notes |
4 |
5 |
5 |
5 |
4.75 / 5 |
No, when notes are permitted |
| Classify generic public website questions |
5 |
4 |
4 |
5 |
4.45 / 5 |
No, with public answers and escalation |
| Decide customer eligibility automatically |
5 |
2 |
1 |
1 |
2.35 / 5 |
Yes: no accountable human sign-off |
Scores are not benchmarks and depend on locally agreed weights. An excluded task cannot be reinstated merely because its numeric score is high. A useful outcome is a scored shortlist with reasons, a no-go list, and one test owner—subject to an agreed engagement scope.
Evidence and important limits
- NIST describes voluntary cross-sector risk-management guidance, not certification of any particular product. [S01]
Evidence references
What is a sensible first AI task?
A sensible first task is one that staff already understand, can demonstrate with permitted examples, and can judge without treating the AI's answer as proof of its own correctness. Consider an office team that drafts routine replies to common customer questions. The team's goal is not simply to get an AI system to write a reply. It is to produce a response that uses the current approved policy, fits the customer's question and is checked before sending. A task with an obvious reviewer and verifiable source is easier to assess than a broad instruction to “transform customer service.” Choosing a first task is a discovery decision. It is not a commitment to deploy an agent or replace an existing system. NIST's voluntary AI Risk Management Framework Playbook organizes risk work through mapping, measuring and managing context-specific risks [PLAYBOOK].
Make a shortlist from ordinary work, not from product names
Ask each team for three examples: a repeated task, a typical input and what a finished result should look like. Request a fully synthetic or redacted example at this stage. Do not collect customer records through an ordinary enquiry form. Sort suggestions into three categories: drafting and brainstorming , finding or summarizing approved information , and taking actions in another system . The third category needs a separate review because changing an account, sending an external message or approving a transaction creates risks beyond a text draft. If a process is already solved reliably by a spreadsheet rule or template, record that fact. AI is not necessary merely because the task is repetitive. An existing guide on enterprise readiness can explain organizational preparation; the next decision is a ranked first-task shortlist, not a company-wide adoption programme.
Worked example: rank three candidate tasks
The following is an invented teaching example, not a client result. A small support team considers (A) drafting a response to an internal equipment request, (B) summarizing an approved handbook, and (C) independently approving a sensitive customer exception. For each task the team scores five characteristics on a 1–3 scale: repeatability, ease of checking, access to permitted information, impact of an error, and readiness of the responsible reviewer. For impact, 3 means lower consequence and 1 means higher consequence; thus higher total scores indicate a more suitable starting task. This is an illustrative worksheet, not a standardized risk score or formal security assessment.
| Task |
Repeatability |
Checkability |
Data permitted |
Lower consequence |
Reviewer ready |
Illustrative total |
| Draft internal equipment reply |
3 |
3 |
3 |
3 |
3 |
15 |
| Summarize current approved handbook |
3 |
3 |
2 |
2 |
3 |
13 |
| Automatically approve exception |
2 |
2 |
1 |
1 |
1 |
7 |
The scores represent assumptions for this worked example. They are not measurements. The exception-approval workflow is also a poor early candidate because decision authority, access controls and possible disputes need examination. Scores should never override a prohibition or missing permission. A task that fails the data-authorization gate must be excluded regardless of its total.
Five questions that make the shortlist useful
First, who uses the result? A private brainstorming note and a client-facing claim carry different consequences. Second, what is the reference answer? For a handbook question, a versioned document may be authoritative; for a strategic idea, a single correct answer may not exist. Third, what information can the tool receive? An approved public template is different from a personnel record. Fourth, who checks the output? Name the reviewer and explain what they must compare. Fifth, what happens if the result is wrong? An incorrect draft may be fixed before use, whereas a wrong automated action may require reversal or escalation. These questions reflect the importance of task context, human oversight and evaluation in NIST's risk guidance [NIST]. They also help explain why a product demonstration is not a complete business case.
Turn the winning task into a testable question
Replace a vague idea such as “use AI for email” with a narrow statement: “Can staff use an approved assistant to draft a response to a routine internal request, using only the approved response policy, with a named reviewer confirming the final text before sending?” Now specify three acceptance checks: the draft reflects the correct procedure, does not add invented commitments, and identifies uncertainty rather than guessing. Supply a small set of permitted examples representing routine questions and exceptions. Record what current manual handling looks like before the test. The comparison might consider completeness, reviewer effort, error severity and whether the proposed output is actually useful; do not assert that AI will improve every measure.
Exclude attractive but unsuitable starting points
A first use case should not depend on bypassing document access restrictions, guessing missing customer details or making irreversible decisions without a human. Do not choose recruitment scoring, credit decisions or health advice as a beginner exercise merely because the interface appears simple. These tasks may require specific sector, legal and fairness controls that are outside a general first-use-case conversation. Also reject projects that have no stable data source, no owner, no way to recognize an error or no permission to test representative records. A workshop can document those gaps without recommending deployment. Where the problem is confusing written instructions, rewriting the instructions may be better than introducing a model.
Which artifacts should be produced before any build?
The first artifact is a task card: team, trigger, input, expected output, responsible person and current check. The second is a permission card: public, internal approved or restricted data, with the actual organizational owner deciding the classification. Third is a sample pack plan describing ordinary, difficult and clearly out-of-scope examples, without copying restricted material. Fourth is a stop list: cases where a person must take over, where the source is missing or where the system must not act. Finally create a one-page decision stating which task warrants further analysis and which candidates should remain manual. These artifacts are valuable even if the organization chooses no AI tool at this stage.
Distinguish discovery from a pilot and from a roadmap
Discovery answers “Which task should we examine first?” A pilot answers “Does a defined method work well enough on this task under controlled conditions?” A wider roadmap answers “How should several teams, systems, responsibilities and dependencies be sequenced?” The three may be connected, but they are not interchangeable offers. A business that already has one selected task and an approved dataset may be ready for a pilot rather than a fresh discovery exercise. An organization coordinating several departments should consider the roadmap service. Routing visitors to the right outcome is more helpful than creating pages that promise the same generic planning work.
What a responsible recommendation looks like
A good recommendation identifies one bounded task, one alternative that might be simpler, a reason for the choice, the evidence that must be collected, and what remains unresolved. It should say “not ready” when access, safety or review arrangements are missing. It should make clear that neither the page's scoring grid nor a first conversation establishes product suitability, compliance or measurable return. The decision can be revisited when new information appears. The end of this exercise is an informed first choice and a practical question for the next stage—not a claim that an AI system has already been built or that a business outcome is guaranteed.
