When NOT to use artificial intelligence
AI is a tool, not the architecture. Four real systems where the decision was made about which part deserved a model and which part worked better with rules.
These days almost every project arrives with the same question: “where do we put the AI?”. It’s an understandable question, but it’s asked backwards. The useful question is a different one: what does this system need?
Sometimes the answer is an AI model. Many other times it’s a clear rule, an SQL query or a server-side validation. AI is a very powerful tool, but that’s what it is: a tool. It isn’t the architecture.
A simple rule
If you can write the rule, write the rule.
Deterministic software is faster, cheaper, more predictable and easier to test. It does exactly the same thing every time. AI adds value when the problem has something that doesn’t fit fixed rules: ambiguous natural language, images, expert judgement, variation.
That’s why arithmetic, regulatory compliance, permissions, file formats and anything that has to come out the same every time should stay on the deterministic side. Here are four systems where that decision was made.
Gustela CRM: conventional features when AI adds nothing
Gustela CRM runs a prospecting sales process: pipeline, batched campaigns with a daily limit, follow-up tasks and automatic exclusion of anyone who mustn’t receive more messages.
All those rules are clear. Nobody who has opted out, bounced or been marked “do not contact” can get back into the queue, and that’s enforced on the server before anything is queued. This system uses no AI: nothing in the process needed it, and adding it would have added cost and uncertainty without adding capability.
Zentia: deterministic rules when they’re enough
Zentia lets people search for properties in natural language. A phrase like “villa with a pool in Marbella up to 500k” is turned into filters for type, area, price and features, which appear as editable chips.
It looks like a textbook case for an AI model, but the interpretation is handled with rules. The vocabulary of a property search is bounded, and rules are fast, predictable and cost nothing per query. If a rule gets it wrong, it shows in the chip and gets corrected.
Zentia case study: natural-language search handled with rules
RetoQ: AI for judgement, software for the result
RetoQ does use AI, and a lot of it: a vision model assesses each photograph against a five-criterion editorial rubric and proposes three edits with Lightroom values. That’s exactly the kind of judgement that doesn’t fit fixed rules.
But the AI doesn’t get to do everything:
- The score is calculated by the server, not the model: it’s the sum of the five criteria times two. Arithmetic isn’t entrusted to a model.
- Responses go through strict JSON schemas. If the model returns an out-of-range score, the whole assessment is rejected.
- The .xmp file is written by the system. A second model proposes attribute names; the server builds the XML and discards anything it doesn’t recognise. The preset is always valid, even if the model slips.
- The product says what it doesn’t do: the preset’s masks are geometric and don’t detect the sky, even if one is called “Sky”.
The model judges; the server calculates.
AtalayaIQ: AI with bounded access and verifiable data
AtalayaIQ is an intelligence layer over seven years of a national events company’s operational data. It has an assistant for asking questions about the report, but the model’s access is closed by design:
- The model chooses an operation from a closed catalogue; the server validates the parameters and runs fixed, parameterised SQL.
- The model doesn’t write SQL and never sees credentials or tables outside the catalogue.
- Only the question, the text history and aggregated results go to the provider.
- Alerts aren’t decided by the AI: they come from seven deterministic rules, each with its evidence.
And everything the system states has been reconciled independently with hand-written SQL. The AI answers questions about data that’s already known to be true.
Questions to ask before adding AI to a process
Before deciding, it’s worth answering these questions:
- Can the rule be written down? If it can, you probably don’t need a model.
- What happens when it gets it wrong? Who notices, and what does the mistake cost?
- Which part has to be exact and reproducible? That part goes on the server.
- What data does the model access, and what goes out to the provider?
- How much does each call cost, and who sees it before the money is spent?
If, after answering them, AI still adds something rules can’t, go ahead. With clear limits, tidy data and software that bounds it, that’s when it works best.
The question isn’t where to put AI, but what the system needs.
If what you have in front of you is a specific process, AI process automation explains how I choose, step by step, between rules, integrations, AI and human approval.
AI automation for businesses covers how I design systems that use AI where it helps and conventional software where it’s the better answer. And if you don’t yet know which of your processes suit AI, AI consulting explains how I diagnose it before building anything.