When not to automate

Automation means a step runs by itself without you pressing a button each time: each incoming e-mail is categorised, each form is summarised, a report is made every morning. With AI the temptation is strong, because almost everything feels automatable. Before starting, judge the task with three questions:

1. How often? A task that happens dozens of times a day saves a lot of time when automated. A task that happens twice a year is rarely worth building and maintaining automation for.
2. How costly if wrong? Mislabelling an e-mail folder is cheap. Sending the wrong warning letter, wrongly rejecting a claim or paying a vendor wrongly is expensive, and often involves people.
3. Can it be undone? A wrong label can be changed. An e-mail already sent, money already paid and data already deleted cannot be pulled back.

Tasks that are frequent, cheap when wrong and reversible are good candidates for automation. As soon as one answer is bad, change the pattern to AI prepares, a person decides: AI makes a draft, category or proposal; a person checks and presses the button. For decisions with significant effects on people, their legal rights also come into play; that is covered in the lesson on automated decisions and people's rights.

One more sign: if the rules are full of exceptions ("usually like this, except for long-standing clients, except in December, except when there is a letter from the board"), automation will often be wrong where it is least visible. Start with only the part whose rules are clear.

If a flow is automated anyway, place people at a few right points. A checkpoint at every step wears people out until they approve without reading. The most important checkpoint is right before an effect that cannot be pulled back: before an outside e-mail is sent, before a payment is approved, before data is deleted, before a decision about a person is recorded. Other useful points are an exceptions queue, where cases that do not fit the rules or that make the AI unsure go to a person, and sample checks, such as reading ten random results every week.

Loud failure gets noticed quickly, because there is an error message or someone complains. The dangerous kind is silent failure: the automation keeps running, but its results do not arrive. Its signs:

• Reports always say "success", but nobody checks the end result.
• The number processed suddenly drops to zero, or does not change for days.
• There are no complaints, because the people who should receive the result receive nothing.
• The output is exactly the same every day, though the data changes.

Check the end state: did the e-mail arrive in the recipient's inbox, did the figure in the target system change. The process report may well say success. Record every automated step in an audit log so you can trace what happened, and set an alert for days when nothing is processed.

All of this matters even more when what is automated is an AI agent, an AI that may use tools and decide its next step by itself. An agent can run dozens of steps in a few minutes, so one misunderstanding early on can multiply before anyone notices. The human-in-the-loop principle here means three concrete things: the agent stops and asks for approval before actions that cannot be undone, every step is logged so it can be traced, and the person approving reads what is about to happen before pressing approve. Approval given without reading is the same as having no checkpoint.