When not to use a language model
Every engagement now begins with the same question: can we use AI for this? The honest answer, more often than clients expect, is: yes — but not the AI you have in mind.
Language models are extraordinary at one thing: transforming unstructured language. They summarise, rephrase, classify, extract, draft, and converse better than anything we have built before. They are also expensive per call, probabilistic by design, and occasionally wrong in confident and creative ways.
That is a trade worth making in some situations and ruinous in others. Knowing which is which is most of the value we add.
Five times to reach for something simpler
When the answer must be exact. Prices, balances, interest calculations, eligibility rules. A lookup table cannot hallucinate a number; a model can. If an incorrect answer creates a legal, financial, or safety exposure, the deterministic path wins — and a model can still sit in front of that path, turning a customer's question into a query.
When the rule already exists and is stable. If your business already has an unambiguous policy — "orders over R5 000 need a second approval" — encode the policy. A model asked to apply it will be right almost every time, which is precisely the problem: almost every time is not a policy, it is a liability.
When you cannot describe what "good" looks like. If you cannot articulate the criteria for a correct output, you cannot evaluate the system, and you will not know when it degrades. Start by writing down twenty examples of good and bad answers. That exercise alone often reveals that the real problem is a process problem, not an AI problem.
When the volume makes the economics absurd. Classifying ten thousand documents a day through a frontier model has a monthly bill attached. A small fine-tuned classifier — or often a well-built logistic regression on decent features — can do the same work for a fraction of the cost, faster, and with a confidence score you can actually threshold.
When the answer must be explainable. In regulated environments, "the model produced this" is not an explanation. Simpler models trade a little accuracy for the ability to show your working — and in a compliance conversation, showing your working is the accuracy that counts.
Where language models genuinely earn their keep
The mirror image of that list is where we do reach for them without hesitation: unstructured text that would otherwise need a human to read it; conversation across a large body of internal knowledge; drafting that a person will review; extraction from documents that never had a consistent format; and the long tail of tasks too varied to enumerate and too small to justify their own system.
The pattern is easy to see once you look for it. Language models are best where the alternative is a person reading something, and worst where the alternative is a computer looking something up.
What this means for a first project
The projects that succeed tend to share a shape: a task that today consumes hours of human reading, where a good answer is recognisable when you see it, where being wrong occasionally is survivable, and where the volume is high enough to matter but the stakes of any single output are low enough to tolerate review.
If a proposal on your desk does not have that shape, it is not necessarily a bad idea. But it may be a database problem, a process problem, or a hiring problem wearing an AI costume — and the cheapest moment to discover that is before the budget is approved, not after.