When Do You Actually Need AI in Automation?

The AI hype meets day-to-day automation

There's a pattern we keep seeing with companies that are starting to look at automation right now: the first question is "should we use AI?". Soon after comes a demo of a language model reading invoices, classifying email, or chatting with customers.

The demo looks impressive. It feels smart. But once it's running a hundred thousand times a year, the cracks start to show: unpredictable outputs, costs higher than anyone planned for, and a system that's hard to debug when something goes wrong.

That's not AI's fault. It's the wrong tool picked for the job.

This post is about how we think about AI in our automations: what should be deterministic, where language models actually add value, and how to avoid building a system that ends up expensive and fragile when it doesn't have to be.

Deterministic vs. probabilistic automation

There are two fundamentally different ways to handle a step in an automated flow:

Deterministic means the same input always produces the same output. The rules are written ahead of time: "if the amount is over €5,000, send for approval." You can test it, you can trust it, and it's essentially free to run.

Probabilistic means the system makes a judgment call. The same input might produce different outputs at different times. A language model that reads an email and decides whether it's a support ticket or a sales inquiry is probabilistic. It's right almost always — but not always.

Most real-world flows need both. The trick is knowing which fits where.

Three questions that decide it

When we design a flow, we ask three questions for every step:

1. Can it be described with clear rules? If yes — use rules.
2. Is the input structured? Amounts, dates, options picked from a dropdown — structured data is best handled with code.
3. What happens if the system gets it wrong? If the error is caught immediately and can be corrected, probabilistic is fine. If the error could move further downstream undetected, avoid it.

If all three questions point to a deterministic solution, the step should be deterministic. It's cheaper, faster, and more reliable. Full stop.

Where AI actually earns its place

That said, there are tasks where a language model is genuinely better — and they're worth highlighting, because they're usually what justifies the architecture in the first place:

Unstructured text

Reading an email written by a customer and figuring out "what does this person want?". Interpreting an invoice where every supplier has their own format. Pulling key figures out of a PDF report.

These are classic AI tasks. Solving them with rules turns into thousands of if-statements that still break the moment a new variation appears.

Classification with many categories

When you have 30+ categories and every incoming item needs to be sorted into the right one — and the categories are described in words, not numbers — AI is often the right call. Maintaining the rules manually simply doesn't scale.

Summaries and drafts

Summarizing a long support conversation into an internal note. Drafting a reply that a person then approves. AI is good at saving time here — as long as a human is still in the loop on the final step.

The architecture we actually use

In most of our projects the system looks roughly like this: a deterministic skeleton with small, well-scoped AI calls in the few places where they genuinely add value.

A concrete example — automated handling of incoming sales inquiries by email:

1. The email is received by a rule-based integration. No AI involved.
2. AI reads the email and extracts three things: contact name, approximate budget if mentioned, and what type of service the prospect is asking about. This is one well-defined LLM call with structured output.
3. The rules take over again. Is the budget above a threshold? Then a deal is created in the CRM and a notification goes to sales. Is it a standard inquiry? Then an automated reply goes out with pricing and a calendar link.
4. Logging and traceability — every step is recorded. What the AI extracted, which rules fired, what the outcome was.

Note that AI is only used in one place — where it's genuinely better. Everything else is plain code and rules. That makes the whole flow cheap to run, easy to debug, and easy to extend.

What this means for cost

It's not unusual to see systems where a language model is called at every step of the flow. When that happens, cost becomes a problem fast.

A worked example: a company processing 50,000 incoming emails a month. If every email runs through three LLM calls, that's 150,000 calls. With a modern model API the bill can quickly hit several hundred euros a month — for one part of the flow alone. Same volume but only one LLM call per email, plus rules for the rest, and the cost can often drop to less than a third.

It's not just a price question. Fewer AI calls also means faster flows, fewer potential points of failure, and less dependency on a third-party API working precisely when you need it.

Three common pitfalls

When companies build AI-heavy flows, the failure mode usually comes down to one of these:

1. AI used where a rule would do

The most common mistake. "If the total is above X, send for approval" is a rule — not an AI task. When we see language models used for simple numeric thresholds or date arithmetic, it's almost always a sign that the team started with the AI tool and went looking for a problem to solve.

2. No human checkpoint on high-impact steps

If an automation can move money, sign contracts, or contact customers on the company's behalf — and the only thing standing between that and a mistake is a language model's judgment — the architecture is wrong. Add an approval step or a rule-based guardrail.

3. No way to see what the AI actually did

If something went wrong last week, you need to be able to go back and see exactly what the AI decided and why. Without logs the system is a black box, and on the day something does go wrong — and it will, eventually — you'll have nothing to work from.

How to think about your next automation

When you're looking at a new process and wondering whether AI should be part of it, try this checklist:

• Write down the steps in the flow, one at a time
• For each step, ask: can this be expressed as rules?
• Mark only the steps where the answer is clearly no — that's where AI belongs
• Think through what happens if the AI gets it wrong at that step, and add a checkpoint if the impact is high

The result is usually a system where 80–90% is rule-based and 10–20% is AI. That's where we see the most stable, cost-effective, and maintainable automations.

In short

AI is a powerful tool, but it's one tool among several. In a well-built automation it isn't the leading role — it's the specialist you call in when ordinary rules aren't enough.

When we help clients build automations, one of our first jobs is to sort out what genuinely needs AI and what doesn't. The result is almost always a simpler, cheaper, and more reliable system than the one people first imagined.

Want a concrete read on which parts of your processes fit deterministic automation and where AI would actually move the needle? Get in touch and we'll go through it together.