A great deal of organisational energy is currently spent looking for somewhere to apply AI. This is the wrong direction of travel. The productive question is not 'where could we use AI?' but 'where is our most expensive repetitive work, and is any of it rule-shaped enough to automate?'
Those two questions lead to very different places. The first leads to pilots. The second leads to work that pays for itself.
The profile of a good candidate
Tasks worth automating tend to share a specific shape. They are repetitive, high-volume, and — critically — have a clear definition of what a correct result looks like.
- Document handling — reading, extracting and filing material that arrives in volume
- Classification and routing — deciding which queue, team or category something belongs to
- Data extraction — pulling structured values out of unstructured documents
- Reconciliation — comparing two sources and surfacing only the differences
- Retrieval — finding the relevant precedent or record inside a large internal corpus
The profile of a bad candidate
Equally important is knowing when to decline. A task is a poor fit when the volume is low enough that a person handles it comfortably, when correctness is contested or subjective, when an error is expensive and difficult to detect, or when the underlying process changes so frequently that any automation would need constant rework.
The most valuable thing an adviser can say about an AI project is that a simpler automation would do the job better.
Design for the human in the loop
Any automation touching decisions with real consequences needs a review path — not as a temporary measure during rollout, but as a permanent part of the design. The practical pattern is confidence-based: the system handles what it is confident about and routes the rest to a person, along with its reasoning.
This has a useful side effect. The queue of low-confidence cases is a live map of where the automation is weak, and it tells you exactly what to improve next.
Measure the thing you set out to change
Before building anything, record how long the task currently takes and how often it goes wrong. Without that baseline you will have no honest way to judge the result, and the project will be assessed on how impressive it seems rather than on whether it helped.