Choosing your first AI use case

Start with the work, then consider the technology

The first question in an AI programme should be about the work: where does your team lose time, struggle to find information or repeat the same judgement? Starting with a named process makes it easier to decide whether AI is useful and whether another kind of automation would be simpler.

Describe the process in ordinary language. Identify its input, the person responsible, the decision being made and the result the business needs. If the process is unclear, spend time understanding it before choosing tools.

Look for a bounded opportunity

A focused pilot gives you room to learn without changing everything at once. An assistant that retrieves approved process guidance is easier to scope than a broad instruction to automate an entire department.

Choose boundaries deliberately: a defined set of documents, a limited group of users and a specific task. State what the solution should do when information is missing or confidence is low.

• Name the workflow and its owner.
• Define the information the solution may use.
• Identify the decisions that require human review.
• Set a clear route for handling exceptions.

Check readiness before committing to a build

Useful data is more than a collection of files. It needs to be accessible to the right people, current enough for the task and organised well enough to interpret. A pilot can expose gaps in those foundations.

Check whether the required systems offer suitable interfaces and whether data access can follow existing permissions. If a critical dependency is uncertain, treat resolving it as part of discovery rather than assuming it will work.

Agree how you will evaluate it

Capture a baseline for the task before introducing AI. Depending on the workflow, useful measures might include completion time, correction effort, exception rates or the ability to find a supported answer.

Create a representative evaluation set that includes difficult cases. Assess output quality, source accuracy and appropriate refusal alongside speed. Record where human review is required, rather than treating all generated output as ready to use.

Make the next decision explicit

A pilot should end with a decision, not just a demonstration. Agree whether the evidence supports expansion, another iteration or stopping. Include the cost of integration, operation, evaluation and support in that decision.

A valuable first use case leaves the business with an owned process, a clearer understanding of its data and evidence about what to do next. That is a stronger foundation than a striking demo with no route into everyday work.