Most leadership teams I speak with have a list of AI ideas longer than their engineering roadmap. Some came from the board, some from a vendor demo, some from an enthusiastic analyst who automated part of their own job over a weekend. The list is rarely the problem. The problem is that every idea on it looks equally promising from a distance.
A useful filter separates the use cases that will reduce cost or risk within a quarter from the ones that will add a new system to maintain, a new failure mode to monitor and a new reason for staff to distrust the tools they are given.
Start with the work, then the model
Before anyone discusses models or vendors, map the work itself. For each candidate process, write down four things:
- Volume. How many times a week does this task happen?
- Variance. How different is one instance from the next?
- Cost of a mistake. What happens if the output is wrong and nobody notices for a week?
- Who checks it today. Is there a person whose judgment currently catches errors?
High-volume, low-variance work with a cheap, visible failure is where automation earns its keep: document intake, reconciliation matching, ticket triage, first drafts of routine reports. Low-volume, high-variance work with an expensive, invisible failure is where it tends to go wrong: credit exceptions, complaint handling, anything that touches a regulator or a customer’s money without a person in the loop.
The hidden cost line
Automation projects are usually approved on the savings side of the ledger. The cost side gets less attention, and it is where the surprises live:
- Exception handling. Every automated process produces cases it cannot handle. Someone has to own those, and they are by definition the hardest cases.
- Monitoring. Model output drifts as inputs change. Someone needs to look at quality every week, with a clear threshold for switching the automation off.
- Skills erosion. When a task is automated, the people who used to do it stop practicing it. If the system fails during a busy period, the team may no longer remember how to run the process by hand.
- Trust. If staff see the tool make a confident mistake early on, they will quietly double-check everything it does, and the savings disappear.
None of these are reasons to avoid automation. They are line items that belong in the business case.
Design the human checkpoint first
The strongest implementations I have seen treat the person reviewing the output as a core part of the design. They decide, up front:
- which outputs are reviewed every time, which are sampled, and which go straight through;
- what the reviewer sees, so they can judge quickly and well;
- how a reviewer’s correction feeds back into the process.
When the checkpoint is designed deliberately, staff see the tool as something that removes the tedious part of their job. When it is bolted on afterwards, they see it as something they have to supervise on top of their real work.
Five questions before production
Before any automation goes live, I ask the sponsoring leader to answer these in writing:
- What exactly will be measured to show this worked, and what is the baseline today?
- Who owns exceptions, and how much of their week will that take?
- At what error rate do we switch it off, and who makes that call?
- How will the people affected learn about it, and have they tested it on real cases?
- If the vendor or model changed tomorrow, how hard would it be to replace?
If those answers are clear, the project is ready. If they are vague, the project needs more design work before it needs more engineering.
Automation done well gives a growing company capacity it could not hire fast enough to create. The companies that get there tend to choose fewer use cases, design them carefully, and bring their people into the work from the first week.