Where AI earns its keep, and where it does not

We are asked to build a lot of AI features. A reasonable share of them should not be built — not because the technology cannot do the task, but because doing the task faster was never what was holding the business up.

There is a short test that sorts most of these before anyone writes code.

Three questions, asked in order

First: what does a wrong answer cost? Not the average case — the worst one that is still plausible. A model that drafts a first-pass reply for a human to approve and a model that sends it are the same technology with completely different risk profiles.

Second: how fast would anyone notice? Errors that surface immediately are survivable at surprisingly high rates. Errors that accumulate silently — a misclassification that quietly skews a report for a quarter — are not, even at low rates.

Third: was this task actually the bottleneck? This is where most proposals fail. If a contract takes nine days to approve and eight of them are a person waiting for someone else to look at it, then generating the draft in four seconds instead of forty minutes changes the total by almost nothing.

Automating a step that was never the constraint produces a faster version of the same wait.

What reliably works

The projects that pay for themselves tend to share a shape: high volume, tolerant of being wrong occasionally, and with a human positioned where a mistake would otherwise escape.

• Extraction from documents that arrive in inconsistent formats — invoices, delivery notes, forms. The work is dull, the volume is real, and the output is checkable against something.
• Triage and routing. Deciding which queue a request belongs in is low-stakes, immediately visible when wrong, and saves a person reading everything.
• First drafts with a named human approver. The model removes the blank page; the approval step is where correctness lives.
• Search across your own material, where a person reads the result and the source is cited so they can check it.
• Summarising long material for someone who will also have the original to hand.

What reliably disappoints

• Anything that writes to a system of record with no human in the loop and no reconciliation. The errors are quiet and compound.
• Replacing a judgement your business is actually paid for. If clients are buying your expertise, automating the expertise is a strange thing to sell them.
• Low-volume tasks. A model that saves twenty minutes on something done twice a month will never repay the cost of building and maintaining it.
• Anything where you cannot describe what a correct answer looks like. If two of your own experts disagree about the right output, you do not yet have a specification.

The maintenance nobody budgets for

An AI feature is not finished when it ships. Models get deprecated and replaced on their vendors' schedules, not yours. Prompts that worked against one version behave differently against the next. Your own data shifts, and so does what counts as a good answer.

If nobody owns the ongoing evaluation — a set of real examples with known-correct answers, run regularly enough to catch drift — then you do not have a reliable feature. You have one that currently happens to work, which is a different thing, and the difference usually becomes apparent at an inconvenient moment.

A reasonable way to start

Pick one task that is high-volume, visibly checkable, and currently annoying. Run it alongside the existing process rather than in place of it, and measure the disagreements. You will learn more from a fortnight of that than from any amount of discussion about which model to use, and you will have the evaluation set you needed anyway.

If the result is that the model agrees with your team almost always and the exceptions are ones a person can catch, you have something worth deploying. If it is that nobody can agree what the right answer was, you have learned something more valuable than a feature.