When not to use AI
The cases where a rule, a query or a form beats a model — from a studio that builds AI for a living.
We build AI products, and a meaningful share of our discovery work ends with us advising against one. Knowing where the boundary sits is most of what makes the technology useful.
When the rules are known and stable
If the logic can be written down and does not change often, write it down. A rules engine is faster, cheaper, testable, explainable and correct every time. Using a model to approximate a deterministic rule is strictly worse.
The cheaper thing, and when it wins
Known, stable logic
- Reach for
- A rules engine
- Instead of
- A model approximating a rule
Unstructured intake
- Reach for
- A better form
- Instead of
- A classifier cleaning up after a bad one
No recorded outcomes
- Reach for
- Instrumentation
- Instead of
- Training on data that does not exist
Low volume
- Reach for
- Leaving it manual
- Instead of
- A build that never repays itself
| Reach for | Instead of | |
|---|---|---|
| Known, stable logic | A rules engine | A model approximating a rule |
| Unstructured intake | A better form | A classifier cleaning up after a bad one |
| No recorded outcomes | Instrumentation | Training on data that does not exist |
| Low volume | Leaving it manual | A build that never repays itself |
When you cannot tolerate being wrong
Some decisions have no acceptable error rate. Statutory calculations, safety interlocks, financial reconciliation — these want deterministic systems. A model can assist the human who reviews them; it should not be the mechanism.
When the volume does not justify it
Automating a task that happens eleven times a month will not repay the build, the evaluation and the ongoing maintenance. Count first. This eliminates more proposals than any technical constraint.
When the data does not exist
No amount of modelling substitutes for evidence about the thing you want to predict. If nobody has recorded outcomes, the honest first project is instrumentation — and it is a good project.
When something else is the better tool
A meaningful share of our discovery work ends with one of these.
- The rules are known and stableWrite the rule
- The process itself is brokenFix the process
- Nobody has recorded outcomesInstrument first
- It happens a few times a monthLeave it manual
- No acceptable error rateKeep it deterministic
When the real problem is upstream
A large share of AI requests are attempts to paper over a process that does not work. Building a model to classify inbound requests that arrive unstructured because your form is bad is expensive. Fixing the form is cheap.
- A rule would do → write the rule
- The process is broken → fix the process
- The data is missing → instrument first
- The volume is low → leave it manual
- The error cost is unbounded → keep it deterministic