Most businesses have now been told that AI will transform them, without being told what to actually do on Monday. The gap between those two things is where budgets go to die.
This is a practical view: what AI does well enough to depend on today, what it does not, and how to scope a first project so you can tell whether it worked.
What it genuinely does well
Reading things at volume
Summarising, classifying and extracting structure from documents, emails and enquiries. If a person currently reads a queue and decides where each item goes, that is a strong candidate. The work is repetitive, the criteria are usually explainable, and errors are visible.
Drafting a first version
Response drafts, descriptions, summaries — anything where a human reviews before it goes out. The productivity gain comes from editing rather than starting, and it is real. The failure mode is removing the reviewer.
Finding patterns in structured data
Segmentation, anomaly detection and forecasting across data you already hold. This is the least discussed and often the highest return, because it surfaces things nobody had time to look for.
What it does not do reliably
- Anything requiring certainty about facts it was not given — it will produce a confident answer regardless
- Judgement calls with real consequences and no human review
- Work where being wrong 5% of the time is unacceptable and errors are hard to spot
- Replacing a process nobody has bothered to define — automation applied to chaos produces faster chaos
Scoping a first project
The projects that succeed look almost boringly narrow. Pick one recurring task, with a measurable before, where a mistake is visible and recoverable.
- Name the task in one sentence, without using the word "AI"
- Measure what it costs today — hours per week, or delay in days
- Decide what "working" means numerically before you build anything
- Keep a human reviewing output until the error rate is known, not assumed
- Compare against the baseline after a defined period, and be willing to stop
The questions worth asking a vendor
- Where does our data go, and is it used to train anything?
- What happens when the model is wrong — who sees it, and how quickly?
- What does this cost per unit of work, at volume, not in the pilot?
- What breaks if the provider changes their model or pricing?
That third question is where enthusiasm frequently meets arithmetic. Per-request costs that are trivial in a pilot can become significant at production volume, and the pilot rarely models that.