Inside a build, "should this use AI" is not a strategic question. It is a component-level engineering decision, made repeatedly, about specific jobs — and it has a defensible answer each time.
The answer is frequently no, and not for cautious reasons. It is because a model is a probabilistic component with running cost, latency and a failure mode that produces plausible wrong answers, and a great many jobs in business software are better served by something deterministic that is cheaper, faster and inspectable.
This is about how that decision gets made rather than about what buyers should look for, which is a separate question covered in what "AI-powered" should mean in business software.
The question that settles most cases
Can this be expressed as a rule?
If a competent person can write down the logic — if this, then that; if the value exceeds a threshold, flag it — then a rule is the correct implementation. It is faster, free to run, produces the same answer every time, and can be explained to a user who disputes it.
Reaching for a model where a rule suffices is not sophistication. It introduces cost and non-determinism to solve a problem that had neither.
The cases where a model earns its place are the ones where the rule cannot be written: the input is unstructured, the pattern is real but not articulable, or the variation is too wide to enumerate. Those are genuine, and they are a minority of what a business system does.
The four properties that decide it
When a rule will not do, four properties determine whether a model is appropriate for that specific component.
Consequence of a wrong answer. A wrong suggestion a user can ignore is cheap. A wrong action taken automatically is not. The higher the consequence, the more the model belongs in an advisory position with a person deciding.
Whether wrongness is visible. Some errors announce themselves; others look exactly like correct answers. Silent plausible errors are the dangerous category, and they argue for either a verification step or a different approach entirely.
Latency, at the point of use. A counter operation happening hundreds of times a day cannot wait two seconds for a model. This alone disqualifies models from many of the places they get proposed.
Cost per invocation. Free at demonstration volume, material at production volume. Worth calculating before the design is committed rather than after.
Where it earns its place in operations
The jobs that recur across the systems we build, where a model is genuinely the right component:
Unstructured input. Extracting fields from a supplier invoice, a document, a photograph. There is no rule for this, and the alternative is manual entry.
Anomaly surfacing over history. Finding the transactions worth a human's attention, from a pattern nobody wrote down. Note the framing: surfacing for review, not acting.
Language. Search that tolerates how people actually phrase things, or handling multiple languages in one field.
Forecasting from real history, where enough history exists. This last condition disqualifies more proposals than any other — most businesses asking for prediction do not yet have the data it requires.
The common shape is that the model produces something a person then uses. Where a model's output is acted on automatically, the consequence question above becomes the whole design.
Where it is decoration
A chatbot over a form. Most business interactions are a small set of specific tasks. A dropdown that does the job in one tap does not benefit from being conversational.
A summary of a screen already visible. If the number is on the page, generating a sentence about it adds latency and a chance of error.
Predictions without history. A confident forecast from three months of data is a confident guess.
Anything where a rule already worked. Replacing a working deterministic feature with a model is a downgrade dressed as an upgrade.
Features added because a competitor announced one. The most common reason, and it produces the least-used parts of most systems — which is also a maintenance obligation, as maintaining software over years argues.
What has to be true when we do use one
Four commitments, applied consistently:
A person can see why. Not necessarily model internals — the inputs, the evidence, and enough for someone to disagree.
Uncertainty is reported rather than hidden. A system that returns a confident answer for a case it could barely distinguish is worse than one that says it is unsure. That principle appears across everything we build, including crop diagnosis confidence scores.
There is a path when it is wrong. An override, a correction, a manual route. Anything a person cannot correct will be worked around instead.
It fails to something rather than nothing. If the model is unavailable, the operation continues — degraded, not stopped. A counter that cannot bill because an inference service is down is an architectural error.
The honest cost
Three costs that get omitted from the decision and shouldn't be.
Running cost that scales with use, unlike the rest of the system.
A dependency on someone else's service, with its own availability, pricing and lifecycle. Where that dependency sits on the critical path, it is now part of your uptime.
Behaviour that changes without you changing anything. An upgraded model can alter outputs a business had come to rely on. This is unusual among software components and worth accounting for.
The counterpart on the buyer's side — what to ask a vendor claiming AI — is in what "AI-powered" should mean in business software, and the security and data-handling questions in security and data ownership in client systems.
What we build
Truffaire has delivered ten operational systems across ten clients, and separately builds ARCORA and SYNTAX, both of which use machine learning centrally because their core jobs — diagnosis from photographs, and conducting a spoken clinical encounter — cannot be expressed as rules.
That contrast is the whole position. In products where the hard problem genuinely requires it, it is the substance. In business operations software, most of what makes a system valuable is correct, fast, deterministic behaviour at a counter — and adding a model there usually makes the demonstration better and the system worse.
Frequently asked questions
How do we know if a vendor's AI is real?
Ask what happens when it is wrong and how often it is. A vendor with an answer has run it in production; one without has run a demonstration.
Is it cheaper to use an API or build a model?
For most business applications, an API — building and maintaining a model requires data and expertise that rarely justify themselves. The trade is control and dependency.
What about data privacy when using external services?
It has to be settled before the design commits, because it constrains what can be sent. Some categories should not leave your infrastructure at all.
Will this become standard in all business software?
In the places it genuinely helps, yes. The current phase, where it is added to demonstrate modernity, will pass — as it has in every previous technology cycle.
Should we wait until it matures?
Not as a blanket position. Decide component by component, using the four properties above. That decision is stable regardless of how the field moves.
Where to start
Take any AI feature you have been offered and ask whether a rule would do the same job.
If it would, you are being sold latency and running cost. If it genuinely would not, the next question is what happens when it is wrong — and the answer to that determines whether it belongs in the system at all.
The wider set of engineering positions this sits inside is in how Truffaire builds software.
If you want a system where each component is chosen on merit, get in touch.