JYnapse Knowledge Base · Free to read · ~12 min
Every business weighing which one to invest in hits the same wall. The honest answer is that it isn't a straight choice — here's the distinction that actually decides what you build, and in what order.
The short answer, if you read nothing else
Automation executes a decision that has already been made. AI makes the decision that nobody ever wrote down.
Almost every real workflow needs both — and in that order, because automation is cheaper, deterministic and auditable, while AI is none of those three. You buy AI only for the steps where a human is currently supplying judgment that a rule genuinely cannot capture.
So the useful question is never "do we need AI or automation." It is: for this specific step, is the rule writable? If yes — automate it. If no — that is exactly where AI earns its cost, and nowhere else.
The confusion isn't really about technology. It's that the two words describe different parts of a task, not competing ways of doing the same task.
Automation is execution. The rule is known and writable, the input arrives in a predictable shape, the output is defined. Same input, same output, every single time — which is precisely why it is safe to put in front of a regulator or a client. It is cheap to run and it fails loudly and obviously when the underlying form or screen changes.
AI is judgment under uncertainty. Either the rule exists but nobody has written it down and it has to be learned from history — that's machine learning — or the rule is unwritable because the input is human language, a photograph, a scanned report. AI returns a best guess with a confidence, never a guarantee.
And "AI" itself covers four families that have almost nothing in common operationally:
| Family | The question it answers | What it needs from you |
|---|---|---|
| Predictive ML | How likely? How much? | Years of clean, labelled history. Volume matters more than cleverness. |
| Computer vision | What is in this image? | Labelled images. Consistent capture conditions. |
| Generative AI / LLM | What does this text say? Draft this. | Almost nothing up front — which is why it's the entry point, and why it's over-bought. |
| Agentic AI | Run a multi-step task and choose the next step. | A stable process underneath it. Without that, it amplifies mess. |
Automation, by contrast, isn't a tier of intelligence — it's a discipline: scripting, RPA, workflow, systems integration. It can be entirely rule-based, or it can have AI sitting inside one of its steps. When it does, the industry calls it intelligent automation.
The policy wording is automation. It is a rule written in advance and applied identically to every claim, by anyone, in any office. Fire, lightning, explosion, bursting or overflowing of water tanks or pipes, windstorm — in or out. It is deterministic, it is auditable, and it does not care how it feels about the case in front of it.
The loss adjuster is AI. He exists because the wording could not anticipate everything. Was that damage bursting and overflowing, or gradual seepage that has been quietly happening for two years? He works from pattern and precedent, produces a judgment with a degree of confidence attached, and he can be wrong.
A wording without adjusters cannot settle a real claim. Adjusters without a wording give you a different answer every time.
That is the entire argument. Nobody in insurance asks whether to have the policy document or the adjuster — you need both, and everyone knows it. When people ask "AI or automation," that is structurally the same question they are asking, just with the answer less obvious.
Before choosing a technology, work out which rung the problem is standing on. Never buy a rung you have not earned — the failure mode is always the same, a rung-4 solution bought for a rung-2 problem.
For a smaller firm, most of the available value sits on rungs 1 to 3. That is not a modest claim — it's the reason the honest answer really is "start with automation," even though the second half of the sentence is "and it will not stay pure automation for long."
The abstract distinction is only useful once it touches actual work. Eight candidates, and what I'd honestly recommend for each:
| The workflow | Right rung | Why — and what not to do |
|---|---|---|
| Renewal calendar across a book of buildings | 3 — pure automation | Expiry dates, notice periods, document chasing. The rule is a date. No AI required or wanted. A wall planner with the dates circled is the manual version of this — it works, it just doesn't scale past the number of buildings you can hold in your head. |
| Quotation comparison for a JMB committee | Hybrid — 3 + 4 | Five insurers, five formats, PDFs and email bodies. Let an LLM extract the fields — sum insured, excess, perils, extensions, exclusions, premium. Then let a spreadsheet or a script do the arithmetic and the formatting. Never let the model do the maths. |
| Comparing policy wordings and exclusions between insurers | 4 — GenAI | The single strongest use of an LLM there is: a pure language-comparison task on documents nobody enjoys reading. Human sign-off is not optional — a hallucinated exclusion is a professional indemnity event, not a bug. |
| Claims history → recurring risk patterns for renewal negotiation | 2 → 3 → 4 as data grows | Start with a clean claims register and a dashboard — frequency, severity, peril mix, loss ratio by building and by year. On a small book that descriptive layer often tells you most of what you need. As the history builds up, predicting drop or renewal risk per building becomes a real ML problem worth the effort — it scales with how much data you hold, so earn the dashboard before you reach for the model. |
| Sum insured adequacy / underinsurance flag | 4 to estimate · 3 to decide | Two jobs hiding in one line. Estimating the reinstatement value — cost per square foot for this age, construction, location, finishes — is a genuine prediction problem, and with enough historical rebuild-cost data an ML model will beat a flat rule-of-thumb, which is precisely why underinsurance is so common. But the adequacy flag itself — is the sum insured below that value? — stays a rule, because that's the number that lands in front of the client. Model estimates the input, rule makes the call. |
| Drafting a site risk survey from photos and field notes | 4 — GenAI, assembly by 3 | Your template, your findings, your recommendations. The model types the first draft; you edit it into something you'd sign. Saves the typing, not the thinking. |
| Sanctions and compliance screening | 4 to screen · 3 to decide | ML earns its place on the screening side — fuzzy name-matching and entity resolution are real, useful jobs it does well. But the pass/fail decision at the end stays a rule. A rule that is occasionally over-cautious is defensible to Bank Negara; a model that was 94% confident is not. Let AI surface the hits, keep the gate deterministic. |
| Climate and flood exposure at a specific location | Buy, don't build | These models already exist and are better than anything either of us would build. Your edge isn't rebuilding them — it's translating what they say into a coverage recommendation a JMB committee will actually approve at an AGM. |
Notice the shape: ML and LLMs are strong on the messy input side — extracting, estimating, drafting. But the final number that goes in front of a client or a regulator, and the compliance decision, are computed by a rule. Model for the estimate, rule for the call. It's the same split as the non-determinism fix in §6, and it's why "does this use AI?" is almost always the wrong question — most of these are AI and rule, doing different jobs in the same workflow.
During my year at Maxis in Network Digital Engineering, there was a monthly submission to the MCMC on spectrum assignment. Data came out of several systems, got merged and reconciled in Excel by hand, colour-coded for the eye to catch gaps, argued about over email, and consumed a meaningful share of two people's month. Every month. Forever.
We took it apart step by step:
| Step | What it became |
|---|---|
| Inbound trigger | An email arrives → the pipeline starts itself. Rule. |
| Merge & reconcile | Python and pandas instead of manual Excel joins. Rule. |
| Missing-value checks | Validation rules plus an automated alert to a named person. Rule. |
| "Where are we?" | A dashboard, so the status was visible instead of being asked about. Rule. |
Days of work became hours. Now note what actually did the work: none of it was AI. The genuinely AI-shaped parts — summarising a long attachment, drafting the covering note, answering a question about the data in plain English — were a later layer, and they only became worth adding once the pipeline underneath them was boring and deterministic.
The AI is the last ten per cent. It is also the first thing everyone wants to buy.
Do the arithmetic before, not after: hours saved × frequency × loaded hourly cost, against build effort plus maintenance. If payback runs longer than the tool's realistic life, don't. The honourable exception is learning — sometimes five hours spent to save five minutes is tuition rather than return. That's fine. Just call it what it is on the day you decide, not afterwards.
This one costs real money, and it is not obvious from the outside. On a production generative-AI system I work on, the same input can return a different output on different calls — even with the randomness setting turned to zero. The cause sits in how requests get batched and routed across shared model infrastructure, and it is not something you can configure away.
If that output is a number going into a client document, that is fatal. The fix we settled on is hybrid: let the model decide which rule applies — a language judgment, which is what it's good at — then let ordinary deterministic code compute the number. Model for judgment, code for arithmetic. If you take one engineering opinion from this note, take that one.
The tool market is optimised to sell a rung-4 answer to a rung-2 problem, because rung 2 has no vendor. The discipline is to identify the pain point first and let it choose the technology, rather than acquiring a technology and going looking for something to point it at.
| On your own hardware | Cloud API | |
|---|---|---|
| Data | Never leaves the building. Simplest possible answer to a client asking where their claims file went. | Leaves your boundary. Enterprise terms typically exclude your data from training — read them, don't assume them. |
| Cost shape | Capex, then largely fixed. Predictable. | Per-token, scales with volume, and surprises people in month three. |
| Capability | Open models are strong and improving, generally a step behind the frontier. Plenty for extraction, classification, summarising, drafting. | The strongest models available, immediately, with no hardware decision. |
| Burden | Yours: patching, power, cooling, someone who knows how it works when they're on leave. | Theirs. |
Split by data sensitivity, not by task. Anything carrying a client name, IC, policy number or claim reference goes to the local model. Anything generic — drafting from a de-identified brief, summarising a public wording, research — goes to the cloud where the capability is better and the exposure is nil.
And the classifier that decides "does this leave the building" should be a rule, not a judgment call. Rung 3 protecting rung 4. That is exactly the pattern in §1's diagram.
One cost discipline worth knowing: with LLMs you pay per unit of text going in, so never feed a whole dataset into a prompt. Aggregate it first in SQL or pandas, send the summary. I've seen more budget wasted on that single mistake than on anything else.
Straight answer, both halves of it.
In a large back office where a dozen people perform one repetitive collation process, automation genuinely does displace roles, and anyone who tells you otherwise is selling something. The exposure sits almost entirely with work that is purely collation, re-keying and format conversion.
In a smaller advisory firm, the realistic outcome is different: the same team services more buildings, and the senior people spend their hours on the site assessment and the renewal negotiation instead of on assembling the comparison table. The roles that get stronger are the ones where judgment is the product — which, in this kind of business, is very nearly all of them. What gets automated is the part of the job nobody was hired for.
Automation is how the work moves. AI is how the work decides. The question isn't which one to buy — it's which rung the work is standing on.
This is how JYnapse approaches every project: start from the decision, not the tool. If you'd like to work through your own list line by line, book a free consultation.
Scope. The examples here are illustrative, meant to make the ideas concrete rather than to describe any particular business.
About the author. JY is the founder of JYnapse and an AI/ML engineer with a master's in data science, building production GenAI, machine-learning and automation systems for businesses in Malaysia and beyond.