What AI automation should — and shouldn't — touch

The most common mistake in AI automation projects isn't a bad model — it's a badly drawn boundary. Teams either automate too little, leaving humans doing pattern-matching work a model handles fine, or automate too much, letting a model make decisions that need accountability a model can't provide.

The useful question isn't 'can AI do this?' Increasingly, the answer is yes for almost anything. The question is: if the model gets this wrong, who notices, and what does it cost? A model that mis-tags a support ticket costs a few minutes of a human's time to fix. A model that approves a refund, denies an application, or sends a message to a customer without review carries a different kind of cost.

In practice, this means designing automation around confidence and consequence, not just capability. Routine, low-stakes, high-volume tasks — categorizing inbound requests, drafting first-pass responses, searching internal documentation — are strong automation candidates. Anything with real consequence for being wrong needs a human in the loop, even if the model is right the overwhelming majority of the time.

We also treat 'automated' and 'invisible' as different things. Even when a workflow is fully automated, the system should make it easy to see what the model decided and why, so a human can catch the exception when it inevitably comes up. Automation without visibility just moves the failure further from where anyone will notice it.

Done well, this isn't about replacing judgment — it's about being deliberate over where judgment is actually needed, and freeing people to spend their attention there instead of on the ninety percent of requests that follow a pattern.