---
title: "AI adoption: how to choose your first use case"
url: https://zerofive.ai/en/blog/strategy/ai-adoption-choose-first-use-case
canonical: https://zerofive.ai/en/blog/strategy/ai-adoption-choose-first-use-case
language: en
published: 2026-09-11
updated: 2026-09-18
author: "ZeroFive.AI"
tags: AI adoption, AI use cases
abstract: "Choose your first AI use case using value, data, feasibility and risk. A practical worksheet and acceptance criteria for a measurable pilot."
---

# AI adoption: how to choose your first use case

**Choose your first AI use case for its testability, not the impact of its demo.** It needs an accountable owner, an observable process, usable data and an outcome that can be compared with current work. Assess value, feasibility and risk together: a large potential benefit cannot compensate for missing controls.

## From ideas to a decision

A document assistant, request classification and quotation drafting are candidates, not projects. To become projects, they must specify who uses the output, which activity changes and which decision remains human. Start by asking which process step should improve and how the organisation will recognise that improvement.

The [AI adoption guide](/en/ai-adoption) explains the broader journey. This article addresses a narrower decision: selecting an experiment that produces useful investment evidence.

## The selection worksheet

| Dimension | Evidence required | Decision question |
|---|---|---|
| Value | Volumes, current time, rework | Which cost or outcome could change? |
| Feasibility | System access and skills | Can we test without rebuilding the process? |
| Data | Representative sample and permissions | May these data be used for this purpose? |
| Risk | Impact, reversibility, controls | Can we detect and correct an error? |
| Adoption | Named owner and involved users | Who will use the output in actual work? |

Rate each dimension with a reason: evidence available, partial or absent. A summary score supports discussion but must not hide a blocking constraint. Missing rights to data require a data decision before an experiment.

## Constraints before ranking

The [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) distinguishes Govern, Map, Measure and Manage. It is a voluntary reference for organising risk management and measurement, not a certification. Before ranking ideas, define context, affected people and responsibilities.

A decision affecting people calls for different attention from an internal draft. Check applicable law with the relevant functions: a prioritisation matrix does not replace legal classification. For personal data, purpose, minimisation and security remain separate from model quality.

## Hypothetical example: incoming request classification

A company considers a system that suggests a request category. Operators can change the suggestion, and it is not sent to the customer. The service owner gathers ordinary, ambiguous and rare requests, defines categories and compares automated assignments with reviewed labels.

The hypothesis is not merely that the model classifies accurately. It is that the complete process takes less time while maintaining an error level agreed beforehand. Review time and corrections therefore matter too. This is an illustrative example, not a customer result.

| Worksheet item | Example to complete before testing |
|---|---|
| Owner | Person accountable for request handling |
| Baseline | Time and quality measured in the current process |
| Sample | Representative requests, separate from development examples |
| Measures | Errors by category, total time, corrections |
| Oversight | Operator confirmation before routing |
| Stop condition | Agreed threshold for critical errors or unavailability |

## Writing acceptance criteria

A complete criterion names a measure, sample, threshold, verifier and consequence. Thresholds depend on the cost of error and current quality, not another company’s pilot. Distinguish recoverable errors from mistakes with hard-to-reverse consequences.

Keep improvement data separate from final evaluation data. Record model version, instructions and sources so that later changes can be compared. Include inexperienced users and incomplete inputs rather than only well-written requests.

## Moving into real work

A successful experiment supports a decision, not automatic rollout. Production requires access controls, incident handling, cost monitoring and an alternative process when the system is unavailable. The owner must be able to suspend use without blocking essential work.

Training should explain when to accept a suggestion, when to inspect sources and when to involve a qualified person. Tool logins alone do not show whether the work improved.

## Selection meeting checklist

- A specific process and named owner.
- An observed baseline rather than an impression.
- Accessible data usable for the intended purpose.
- An evaluation sample containing difficult cases.
- Thresholds agreed before seeing results.
- Human oversight and a recovery path.
- An explicit decision: proceed, revise or stop.

Where these are missing, complete the worksheet before buying more licences. [AI Assessment](/en/services/ai-assessment) connects processes and opportunities; [PROTOT.AI](/en/protot-ai) provides the validation gate before production. Read [budgeting from pilot to production](/en/blog/strategy/ai-project-budget-pilot-production) for the wider commitment.

Start with a [company self-assessment](/en/start-ai-rating) or [book an assessment meeting](https://calendly.com/fabiolalli/zerofive).