How to tell if your business actually needs AI

The uncomfortable pattern in failed AI projects is that the engineering usually worked. The model did roughly what it was supposed to do. What went wrong happened earlier, when someone chose a problem that AI was a poor fit for and nobody said so.

There is a test that filters most of these out, and it takes about an hour. It has three parts: the shape of the task, the cost of being wrong, and the honest comparison.

1. Is the task actually fuzzy?

AI earns its cost on tasks where the rules are hard to write down but a human recognises the right answer instantly. Reading an unstructured document and pulling out the delivery date. Deciding which of forty teams a support ticket belongs to. Summarising a call into the three things that matter.

If the rules are writable, write them. A deterministic function that always produces the same output is cheaper, faster, debuggable, and doesn't need an evaluation harness. Plenty of teams have paid for a language model to do arithmetic that a spreadsheet formula already did correctly.

If you can describe the rule precisely enough to evaluate the model, you can usually just implement the rule.

2. What does a wrong answer cost?

Every model gets things wrong at some rate. The question is never whether it will, but what happens when it does. This is the single most useful variable in AI project selection and the one most often skipped.

• Cheap and self-correcting: a wrong tag on a saved article. The user fixes it in a second and nothing is lost.
• Recoverable but annoying: a misrouted support ticket. Costs time, visible, fixable.
• Expensive and quiet: a wrong number in a financial summary that nobody checks. This is the dangerous category.
• Unacceptable: anything with legal, medical or safety consequence where a confident wrong answer causes real harm.

The third category is where most damage happens, because the failure is silent. If your use case lives there, the project is not 'add AI' — it's 'add AI plus the verification layer that makes its mistakes visible', and that second half is usually the larger piece of work.

This is why the food recognition pipeline in FitRas returns a needs-clarification response rather than a number when a portion is ambiguous. A calorie count that is confidently wrong is worse for someone tracking their intake than one extra question. The gate exists because the cost of a quiet wrong answer was judged higher than the cost of the friction.

3. Compare against the real baseline

The comparison that matters is not model-versus-nothing. It's model-versus-what-you-do-today, measured. Before building anything, measure the current process: how accurate is it, how long does it take, what does it cost per unit.

Teams routinely discover their existing manual process is 91% accurate and their proposed model is 88%. That is a useful thing to learn in week one for the price of an afternoon, rather than in month four for the price of a project.

The short version

• The task should be genuinely fuzzy — if you can write the rule, write the rule.
• You should be able to state what a wrong answer costs, in your own units.
• You should have measured the current process before proposing to replace it.
• Someone should be willing to say 'not this one' out loud.

The best AI strategy work usually removes more from the roadmap than it adds. That is not a failure of ambition. It's what makes the remaining item worth doing properly.