When Not to Use AI: A Decision Framework
The discipline that separates good AI engineering from hype is knowing when not to use it. A practical framework for deciding when a model is the wrong tool for the job.
There is a quiet skill that separates teams who build AI that lasts from teams who ship impressive demos that quietly get switched off: knowing when not to use it. In a climate where every problem is being handed to a language model, the discipline to say "this one doesn't need one" is rarer and more valuable than the ability to build the model in the first place. Reaching for AI when a simpler tool would do is not innovation. It is added cost, latency, and failure surface, wearing the costume of progress.
Here is the framework we actually use to decide.
Is the problem deterministic?
The first question is whether the problem has a single correct answer that can be computed by a rule. Calculating a repayment, validating a form, routing a request by a fixed condition, checking whether a value falls within a range — these are deterministic. They have exactly one right answer, and a few lines of ordinary code will produce it correctly every time, for free, instantly, and transparently.
Putting a language model on a deterministic problem is a category error. You take something that was reliable and cheap and make it probabilistic and expensive — introducing the possibility of a wrong answer where none existed, and paying per request for the privilege. If the problem can be solved by a rule, solve it with a rule. AI earns its place only where the problem is genuinely ambiguous, where there is no clean rule because the input is messy, unstructured, or open-ended.
What does being wrong cost?
The second question is the cost of error. AI systems are probabilistic; they will sometimes be wrong. Before deploying one, you have to ask what happens when it is, and whether you can live with that outcome.
For some problems, an occasional wrong answer is easily absorbed — a slightly off suggestion, a draft a human will review anyway. For others, a single wrong answer is unacceptable: it moves money incorrectly, gives advice someone acts on, or makes an irreversible change. The higher the cost of being wrong and the harder it is to catch before it causes harm, the higher the bar for using a probabilistic system at all — and the more of your engineering has to go into constraint, verification, and human review rather than into the model itself.
Can you tell whether it's working?
The third question is measurement. Before you build, ask how you will know whether the system is doing its job. If you can define what a good output looks like and measure it, you can build, evaluate, and improve responsibly. If you cannot — if quality is a matter of impression with no way to test it at scale — you are not building a system, you are hoping, and hope does not survive contact with production.
Unmeasurable AI features are where projects quietly rot. They demo well, ship, and then slowly drift or degrade with nobody able to say by how much, because there was never a way to tell. If you can't measure it, either invest in making it measurable before you build, or don't build it.
The framework in one pass
Put together, the decision is a short sequence. Is the problem deterministic? Then use a rule, not a model. Is it genuinely ambiguous? Then a model may fit — but what does being wrong cost, and can you constrain and verify enough to live with it? And can you measure whether it works well enough to improve it over time? Only a problem that is genuinely ambiguous, whose errors you can afford or catch, and whose quality you can measure, is a good candidate for AI.
This framework disqualifies a lot of the things people are currently trying to build with language models, and that is the point. The value of a disciplined "no" is not just the cost you avoid on the wrong project. It is the focus you keep for the problems where AI is genuinely the right tool — where the input really is too messy for a rule, and a model does something no amount of ordinary code could. Those problems are real, and they are worth doing well. Saying no to the rest is how you protect the capacity to.