Where AI is actually worth it in a business (and where it isn't)

The short answer: AI is worth it when the task is repetitive, happens at volume, tolerates an error you can catch, and the data already exists. If any one of those four is missing, there is almost always a cheaper and more reliable answer — a rule, a form, an integration between two systems that don't talk to each other today, or simply fixing the process before automating it.

Most of the AI enquiries we get start from the wrong end: "we want a chatbot." A chatbot is an interface, not a problem. The difference between a project that pays for itself in six months and one that gets quietly switched off after three is almost always the choice of problem, not the choice of model.

How do you know if a problem is a good fit for AI?Link to this section#

Four questions. If any of them comes back no, stop before a line of code gets written.

Is it repetitive? AI doesn't solve a case, it solves a shape of case, many times over. If every instance is different and needs fresh judgement, what you have isn't an automatable task — it's a job.

Is there volume? This is the filter that should stop the most projects and almost never gets applied. If the process happens twenty times a month, the best available system is a person spending twenty minutes on it. Only at hundreds or thousands of repetitions a month does the saving justify the build, the evaluation and the maintenance.

Does it tolerate an error you can catch? The question isn't whether it tolerates errors — every system has them — it's whether the error can be detected before it does damage. A misrouted ticket is fixed by dragging it to another queue. A miscalculated figure nobody checks is discovered when the complaint arrives.

Does the data already exist, and can you get at it? If the information the model needs lives in three people's heads or in a system with no API, this isn't an AI project yet. It's a data project.

The four patterns that reliably pay offLink to this section#

Almost everything we see working in production falls into one of these four. This is not a list of what the technology can do — it's a list of what adds up.

Pulling structured data out of documentsLink to this section#

Supplier invoices, delivery notes, purchase orders, insurance policies, contracts: anything that arrives as a PDF and gets retyped into a system by hand.

A distributor receives invoices from sixty suppliers in fifteen different layouts, and nobody is ever going to get all sixty to issue them the same way. The model reads the document and returns JSON with the fields that matter — issuer, number, date, line items, totals — and that JSON is validated against a schema before it touches the ERP.

What makes this work is not the model, it's the validation. Adding up the line items and comparing them against the declared total catches most reading errors with no human involved; whatever doesn't reconcile goes to a review queue. That deterministic check on top of the model's output is the difference between a demo and something you can leave running.

Classifying and routingLink to this section#

Support tickets, mail into a general inbox, claims, job applications. An info@ address taking three hundred emails a day mixing sales, support, billing and spam is a textbook case: there is volume, it repeats, and the error is cheap because recategorising an email costs one click.

One warning about measurement: the baseline isn't chance, it's what you already have. If your keyword rules are right 80% of the time, the model has to beat that 80% consistently to justify the switch. Often it does. Sometimes the honest answer is that the rules are good enough.

Semantic search over internal knowledgeLink to this section#

Manuals, procedures, product documentation, the archive of resolved tickets. The classic case: someone in support who knows the answer exists but not where, and ends up asking whoever has been there longest.

What's worth building here is not an assistant that "knows everything" — it's a search tool that returns the relevant paragraph with a link to the source. That distinction looks cosmetic and isn't: when the system cites, the reader verifies in two seconds and the error becomes cheap. When it asserts without citing, nobody verifies anything.

Drafting text that a person then editsLink to this section#

First drafts of customer replies, product descriptions, meeting summaries. The real saving isn't in the writing, it's in not starting from a blank page. A decent draft someone fixes in three minutes replaces fifteen minutes of writing from scratch.

The condition is literal: somebody edits it. If the text goes out under your name and nobody reads it first, you are no longer in this pattern.

Where AI does not pay offLink to this section#

This is the part almost nobody writes, and it's the part that saves the most money.

Decisions that need someone accountable. Approving credit, denying a claim, letting someone go, settling on a diagnosis. The problem isn't technical, it's accountability: when something goes wrong, a person has to explain why it was decided that way, and "the model said so" does not survive a customer, an auditor or a court. The model can organise the information and suggest; the decision still has a name attached to it.

Not enough volume to amortise the build. A document-extraction pipeline done properly — with exception handling, evaluation and monitoring — rarely comes in under several weeks of work. If the task costs one person two hours a week, the numbers don't work, and they don't work by a wide margin: multiply the annual hours by the loaded hourly cost and compare it against the budget. If the result isn't obvious, it's a no.

Expensive errors you cannot verify. The risk isn't that the model gets it wrong; it's that it gets it wrong and you don't find out. Payroll runs, regulatory calculations, any output nobody can check without redoing the work. If verifying costs as much as producing, you haven't saved anything — you've added one more component that can fail.

Broken processes. If nobody today can say for certain who approves what, automating it doesn't fix it: it makes it faster and harder to audit. A confused process automated is a confused process with a layer of software on top and one fewer person responsible for it.

"Human in the loop" is a design decision, not a disclaimerLink to this section#

It's the most repeated phrase in this field and the least specified. Putting a person in to review isn't a caveat for the contract: it's a part of the system, and it gets designed as one.

• What gets reviewed and what doesn't. The usual shape is a threshold: above a certain confidence it goes through automatically, below it lands in a queue. That threshold is calibrated against real data, not picked by intuition.
• In what interface. If reviewing means opening three screens and eyeballing a comparison, it won't happen. The review screen is often the most important part of the product.
• What happens to rejections. If the correction never makes it back into the system — as a test case, as an example, as an adjustment — the system never improves.

If review ends up being someone staring at a grid and hitting "approve all", there is no review. There's a signature. And a signature doesn't reduce risk, it relocates it.

The costs nobody puts in the budgetLink to this section#

The build is the visible part. These four show up afterwards.

Per-token cost at volume. A pilot over fifty documents costs pennies and says nothing about the economics of the system. Eight thousand documents a month is a fixed line in the operating budget, and that multiplication belongs in the decision to build.

Evaluation. A set of cases with the correct answer written out by hand — on the order of one hundred to three hundred — is what lets you answer "did that change make it better?". Without it, every prompt tweak is an opinion validated against three examples somebody happened to have open. It's the step most often skipped and the most expensive one to skip.

Monitoring and drift. The input changes: a new supplier with a different layout, a campaign that brings a different mix of questions. Quality doesn't fall off a cliff, it degrades silently. If nobody is watching a metric, the first to notice is a customer.

Maintenance when the model changes. Providers retire versions and ship new ones. A prompt tuned against one model does not behave identically against the next, and the migration stops being optional when the version you depend on is withdrawn. Budget the first year of operation as its own line, not as a rounding error on the build.

Privacy: what leaves your infrastructure and what doesn'tLink to this section#

This is the first question a serious client asks, and "it's all in the cloud, it's secure" is not an answer. The four that matter:

1. What data actually leaves. Often you don't need to send the whole document — only the part the model needs, with no names, no account numbers, no identifiers. Redacting before sending is the cheapest control available and the least used.
2. Where it goes and under what contract. Which provider processes it, in which region, how long they retain it, and whether it's used for training. You verify that in the terms you sign, not in the provider's blog post.
3. What gets logged. Logs are data. If you store every request and response for debugging, that store is as sensitive as the original and usually sits outside the retention policy somebody wrote for the database.
4. What if nothing can leave at all. Some data cannot exit your infrastructure, by regulation or by contract. You can run an open model on your own hardware, but let's be straight about the trade: less capability per dollar, plus a meaningful amount of infrastructure work. Sometimes that is genuinely the only valid option, and then it gets planned with that cost in view.

Where we would startLink to this section#

Pick one task that passes the four-question test. Measure what it costs today in hours per month: the real number, not the one you remember. Build the smallest thing that solves it end to end for a narrow subset, including the validation and the review screen. Measure again: if the saving is there, you scale with evidence behind you; if it isn't, you stopped early and cheaply.

That's how we run applied AI work: a fixed budget per phase and frequent releases, so the decision to continue or stop is made with something working in front of you rather than a promise.

If you have a task in mind and aren't sure which side of the test it falls on, tell us about it and we'll look at it with you. If the answer is that it isn't worth building, we'll say so.