Choosing AI use cases that survive a business case

What counts as a use case#

An AI use case is a specific decision or task, in a named process, that a model would perform or assist, with a stated owner and a measurable effect on cost, revenue, risk or service.

Anything less specific than that is a theme rather than a use case.

“AI in credit” and “AI for customer service” are directions, not candidates, and they cannot be costed, tested or refused.

The discipline of forcing a candidate into that sentence eliminates a surprising share of an initial list before any analysis begins, which is itself useful.

The first test: value#

The first test is value, and it should be applied before feasibility because it is cheaper. A use case has value when the volume is high enough that a small per-unit improvement compounds into a number worth managing, and when the current cost of doing it another way is actually known.

Institutions consistently overestimate the value of automating visible, irritating tasks that occur rarely, and underestimate high-volume invisible work such as document extraction, alert triage and reconciliation. The honest question is not whether AI could do the task but what the institution would do with the capacity released — if the answer is nothing specific, the saving is theoretical.

The second test: data#

The second test is data, and it fails more candidates than any other. The relevant question is not whether the institution has data but whether it has the right data, lawfully usable for this purpose, in sufficient volume, with labels or outcomes that make learning possible, covering the conditions the model will meet in production.

• A credit model needs outcomes from a period including a downturn
• a fraud model needs confirmed cases, not merely alerts
• a document model needs examples of the messy real submissions rather than the clean templates

Data assessed as adequate on the strength of a schema, without anyone examining actual records, is the single most reliable predictor of a pilot that underperforms without explanation.

The third test: decision fit#

The third test is decision fit: whether the process has somewhere to put the answer.

A model that produces a score which no existing step consumes, a ranking that no queue is ordered by, or a recommendation that no role is authorised to act on, will produce excellent output into a void.

This is the test most often skipped, because it belongs to operations rather than to technology and neither side thinks it is theirs.

The way to apply it is to walk the process as it runs today and identify the exact step where the output would arrive, who is standing at it, what they would do differently, and what authority they hold. If that step does not exist, it has to be designed — and designing it is usually more work than building the model.

The fourth test: accountability#

The fourth test is accountability: whether anyone will sign for the outcome. Every consequential automated decision needs a named person who accepts responsibility for it being wrong, and that person will reasonably ask what the error rate is, what the failure looks like, who the customer complains to, and what happens when a supervisor or an auditor asks.

Use cases die at this test more often than at any technical one, and usually late, after money has been spent. Asking the question first — who signs — reorders a roadmap immediately, because it separates the cases where accountability is straightforward from the ones that require a governance answer before they can be built at all.

The gap between a pilot and production#

The gap between a working pilot and a production system is where most AI investment is actually lost, and it is worth being precise about what sits in it, because it is almost never modelling. Production requires:

• integration with the systems that run the process
• a decision record that reproduces any past output
• monitoring that detects degradation
• an override path with a real user interface
• access control
• a rollback plan
• an owner with a budget line
• a support arrangement for the day it breaks at month-end

A proof of concept scoped without these is not eighty per cent of the way to production; it is a demonstration that the model is not the obstacle.

Sequencing the roadmap#

Sequencing a roadmap well means resisting the instinct to start with the most valuable case. The first delivery should be chosen for its ability to prove the framework end to end — meaningful but not existential, with clean data, an obvious place in the process, and an owner who wants it.

Delivering it establishes the governance path, the integration pattern, the monitoring approach and the institution’s confidence, all of which make the second and third cases faster and cheaper. Starting with the hardest case instead means the framework, the integration and the political argument are all being invented simultaneously, under the highest possible stakes.

The shapes that hold up, and the shapes that disappoint#

The candidates that hold up best in regulated institutions share a shape:

• high volume
• tolerant of a reviewable error
• with an existing process step to land in
• an owner who already feels the pain

Document extraction and checking, alert triage and prioritisation, first-line drafting with human sign-off, reconciliation and exception routing, and search across internal policy and procedure all fit it.

The candidates that most often disappoint share a different shape:

• consequential decisions about individuals where explanation is required and error is expensive
• low-volume judgement calls where there is nothing to learn from
• anything whose value depends on data the institution has not confirmed it can lawfully use

The refusals are the most valuable output#

The most valuable output of a use-case exercise is usually the list of refusals, provided the reasons are attached.

• “Not yet, because the outcome data does not cover a downturn” is a decision that can be revisited when it does.
• “Not yet, because no role is authorised to act on the output” names a process change someone can own.
• “No, because the decision is too consequential to automate at our current validation capability” is a defensible position that can be stated to a board.

A roadmap consisting only of approved items, with nothing refused, has not been through an exercise at all — it has been through a wish list.