AUTOMATIONOR ARTIFICIALINTELLIGENCE

An automation is a rule somebody wrote and a machine repeats. A form arrives, it creates the record, sends the email, updates the row. Same input, same output, a year from now. A model doesn’t repeat a rule: it infers one from thousands of examples. Ask what an email is about and it answers with the likeliest thing. It’s usually right, and “usually” is not “always”. You check an automation by reading it. A model only on real cases.

• The rule can be written down

  The input arrives in fields: columns, codes, a completed form. You can say in words what to do in every foreseen case. If the explanation ends, that’s automation and a model adds only a bill.

• The input is free text

  An email a client wrote their own way. A PDF laid out differently every time, a handwritten note. A rule won’t hold here, and this is where a model earns its keep.

• It calls for judgement, not a decision

  Classifying, summarising, working out what a message asks for. These are tasks with a better answer, not a right one. That’s where a model is worth paying for.

• The mistake is expensive and quiet

  If being wrong means a wrong invoice or confidential data in the wrong place, “nearly always” isn’t enough. At those points a model goes in only with a person confirming first.

1. 01

   I write the rule out in words

   I take the step and write it as an instruction for a new starter. Not in code: in plain English, with every case and the exceptions people only say out loud.

2. 02

   I find where the page breaks

   If the instructions cover everything, it’s automation and the diagnosis ends here. If I have to write “it depends”, I’ve found the exact spot where judgement is needed.

3. 03

   I isolate that spot, and only that

   One step, not five. Ordinary automation stays around it, cheaper and predictable. The model gets the part that can’t be written down.

4. 04

   I try it on your real cases

   Closed cases, where the right answer is already known. I measure how much it resolves, how often it’s wrong, and what that volume costs a month. If it doesn’t hold up, I say so before building.

5. 05

   I set a boundary and a check

   What the system doesn’t decide on its own, who confirms, and where you see it got something wrong. A model inside a process without that point isn’t something I hand over.

I sell AI consulting too, so I have an interest in saying yes. The most frequent case isn’t a company that needs a model. It’s two tools that need to talk to each other. Those are automation problems: cheaper, and they don’t fail a new way each week. Half the job is saying which steps are better left alone. When the diagnosis says that, the AI work stops there. (Consulting that always reaches the same answer is a catalogue.)

Cost

An automation costs to build and then almost nothing. A model costs on every call, and the bill grows with use.

Verification

An automation is checked by reading the rule. A model only against a sample of real cases, measured before and after.

The kind of failure

An automation goes wrong the same way every time and gets caught. A model goes wrong on one case and is fine on the rest.

Maintenance

An automation breaks when a connected tool changes, and you notice. A model degrades when the data changes, without breaking.

Data

An automation can stay inside the tools you already have. A model sends text to an outside supplier: which data leaves, and to whom, gets settled first.

Supervision

A system that decides on its own, with no point where a person can stop it, isn’t something I hand over. That holds for automations that touch money too.