How Businesses Can Actually Use AI (Without the Hype)

Two things are true at once: language models are genuinely useful, and most business AI projects fail to produce anything measurable. The gap between those isn’t the technology — it’s the choice of problem.

What models are actually good at

Current language models are strong at a fairly narrow set of tasks:

• Reading unstructured text and pulling out structured data.
• Classifying text into categories you define.
• Summarising long documents into shorter ones.
• Drafting text that a human then reviews and edits.
• Answering questions about documents you provide, when the answer is in those documents.
• Translating between languages, and between registers.

Notice what these have in common: the input is messy text, the output is checkable, and a human can verify the result faster than they could have produced it.

What they’re bad at

• Arithmetic across many numbers. Use a database or a spreadsheet.
• Guaranteed correctness. They will produce a confident wrong answer rather than nothing.
• Knowing your business. Anything not in the prompt or retrieved context doesn’t exist to the model.
• Being reliably consistent. The same input can give slightly different output. Fine for drafting, unacceptable for a pricing calculation.
• Staying current. Training data has a cutoff. Anything time-sensitive needs to be retrieved, not remembered.

Almost every failed AI project we’ve seen chose a task in this list and tried to engineer around the limitation, rather than choosing a task from the previous one.

A useful test for any AI idea

Three questions:

1. Is the input unstructured? If it’s already structured data, ordinary code will do the job better, cheaper and predictably. That’s traditional automation.
2. Can a human check the output quickly? If verification takes as long as doing it, you’ve saved nothing.
3. What’s the cost of being wrong? If it’s high, you need a human in the loop, which caps the saving. Be honest about that before you build.

Where the value usually is

Document intake. Invoices, orders, applications, CVs, contracts. Extracting fields into structured data with a confidence score, routing the uncertain ones to a person. This is unglamorous and frequently the highest-return AI in a business.

Inbox triage. Categorising and routing incoming email, drafting a first response, flagging anything urgent. Works well because a human reviews before anything is sent.

Internal question answering. A search layer over your own documentation, policies and past projects — with citations, so answers can be verified. Most useful in businesses where the knowledge is real but scattered.

Making free text reportable. Feedback forms, support notes, survey comments. Categorising thousands of these at once produces reporting nobody could previously do at all — a genuinely new capability rather than a faster version of an existing one.

Content drafting at volume. Product descriptions, translations, variations. With editorial review, and with someone accountable for accuracy.

How to run the first project

Pick one process. Narrow beats broad, every time.

Measure the current version. How long it takes, how often it’s wrong, how many cases per week. Without a baseline you cannot demonstrate improvement.

Build a test set. Fifty to a hundred real cases with known correct answers. This is the single most skipped step and the one that separates evaluation from opinion.

Prototype on real data. Not on the clean examples. Real data has scanned pages, missing fields, and three formats from the same supplier.

Measure honestly. Accuracy against the test set. Cost per case. Time saved. If it isn’t better than the manual process, say so and stop — that’s a successful project, not a failed one.

Then integrate. Only after it works. An accurate model wired into nothing produces no value.

The things to get right before you scale

• Data handling. Know where your data goes, what’s retained, and whether it’s used for training. Business API tiers from major providers don’t train on submitted data by default, but this should be verified and documented rather than assumed.
• Cost modelling. Per-call costs are small and volume is large. Model it at realistic volume before committing.
• Failure behaviour. What happens when confidence is low? "Escalate to a person" is a design decision, not a fallback.
• Monitoring. Model quality can drift when providers update. Keep the test set and re-run it.

The honest summary

For most small and mid-sized businesses, the ranking is: fix your data flows first, automate the deterministic processes second, and apply AI to the genuinely unstructured work third.

Done in that order it works. Done in reverse it produces a demo and a disappointing invoice.

If you have a process with a lot of reading, sorting or retyping in it, tell us about it — and we’ll tell you honestly whether AI is the right tool for it. Sometimes it isn’t.