How to choose your first AI use case

Start with a workflow, not a technology

A dependable starting point is a piece of work that already happens in your organisation: a process people follow, the time it takes and the places it goes wrong. You do not need an AI strategy before you begin. You need a problem worth solving and someone who understands how the work is done today.

Starting from the technology tends to produce demonstrations. Starting from the workflow produces something a team can use.

Ask whether the problem needs AI at all

Some problems that arrive labelled as AI are better served by something simpler. If the steps are predictable and the rules can be written down, a structured form, a clear approval flow or a straightforward rule may do the job with less risk and less upkeep.

AI earns its place where the work involves language, judgement or unstructured information: searching internal knowledge, handling documents that all look slightly different, summarising long material, or helping people make sense of a large volume of text.

Compare candidates on usefulness, feasibility and effort

With a shortlist in hand, look at each idea in the same three ways.

• Usefulness: who benefits, how often the task comes up, and what changes for them if it becomes easier.
• Feasibility: whether the data exists, whether you are permitted to use it, and whether the systems involved can be reached.
• Effort to validate: how much work it would take to find out whether the idea holds up.

A good first use case does well on all three. An idea with a large payoff that would take a very long time to test is a poor first step, however attractive it looks on paper.

Check the data and the constraints early

Before anyone builds anything, map what the use case depends on. What data does it need, and where does that data live? Who is allowed to see it? Does it include personal or confidential information? Which systems would it read from or write to?

The answers decide whether an idea is practical, and they often change which provider or deployment approach is suitable. It is better to settle them during scoping than to discover them halfway through a build.

Decide where people stay in the loop

AI output can be wrong while sounding confident. For a first use case, choose work where a person reviews the result before it matters: a draft someone edits, a suggestion someone approves, a search result someone checks.

Being explicit about that review step, and about what the system is not allowed to do, makes the first project safer and makes it easier for the team to trust the result.

Define a small test before a big build

Once you have a candidate, write down the single question a proof of concept should answer and what a good result would look like. Keep it narrow: one workflow, one group of users and a limited set of data.

If the test works, you have evidence for a pilot and a clearer picture of what a full build involves. If it does not, you have learned that without committing to a programme.