Conversations about AI in business almost always start from the wrong end: pick a tool first, then hunt for somewhere to apply it. That produces projects which dazzle in a demo and quietly die two months later. The reverse order works — find a task with the right properties, and only then ask whether a model is needed. Below: three markers of tasks where AI delivers measurable gains, four categories where it loses to ordinary code, and an honest look at cost.

Three markers of a task where AI pays off

Language models are profitable not where they impress, but where three conditions hold at once. If even one is missing, it is almost always cheaper to solve the task with ordinary code or leave it to a person.

1. 1

   The task repeats and is expressed in words

   Parse an enquiry, extract the essentials, assign a category, draft a reply. If the same thing happens dozens of times a week and slightly differently each time, it is a candidate.

2. 2

   Mistakes are cheap or immediately visible

   A misfiled enquiry is fixed with one click. An incorrectly issued invoice is not. The more expensive the error, the more oversight is required, and the less sense automation makes.

3. 3

   A person or the next step checks the output

   AI works well as a first rough layer followed by a quick review. A model acting with no oversight at an important step will eventually create a problem costing more than everything it saved.

What actually sticks

The most common working scenario across our projects is that first row: a Telegram bot answering repeat questions from a knowledge base and handing anything uncertain to a human. The technical side of such a solution is covered in our piece on AI chatbots.

Where AI loses to ordinary code

This is the part nobody usually mentions. A language model is a probabilistic tool, so it is poorly suited wherever guaranteed consistency of output is required.

• Calculations. Prices, discounts and stock levels must come from a formula, not a model. A model can be wrong and you will not notice.
• Unambiguous rules. "Free delivery over a thousand" is a condition in code, not a task for AI.
• Legally binding text. Contracts and warranty terms cannot be handed to a generator without a lawyer.
• Rare tasks. Something happening twice a month is cheaper done by hand than automated and maintained.
• Sensitive data without controls. Customer personal data requires a deliberate decision about where it is sent.

Where to start

1. 1Measure one task. How many times a week it happens and how many minutes it takes. Without that number you can judge neither the benefit nor the failure.
2. 2Take the dullest task, not the most interesting. The best candidates are the ones everybody dislikes: sorting, re-entering data, repeating the same answers.
3. 3Run a two-week pilot. Limited scope, one scenario, mandatory human review of output.
4. 4Cost the processing. Paying per volume of text is predictable: most enquiry-handling scenarios cost tens of dollars a month, not thousands.
5. 5Only scale what worked. Launch the second scenario after the first has run a month without manual corrections.

If the task turns out not to need AI at all but plain automation, that is a normal and very common outcome — the typical scenarios are described in our piece on business process automation.

Frequently asked questions about AI in business

In short

• AI pays off where the task repeats, errors are cheap and output is checked — all three at once.
• The most reliable scenario is answering routine questions: 60–80% of enquiries close automatically.
• Leave calculations, unambiguous rules and legal text to ordinary code and people.
• Never grant a model the right to take an irreversible action without confirmation.
• Start with the dullest task rather than the flashiest, and with a two-week pilot.
• If manual corrections exceed 20%, refine the scenario instead of scaling it.