When not to use AI

Being able to add AI does not mean you should. Knowing when to leave it out is part of doing this credibly — and it is what separates an engineer from a hype merchant.

Don't use AI when a rule is exact and known

If the logic is deterministic — a price table, an availability check, a tax calculation — use code. A model introduces cost, latency and a chance of being wrong in exchange for nothing. See AI vs deterministic.

Don't use AI where a mistake is unacceptable and unrecoverable

If there is no room for a human to catch and correct an error — an irreversible payment, a safety decision, a legal ruling — do not place a probabilistic system in the critical path. Keep it advisory at most, with a person accountable.

Don't use AI to paper over a broken process

If the underlying workflow is chaotic, automating it just produces chaos faster. Sometimes the honest recommendation is a cleaner process, a checklist, or a small integration — not AI. Say so; the trust you earn is worth more than the sale.

Don't use AI when the data can't leave

If a customer genuinely cannot allow their data to be processed by a given service and there is no viable private deployment, the responsible answer may be "not yet". Forcing it is a privacy incident waiting to happen. See data protection.

Don't use AI where the economics don't work

Some tasks are cheap to do by hand and rare. Automating them costs more to build and run than they will ever save. Do the arithmetic before building.

The honest alternative

Part of this catalogue's premise is intellectual honesty: if AI would commoditise the very thing you are selling, or if a non-AI approach — a trade, property, infrastructure, a simpler tool — serves the customer better, that is the right recommendation. Technology does not automatically win.