What not to automate
The best AI or automation advice is sometimes to leave a working process alone.
Start from the cost of a wrong answer
Most automation conversations start with capability: what could this do? That is the wrong end of the problem. The better question is what a wrong answer costs, because that is what decides whether automation is an improvement or a new liability.
A step where a mistake is visible, cheap, and quickly corrected is a good candidate. A step where a mistake is quiet, expensive, or first noticed by a customer is not — however automatable it looks.
Automate the middle, keep the edges
The durable pattern is to automate the middle of a workflow and keep people at the boundaries. Classification, drafting, routing, summarizing, and retrieval are usually safe to accelerate. Intake and final approval usually are not.
That is not caution for its own sake. Judgment, accountability, and relationships live at the edges of a process, and those are the things automation handles worst.
Test alongside, not instead
The safest way to find out is to run the automation next to the existing process rather than in place of it, and compare. If it agrees with your people, you have evidence. If it does not, you have learned something more valuable than a deployment.
Leaving it alone is a valid outcome
Sometimes the honest recommendation is that a workflow should be left alone, or fixed before it is automated. Automating a broken process only produces broken outcomes faster — and adds a system to maintain on top of the original problem.
Have a decision like this in front of you?