AI & Automation · 3 min read
Where AI Actually Pays Off in Business Software
The useful question about AI in business software is not whether it works. It is whether it beats the alternative for a specific job, once you have counted what it costs to run, to supervise, and to be wrong. For some tasks it wins comfortably. For others, a hundred lines of plain code are faster, cheaper, and correct every time.
The test we apply
Before reaching for a model, it is worth asking whether the task has a right answer that can be written down as a rule. If it does, write the rule. Rules are cheaper to run, easier to test, and they do not drift when a vendor updates something.
Where a model earns its place is the opposite case: tasks where the input is messy, the rules are numerous and fuzzy, and a human currently does the work by judgement rather than by procedure. Reading a supplier invoice that arrives in a different layout every time is that kind of task. Calculating tax on it is not.
Where it earns its cost
The cases that reliably work share a shape — a human was already doing something repetitive with unstructured input, and being roughly right is genuinely useful:
- Pulling structure out of documents. Invoices, contracts, application forms, email enquiries. The output is checkable, which matters — a person can confirm a total in seconds even if extracting it took them minutes.
- Routing and triage. Deciding which team an enquiry belongs to, or which of a thousand tickets look urgent. Being wrong occasionally costs a re-route, not a disaster.
- Search over your own material. Letting staff ask a question of a body of internal documents instead of knowing which file to open.
- First drafts. Summaries, replies, descriptions — where a person edits and approves before anything leaves the building.
Notice what these have in common: a person stays in the loop, and the cost of a wrong answer is a correction rather than a loss.
Where plain code still wins
Anything arithmetic. Anything with a legal or financial consequence attached to being exactly right. Anything where the same input must produce the same output every time, and where you will one day have to explain to an auditor why it produced what it did.
There is also a large category of work where a model is technically capable but simply unnecessary — validating an email address, deciding whether a date falls in a range, applying a discount tier. Using a model there buys latency, cost, and a new failure mode in exchange for nothing.
What it costs to run
The per-request price is the part everyone estimates and the part that matters least. The costs that catch teams out are the ones around it: the work of evaluating whether output is good enough, the review step you now need in the workflow, and the ongoing attention required when behaviour changes underneath you.
A feature that needs a human to check every answer has not removed the human — it has changed their job from producing to reviewing. That is often still a large win, because reviewing is faster than producing. But it should be planned as a redesign of the workflow, not sold as removing a step.
Failing safely
Anything built on a model needs an answer to a question ordinary software rarely faces: what happens when it is confidently wrong? Not unavailable — wrong, plausibly, in a way nobody notices for a week.
The practical protections are unglamorous. Keep a human approval step wherever the consequence is irreversible. Log the input and the output together so a bad decision can be traced afterwards. Constrain the output to a fixed shape and reject anything that does not fit. And give it a defined scope, so that a system built to categorise enquiries cannot quietly end up issuing refunds.
Build Software That Grows Your Business
From custom software development and AI automation to cloud-native applications, we create secure, scalable solutions built for long-term success.
Get Free Consultation