Should You Automate This With AI? A Triage Framework for Operators

The most expensive AI mistakes I see are not failed pilots. They are successful pilots aimed at the wrong process. A team automates something that works beautifully in the demo, ships it, and six months later discovers the thing they automated was rare, or high-stakes, or so entangled with human judgment that the automation created more review work than it removed. The tool did its job. The decision to point it there was the error.

What follows is a triage framework for deciding whether a given process deserves AI at all, and if so, in what form. It is deliberately conservative. In 2026 the technology can do more than most companies use, so the binding constraint is judgment, not capability.

Sort every process onto two axes

Before scoring anything, place the process on a simple grid. The vertical axis is volume and repetition: how often does this happen, and how similar is each instance? The horizontal axis is cost of being wrong: if the output is flawed and slips through, what is the damage?

• High volume, low cost of error. This is prime automation territory. Categorizing support tickets, drafting routine emails, summarizing meetings, extracting fields from invoices, tagging content. Errors are frequent enough to matter but cheap enough to catch.
• High volume, high cost of error. Augment, do not automate. Think loan pre-screening, medical intake, contract review. AI drafts or flags; a qualified human decides. The value is speed with a human backstop.
• Low volume, low cost of error. Usually not worth automating. The effort to build and maintain the automation exceeds what you save. Do it by hand or with a template.
• Low volume, high cost of error. Leave it to people. A board memo, a redundancy decision, a crisis response. These are rare and consequential, exactly the wrong profile for automation.

This grid alone kills half of the bad ideas. Most "let's use AI for this" proposals turn out to live in the two quadrants where you shouldn't.

The five questions that decide the survivors

For a process in the promising quadrants, run these five checks before committing budget.

1. Is the output checkable, and by whom?

AI is strongest where a human can verify the result quickly, and dangerous where verification is as hard as the original work. Drafting a customer reply is checkable in seconds. A financial forecast that looks plausible but is subtly wrong is not, unless you already have someone who could have built it themselves. If nobody on the team can tell good output from confident-but-wrong output, do not automate; you are just moving the error downstream.

2. How stable are the inputs and the rules?

Automation loves stability. A process where the format, the policy, and the edge cases change every quarter will keep breaking, and someone has to maintain it each time. If your refund policy is rewritten monthly, an AI refund assistant becomes a maintenance liability. Score stability honestly.

3. What does one error actually cost, including the tail?

Average cost is misleading. Ask about the worst plausible error, not the typical one. Ten thousand correctly tagged tickets and one wrongly auto-closed complaint from your largest account is not a good trade. If the tail risk is severe, keep a human in the loop even at high volume.

4. Is the bottleneck actually the task, or the decision around it?

Teams often want to automate the visible work when the real delay is a handoff, an approval, or missing data. Automating the drafting of a proposal does nothing if proposals sit in someone's inbox for a week awaiting sign-off. Map where time is genuinely lost before assuming AI is the fix. Sometimes the honest answer is a process change, not a model.

5. What is the fully loaded cost to build and keep it running?

Count the license, the integration work, the review time, and the ongoing maintenance. A rule of thumb I use: if the automation cannot save at least three to five times its annual all-in cost, it is not worth the organizational attention it will consume. Small savings are real, but they crowd out bigger opportunities and still demand governance.

A worked example

A logistics company asked me whether to automate customer status inquiries. High volume, thousands a week. Low cost per error, since a wrong ETA is annoying but recoverable. Checkable, because the true answer sits in their tracking system. Inputs stable. The bottleneck was genuinely the task, not an approval. Every signal pointed to automate, and a retrieval-connected assistant cut their response volume to agents by more than half.

The same company wanted to automate claims for lost shipments. High cost of error, emotionally charged customers, payouts involved, policy that shifted with carrier contracts. Same enthusiasm, opposite answer. We built an AI assistant that drafted the claim summary and flagged the likely resolution, then routed everything to a human. Faster, but never autonomous. Two years on, both decisions still look right.

The categories people get wrong

A few patterns recur. Creative work with a house style tempts teams to full automation, but brand voice is exactly where confident-but-off output slips through; augment instead. Anything legal, medical, or financial-advisory looks automatable because the text is formulaic, yet the cost of a wrong answer is exactly why it isn't. And rare high-value negotiations get proposed because they are expensive in staff time, but low volume plus high stakes is the worst quadrant on the grid.

Conversely, people underrate the dull middle: internal knowledge lookup, meeting notes, data cleanup, first-pass triage. These rarely make an exciting proposal. They are where mid-sized companies actually recover hours.

Decide, then revisit

A useful habit is to write the decision down in one line: the process, the quadrant, the verdict, and the number that would change your mind. Revisit it in six months. Volumes grow, error costs change, and a process that failed the test last year may pass it now. Triage is not a one-time gate. It is a discipline for spending your automation budget where it compounds, and, just as importantly, for saying no to the demos that dazzle but don't pay.