How to identify an AI use case worth funding

Most organisations do not have an AI problem. They have a prioritisation problem. There is a list of twenty ideas, three of them are genuinely good, and nothing in the list tells you which three.

The usual response is a scoring workshop. Everyone rates each idea on impact and effort, the numbers are averaged, and the top of the list turns out to be whatever the most senior person in the room liked. That is not prioritisation, it is consensus theatre with a spreadsheet attached.

What follows is the test we actually apply. It is four questions. An idea that cannot answer all four should not be funded yet, and the reason it cannot answer them is usually more useful than the idea was.

Question one: what does the process cost today?

Not what the AI would save. What the current process costs, in a number someone would defend.

This sounds obvious and it eliminates roughly half of most idea lists. An organisation that wants to automate tender review can usually tell you it takes "about a week". It often cannot tell you how many tenders, how many people, at what cost, with what error rate, and what happens when it goes wrong. Without that, the eventual benefit claim is unfalsifiable.

The number does not need to be precise. It needs to be constructed from something observable: hours logged, tickets closed, documents processed, invoices disputed, staff on a roster. A range built from real counts beats a point estimate built from opinion.

There is a useful side effect. Roughly one time in five, working out the current cost reveals that the process is cheap and the irritation is disproportionate. That is a genuinely good outcome, arrived at for the price of an afternoon.

Question two: is the input actually available?

AI use cases fail on data availability far more often than on model capability.

The specific question is not "do we have the data". It is: can a system read the input, at the moment it is needed, with the permissions it needs, in a form it can process? Four separate conditions, and a use case needs all four.

Common failure shapes:

• The data exists but not in a system. It is in someone's inbox, a shared drive nobody indexes, or a PDF that was scanned at an angle in 2019.
• The data exists but not at the right time. The nightly extract is fine for reporting and useless for a decision made at 10am.
• The data exists but the permissions do not resolve. This is the one that kills enterprise search projects. A decade of accumulated oversharing means the moment you switch on retrieval, people can find things they were technically always able to find but never would have. That is an information-management project, it sits outside the AI build, and it needs its own budget.
• The data exists but is not trustworthy. Three systems hold a customer record and they disagree. A model trained on the disagreement learns the disagreement.

None of these are reasons to abandon a use case. They are reasons to sequence it behind the work that fixes them, and to stop describing it as a three-month AI project when it is a nine-month data project with three months of AI at the end.

Question three: what happens when it is wrong?

Every model is wrong sometimes. The question is what that costs, and who notices.

Sort candidate use cases into three bands:

Low consequence, self-correcting. A drafting assistant produces a weak first paragraph. The author rewrites it. The cost of being wrong is a few seconds, and the person who bears the cost is the person who can immediately detect it. These are the safest places to start and, not coincidentally, the easiest to get approved.

Moderate consequence, detectable. An extraction pipeline mis-reads a quantity on a supplier confirmation. It will be caught at goods receipt, but late, and someone will spend an hour on it. These need a review step and a measured accuracy rate before they scale.

High consequence, hard to detect. An automated classification silently mis-routes a small percentage of cases and nobody finds out for months, because the whole point of the automation was that nobody was looking. These need sampling, audit trails, and a named person accountable for the error rate. Some of them should not be built at all.

The band determines the control, and the control determines the cost. A use case whose value only works if you skip the review step is not a viable use case, it is a viable use case with the safety removed.

Question four: who owns it after it works?

This is the question that changes the answer most often, and it is the one most business cases omit entirely.

An AI system is not a project deliverable. Its accuracy drifts as the inputs drift. Suppliers change their document formats. A reorganisation changes the permission structure underneath a retrieval index. A model version is deprecated and the replacement behaves differently on the edge cases you never wrote down.

So: who watches the accuracy? Against what baseline? How often? Who decides when it has degraded enough to act? What is the budget for retraining, and whose cost centre does it come from?

If the answer is "we will work that out later", the total cost of the use case is unknown, and any ROI figure attached to it is decoration. We would rather find that out in the assessment than in month seven.

Putting it together

A use case worth funding can answer all four:

1. The current process costs a defensible number.
2. The input is available, timely, permissioned and trustworthy enough.
3. The consequence of error is understood and the matching control is affordable.
4. Someone owns the accuracy after go-live and has a budget for it.

Notice what is absent. There is no question about which model to use, which cloud to build on, or whether to use retrieval or fine-tuning. Those are real decisions and they matter, but they are downstream. Choosing a platform before answering these four is how organisations end up with a well-architected solution to a problem that was not worth solving.

What this looks like in practice

The four questions take about half a day per candidate when the right people are in the room. The right people are the ones who do the work, not the ones who describe it. A process owner will tell you the exception rate. A manager will tell you the intended process.

Run it across a list of twenty and you will typically get:

• three or four that pass cleanly and can be scoped,
• six or seven that pass questions one and three but fail on data, which become a data roadmap,
• the rest that fail question one, which quietly disappear and should.

That last group is the real return on the exercise. Not choosing the best idea, but declining to fund the nine that were never going to work, before spending anything on them.

If you want to run this against your own list, our free discovery workshop is built around exactly this test.