When not to use AI

Saying no is part of the job

Every AI page on this site has a section called "where it doesn't fit". We put it there because saying where something fails is what makes the rest believable. This article collects those limits in one place. If any of them describes your situation, the honest advice is not to use AI for it, and we would rather say so in the first call than six weeks in.

When a rule would do

A great deal of what gets sold as AI is an if-then statement with a bigger invoice. If a GST rate depends on the item category, write the table. A rule is cheaper, faster, explainable and never wrong in a new way. Ethos bills locally through an outage because the rule for raising a bill is simple and must never be wrong. We would not put a model in that path, and nobody should.

Use a model when the input is messy and the rule cannot be written: a scanned invoice from a supplier whose format keeps changing, a customer email in three languages, a photograph. If a spreadsheet formula can do it, it is not an AI job.

When the job happens once

The cost of building, testing and watching an automated system is recovered only when the job repeats. A one-off migration, a single report, a clean-up of last year's data: these are jobs for a person with a script, not for a model wired into production.

When nobody can describe the process

Automation copies a process. If three people in the business do the job three different ways, and each says the others are wrong, a model will learn the mess and repeat it with confidence. Map the process first. Write down the steps, the exceptions and who decides what. That map is useful on its own.

When the data is not there

A forecast needs a record. A chatbot needs written answers. A document reader needs examples of the documents. If the business has been open a few months, or the answers exist only in the owner's head, the first job is to collect, not to model. We say this often to restaurant owners: a till that has been counting stock by recipe for two years is worth more to a forecast than any model is.

When a wrong answer is expensive and hard to reverse

Pricing, credit, anything with a legal or regulatory consequence, anything sent to a customer without a person reading it. Models are wrong some of the time, and they are wrong fluently, which is worse than being wrong obviously. Where a mistake cannot be caught and undone before it has an effect, a person must stay on the decision. If the aim is to remove the person from that particular step, the answer is no.

When you cannot check the output

If nobody in the business can tell whether the model's answer is right, there is no way to know when it has drifted. An automation nobody can audit is a liability with a monthly bill. Before building, name the person who will check it and the thirty past cases it will be checked against.

When the data cannot leave

Some information should not be sent to a third-party model under any terms: certain customer records, contracts under confidentiality, anything a client has asked you to keep inside your own walls. Models can be run in infrastructure you control, but that costs more and needs looking after, and if the hours saved do not justify it, the correct decision is not to do it.

When it is for the demo

If the reason is to be seen using AI, in a pitch, on a website or to a board, the project will be judged by how it looks rather than by what it does, and it will be abandoned as soon as the attention moves on. We build AI that does a job, not a demo. A job has a count of hours before and after. A demo does not.

What to do instead

Each "no" above has a cheaper "yes" next to it.

• A rule would do: write the rule, in the system you already have.
• The job is rare: a person and a script.
• The process is undocumented: map it. That is a two-week piece of work, not a model.
• The data is missing: start collecting now, properly, so the question can be asked next year.
• The mistake is expensive: keep the person, and let the model draft and flag.
• The output cannot be checked: name the checker and gather the examples first.

Most of these cost less than a proof of concept, and they remove the reason the proof of concept was going to fail.

Where that leaves AI

Everything above is a limit, not a verdict. The same business that should not put a model on its pricing may save hours every week by letting one read its supplier invoices. The point of knowing where AI does not fit is to spend on the place where it does. Our AI pages set out each capability with its fit and its limits side by side, so you can see both before anyone is asked to build anything.