If you can't check it, don't automate it

Trust comes from being able to verify, not from hoping it worked. If you cannot check the output, you should not automate the task. Full stop.

This sounds obvious until you watch how people actually adopt automation. The thrill of a job running on its own is strong. You set it up, it works the first few times, and you stop looking. That is the dangerous moment. The automation has not earned your trust. You have just stopped paying attention, which is a very different thing. Trust without a way to verify is just hope wearing a hard hat.

Here is the trap. Automation removes the friction that used to make you notice problems. When a person did the job, mistakes surfaced because a human was in the loop, frowning at something odd. Automate it and that frown disappears. The errors do not. They just pile up silently until something big enough breaks to get your attention, by which point the pile is large and the cause is buried weeks back.

I worked with a firm that automated their invoice reminders. Lovely idea, freed up real time. Months later they discovered it had been chasing a major client for an invoice that was already paid, every week, politely and relentlessly, because the “paid” status lived in a system the automation could not see. The client said nothing for a while out of British awkwardness, then mentioned it was getting silly. The automation worked perfectly. It just could not be checked, so a small data gap turned into a relationship problem.

The sharper way to think about it is to design the check before you design the automation. Ask, when this runs, how will I know it did the right thing. If the answer is a clear, cheap signal, a summary, a log, a flag when something looks off, then automate away. If the only way to know is to manually redo the work the automation just did, you have not saved anything. You have added a thing to babysit.

This is also the honest line between what to automate now and what to leave alone. The boring, checkable jobs go first. Moving data, sending standard messages, formatting documents, anything where right and wrong are easy to see at a glance. The fuzzy, judgement-heavy jobs wait, not because the tool cannot attempt them, but because you cannot easily tell when it has got them wrong, and an error you cannot catch is an error you will eventually ship.

There is a useful instinct here that good operators already have. They do not trust a process they cannot see into. They want a dashboard, a sample, a spot check, a number that should always sit in a range. Apply that same instinct to AI and automation. Visibility first, then trust, then take your hands off.

The practical takeaway. For anything you are about to automate, write down the single check that tells you it is working, and make sure that check is faster than doing the job by hand. If you cannot find one, the task is not ready, no matter how tempting the time saving looks. Automation you cannot verify is not a time saving. It is a delayed problem you have agreed not to look at.