We are hired to put AI into businesses, and a meaningful share of what we recommend contains no AI at all. That is not modesty. It is that a language model is an excellent solution to one kind of problem and a poor solution to several others, and the difference is easy to state.
| Question | AI | Traditional automation |
|---|---|---|
| Best input | Documents, messages and ambiguous language | Structured records and known events |
| Best decision | A fuzzy boundary learned from examples | A rule that can be written and tested |
| Output | Probabilistic and confidence-scored | Deterministic for the same input |
| Control | Evaluation, thresholds and human review | Tests, validation and explicit exceptions |
| Typical role | Read, classify, retrieve or draft | Calculate, route, validate, integrate and record |
Use AI when the input is unstructured or the rule cannot be written
- Reading a document, an email or a form whose layout varies and cannot be standardised.
- Classifying free text into categories where the boundary is fuzzy and examples teach it better than rules.
- Finding the relevant passage across thousands of documents in response to a question in plain language.
- Summarising something long for a person who then makes the decision.
- Drafting a response that a human reviews before it goes out.
What these have in common: the input resists structure, and a person doing the job would also be exercising judgement rather than following a rule.
Use ordinary software when the rule exists
- Arithmetic. Totals, tax, margin, discounts. A model can do it and will occasionally be wrong, which is an unacceptable trade for something a computer has done perfectly since 1972.
- Lookups against a system of record. If the answer is in the database, query the database.
- Deterministic routing. If approval over $10,000 goes to the CFO, that is an if statement.
- Validation against known constraints. Formats, ranges, required fields, referential integrity.
- Moving data between two systems that both have APIs. That is an integration.
A rule you can write down should be code. Code is cheaper, faster, testable, auditable and gives the same answer twice.
The four costs of using AI where it was not needed
- 1Non-determinism. The same input can produce a different output. For a summary that is tolerable. For a tax calculation it is a defect.
- 2Latency and cost per item. Milliseconds and fractions of a cent become seconds and real money at ten thousand items a day.
- 3Auditability. "The model decided" is not an answer your finance team or your auditor will accept about a threshold that could have been a rule.
- 4Fragility. Model updates change behaviour. Something that was a stable if statement should not acquire a release cycle it did not need.
The shape almost every good system takes
Not AI or software. AI at the edges, software in the middle. The model does the part that resists structure — reading the document, classifying the request — and hands a structured result to ordinary code, which validates it, applies your rules deterministically, and writes it to the system of record. A confidence threshold decides what a person looks at.
That architecture is why we can tell you what the system will do. The unpredictable component is confined to one step, its output is checked, and everything downstream of it is testable.
How to test a vendor
Ask which parts of the proposed system do not use AI, and why. A vendor who cannot name any is either not thinking about your problem or is selling you the component they happen to sell.