Should I use AI in my business?

The question behind the question

Almost nobody actually wants “AI”. What they want is for a particular piece of work to stop costing so much time — reading documents, answering the same questions, moving data between systems, writing the same replies.

So the useful version of the question is: is this specific job one that AI is good at? That is answerable. “Should we use AI?” is not.

This guide covers the decision. If you have already decided in principle and want to know where it fits in a business like yours, read where an established business should actually use AI instead — that one goes place by place.

What AI is genuinely good at

Language models are good at a narrow and surprisingly useful thing: taking input that varies in ways you cannot write rules for, and producing output in a predictable shape.

That covers more than it sounds like:

• Reading documents. Invoices from two hundred suppliers, each laid out differently. CVs. Contracts. Scanned forms. The input is a mess; the output is a few structured fields.
• Answering from your own material. Policies, guides, past projects — a question comes in, the answer is in there somewhere, and finding it is the work.
• Classifying and routing. Which team handles this? Is this bounce permanent? Which of forty categories does this belong in?
• First drafts. Replies, summaries, proposal sections — written to be edited, not sent.

The common thread: a human could do it, the rules are too fuzzy to write down, and you can tell whether the result is right.

What it is bad at

• Anything requiring exactness. Arithmetic, totals, dates, reconciliation. Use software for the calculation and AI only for getting the numbers out of the document.
• Knowing things you have not told it. A general model knows nothing about your prices, your clients or your process. If it appears to, it is guessing.
• Being reliably consistent. The same input can produce slightly different output. Fine for a draft, not for anything that must match every time.
• Saying “I don’t know”. Models tend to produce something. Without a design that constrains and cites, confident wrong answers are the default failure mode.

The test worth applying

Two questions. Both need a yes.

1. Is the input genuinely messy? If you could write a rule, write the rule. It will be faster, cheaper, and auditable.

2. Can you tell whether the output is right? Either a person checks it, or it reconciles against something, or you sample it. If nobody can tell, you have not automated the work — you have made it invisible.

What to do first

Pick the task where someone currently reads something and writes something, it happens often enough to matter, and a wrong answer is annoying rather than catastrophic.

Build that one. Measure it against the manual baseline honestly — not “it feels faster”, but how many got through without correction. Then decide whether there is a second.

The businesses getting real value from AI are not the ones using it in the most places. They found two or three tasks where it genuinely fits and resisted the rest.

When ordinary software is the better answer

This is the part the market tends to skip.

You are tempted by	Usually better
An AI assistant to answer customer questions	A good search box and clearer pages
AI to extract data from your own system	A query or a report
AI to decide approvals	A rule — “over £500 needs sign-off”
AI to fill in a form	A better form
AI to summarise your own data	A dashboard

We talk clients out of AI features regularly. A model that costs money per call and occasionally gets it wrong is a poor substitute for a well-built screen.

The risks worth taking seriously

Confident wrong answers. Mitigate by grounding answers in your own material and making the assistant cite what it used, so a reader can check.

Cost that arrives monthly. Model calls are cheap individually and expensive in aggregate. The failure mode is a per-record call across ten thousand records. Cache, cap, and make calls event-triggered rather than per-row.

Data going somewhere you did not intend. It depends entirely on which service and which settings — enterprise API terms, retention and training policies differ, and the defaults are not always what you would choose. It is a question to ask before you build, not after. (A full guide on this is being written; in the meantime, ask us and we will walk you through it.)

Building on a feature rather than a problem. The most expensive AI projects we see started with “we should use AI” and went looking for somewhere to put it.

What it costs

Less than people expect to build, and more than they expect to run. There is no licence, but there is a per-use bill that scales with how much you use it. The numbers and what drives them are in how much does AI automation cost?.

What this looks like in practice

For Adjust, a neurodiversity training consultancy, the problem was not “we need AI”. It was that their expertise was only available on the day they were in the room. The assistant answers managers’ questions from Adjust’s own guidance, links to the guide it used, and follows their house style — including terminology the sector has moved away from. That is a narrow, checkable job.

For Yeppe, AI is a fallback, not the system. Crawlers read school websites with ordinary parsing; the model only handles pages that defeat it. Cheap and deterministic first, model as the exception.

So — should you?

If you can name one task where the input is messy, the volume is real, and you could tell whether the answer was wrong: yes, and start there.

If you cannot name one, the honest answer is not yet. That is a better place to be than halfway through a project nobody can evaluate.