Choosing AI should be an engineering decision. What does the task require, how much uncertainty can it tolerate and how will you know the result is useful?

Start with a normal solution

A calculation needs a calculation. A fixed routing rule needs a rule. Moving data between two known systems needs an integration. None of these becomes more reliable simply because a language model is involved.

AI becomes interesting when the input is varied and interpretation matters. Summarising long text, suggesting a category or extracting candidate fields from inconsistent documents can be useful starting points.

Design for uncertainty

A plausible answer can still be wrong. Constrain the task, validate the format and compare the result against information you can check. Set aside real examples that were not used while designing the prompt, then use them to evaluate changes.

Keep the human decision explicit

Do not let a generated confidence score substitute for a tested quality threshold. For consequential decisions, make review part of the workflow and show the reviewer the original evidence. A hiring assistant might organise information, for example, while a person applies the agreed criteria and makes the decision.

Count the cost of the whole system

Include review time, errors, latency, privacy requirements and ongoing evaluation. A task that looks cheap per request can become expensive if every response needs checking.

Prototype a narrow task before expanding it. Compare it with a straightforward alternative and keep the version that performs well against the actual requirements. Sometimes that will be AI. Sometimes it will be a few clear rules.

HAVE A RELATED PROBLEM?

Tell us what you are working on