"AI-powered" appears on nearly every business software product page, and it now conveys almost no information. It might mean a language model reads your documents. It might mean a threshold alert with a different label. It might mean nothing at all.
For a business evaluating software, the useful question is not whether a product has AI. It is which specific tasks it performs with a model, and what happens when the model is wrong — because it will be, and the difference between a good and a bad implementation is entirely in how that case is handled.
The division that matters
The practical rule we build to: a model should read, generate and summarise. Deterministic logic should decide anything consequential.
Language models are genuinely good at handling unstructured input — reading a supplier invoice in an unpredictable format, summarising a long thread, classifying something into loose categories, answering a question phrased in ordinary language. These are tasks that resisted automation because the rules could never be fully written down.
They are a poor choice for decisions that must be consistent, auditable and defensible. Whether a customer exceeds their credit limit is arithmetic. Whether stock is below reorder is a comparison. Using a model for these makes a reliable operation probabilistic for no benefit.
The failure to separate these is what produces software that is impressive in a demo and untrustworthy in operation.
How we apply it elsewhere
In SYNTAX, our clinical reasoning platform, the separation is explicit: assessment scores are computed by logic against defined criteria, while a model writes the narrative feedback. The score has to be defensible; the prose does not.
The same principle governs operations software. A model can draft the summary of a variance. It should not decide what counts as variance.
Where AI genuinely earns its place in operations
Reading unstructured documents. Supplier invoices, delivery notes, purchase orders arriving as PDFs, images or email text in a hundred different layouts. Extracting structured data from these was previously either manual or brittle. This is the clearest win available in most operations.
Search in ordinary language. "What did we sell to this customer last quarter" without constructing a report. The model interprets the question; the answer still comes from the actual records.
Summarising a situation. Turning a set of exceptions into a short readable account of what needs attention, rather than a list a person has to interpret.
Drafting. Follow-up messages, purchase orders, descriptions — where a person reviews before it goes out.
Loose classification. Categorising incoming requests or issues where the boundaries are fuzzy and consistency requirements are moderate.
The common property: the output is read by a person who can notice it is wrong before it matters.
Where it does not belong
Anything requiring an audit trail of reasoning. If you may need to explain the decision to a customer, a regulator or a court, it should be produced by rules you can state.
Financial calculation. Totals, tax, balances. These are arithmetic with a correct answer.
Threshold and rule enforcement. Credit limits, reorder points, authorisation levels. Deterministic by nature.
Anything where a plausible wrong answer is expensive and hard to spot. This is the crucial category. Traditional software fails obviously — it errors, or produces an absurd number. Models fail plausibly, generating something that looks reasonable and is wrong. That makes detection harder, not easier, and it is why the "detectable when wrong" condition from workflow automation becomes more important with AI rather than less.
Five questions for any vendor claiming AI
Which specific tasks use a model? A vendor who cannot name them precisely is describing marketing, not architecture.
What happens when it is wrong? There should be an answer involving human review, confidence handling, or a fallback. "It is very accurate" is not an answer.
Does it decide anything, or only draft and summarise? If it decides, ask how the decision is logged and whether it can be explained afterwards.
Where does our data go? Whether business data is sent to a third-party model provider, whether it is retained, and whether it is used for training. This is a straightforward question and the answer should be in writing.
Does it work without it? If the AI features are unavailable, does the system still function? Anything core that depends on an external model has a new failure mode.
The uncertainty question
A system that always produces an answer is more satisfying and less trustworthy than one that declines.
We build the opposite way. In ARCORA, our crop diagnosis system, every result carries a confidence score, and some cases produce a referral for laboratory testing rather than an answer — because certain identifications cannot be made from an image. Knowing the boundary of the method is part of the method, an argument made at length in reading a crop diagnosis report.
In operations software the equivalent is a system that flags "this invoice did not extract cleanly, please check" rather than silently recording a wrong figure. That behaviour is unglamorous and it is the difference between a tool you can trust and one you have to audit.
What we have seen
Across the ten systems we have delivered, AI features are consistently the ones clients are most excited about at specification and least dependent on in operation.
What actually gets used daily is document reading — because it removes real manual work with an obvious check. What gets used less is anything conversational, because staff with a job to do prefer a screen that shows the answer to a chat that requires phrasing a question.
The other consistent finding is that AI applied to a broken process makes it faster and wrong. If information is being carried between systems by hand, the fix is a shared record, not a model performing the carrying. That is the architecture in what a business operating system actually is.
Frequently asked questions
Is AI in business software worth paying extra for?
For document extraction, frequently yes — it removes measurable manual work. For conversational interfaces, evaluate against how your staff actually work. Paying a premium for "AI-powered" as a category, rather than for a named task, is paying for marketing.
Will our data be used to train someone's model?
Ask, and get it in writing. It varies by vendor and by the underlying provider, and it is a reasonable thing to require an answer on before committing.
Can AI replace our reporting?
It can make reports easier to request in plain language. It should not be the thing computing the numbers. Interpretation by model, calculation by logic.
How do we know if the AI is accurate?
Test it on your own documents and data before committing, not on the vendor's demo set. Extraction accuracy varies enormously with format, and your suppliers' invoices are the only relevant sample.
Should we wait for the technology to mature?
For document reading, no — it works now and the benefit is immediate. For anything making consequential decisions unsupervised, waiting is reasonable, and so is never.
Where to start
Ignore the label and list the tasks. For each place a product claims AI, ask what it does, what happens when it is wrong, and whether a person sees the output before it matters.
The implementations worth paying for are narrow and boring: read this document, summarise these exceptions, answer this question from the actual records. The ones to be careful with are the ones that decide something quietly.
SPEXA includes AI as one of six modules, scoped to search and summarisation over the operation's own data. If you want a read on where it would actually save you time, get in touch.