When AI automation actually pays off

Almost everyone is using AI. Almost no one can show it on the bottom line.

Here is the honest starting point. McKinsey's most recent State of AI work finds that AI adoption is now close to universal, with roughly 88 percent of organizations using AI in at least one business function. And yet only about 39 percent report any measurable EBIT impact from generative AI, and most of those say the effect is under 5 percent. So the technology is everywhere, and the money is mostly not. The factor most associated with actually moving the numbers is not picking a better model. It is redesigning the workflow around the tool instead of bolting AI onto a process you never fixed. That single finding should shape how you think about every automation you are tempted to build.

What AI automation is genuinely good at

The tasks where AI pays off share a profile. They are high volume, repetitive, and tolerant of a human review step, and a wrong answer gets caught cheaply before it does damage. Document and data extraction, intake triage, classification, first-draft generation, and summarization all fit this shape. You are running the same kind of work thousands of times, the model produces a draft or a structured guess, and a person confirms or corrects it. The volume is what makes the build worth paying for, and the review step is what keeps the occasional bad output from reaching a customer or your books. If a task does not have both of those properties, be skeptical.

What it is bad at

The poor-fit profile is the mirror image. Low-volume work almost never justifies the build, because the cost of designing, integrating, and maintaining the automation never gets spread across enough runs to come out ahead. Zero-error-tolerance work is a bad fit because these systems do not produce zero errors, so anything where a single wrong answer is expensive and hard to catch needs a different approach. Judgment-heavy work that depends on context a model does not have tends to disappoint. And fast-changing rules are a quiet killer, because the prompt and examples you tuned for this quarter's policy quietly become wrong when the policy changes and nobody re-tests.

The real cost stack, and why it is not the API bill

Owners usually worry about per-token cost, and that is almost always the wrong thing to worry about. Anthropic's own documentation gives a useful anchor. Running 10,000 support-ticket conversations of roughly 3,700 tokens each through Claude Haiku 4.5 costs about 37 dollars total, well under a cent per ticket for the raw model call. List prices as of 2026 sit in that same range. Claude Haiku 4.5 is about 1 dollar per million input tokens and 5 dollars per million output. Cheaper small models from other vendors run well under a dollar per million input tokens. Inference is rarely the dominant cost of an automation.

The real money goes to the build, the integration into your existing systems, the human-review loop, and ongoing monitoring and maintenance. Those are mostly people costs and they recur. There are real levers on the inference side if you want them. Output tokens cost about five times input across the lineup, so designing for short structured outputs instead of chatty prose matters. Batch processing runs about 50 percent cheaper when the work is not time-sensitive. And prompt-cache reads cost roughly a tenth of the base input price, which helps when you reuse a large fixed instruction block across many calls. But none of these will rescue an automation whose build never amortizes or whose review loop eats the time it was supposed to save.

Why a human stays in the loop

Hallucination, meaning confidently stated facts that are not supported by the source, is real and measurable and does not reach zero. Vectara maintains a public leaderboard that scores how often models introduce unsupported facts when summarizing a document they were handed. On the harder long-document version, the best models land around 3 percent, while several strong recent models exceed roughly 10 percent. That is the grounded case, where the model has the source in front of it. So the practical posture is simple. Treat AI output as a fast first draft that a person confirms, especially for anything customer-facing or money-moving. The review step is not a sign the automation failed. It is the design that makes a good-fit automation safe to ship.

The failure modes worth naming

A few come up again and again. Hallucination, covered above. Drift, which comes in more than one form. Data drift, where the inputs change over time. And concept drift, where the right answer changes because a rule or policy changed underneath you. Drift is why an automation needs ongoing monitoring and periodic re-evaluation, not a one-time launch. Then there are edge cases the pilot never saw, which show up the moment you scale past the clean examples you tested on. And the big one, automating a bad process. If the underlying workflow is broken, AI does not fix it. It just makes the same mistakes faster and at higher volume.

How to measure ROI without lying to yourself

The honest calculation is time saved valued at the fully-loaded cost of the person doing the work, minus everything it actually costs to run. That means subtracting the build, the ongoing API and monitoring and maintenance, and the cost of the human-review loop, which is the line people most often forget. If reviewers spend nearly as long checking outputs as they would have spent doing the task, the automation does not pay, no matter how impressive the demo looked. Avoid vanity metrics. Messages handled and percent automated tell you nothing about whether you came out ahead. Net hours saved against net dollars spent is the only number that matters.

When the honest answer is not yet

Sometimes the senior call is to wait. If the volume is too low for the build to amortize, wait. If errors are expensive and hard to catch, wait or keep a person fully in charge. If the underlying process is undefined, fix the process first, because automating confusion only scales confusion. And if the rules change faster than you can re-test the system, you will spend more on maintenance than you save. None of this is anti-AI. It is the discipline that separates the automations that pay from the ones that quietly bleed.

A quick word on the scary statistics

You will see two numbers thrown around to argue AI is a failure. Both are weaker than they sound. The widely repeated line that 85 percent of AI projects fail misreads a 2018 Gartner forecast, which predicted that through 2022 about 85 percent of AI projects would deliver erroneous outcomes from bias in the data, the algorithms, or the teams running them. That was a prediction about flawed outputs, not abandoned projects. The viral figure that 95 percent of generative-AI pilots fail comes from a 2025 MIT initiative report that is not peer-reviewed, leans on a relatively small set of interviews, and uses a narrow definition of success. Use both as cautionary color about overpromising. Do not treat either as a hard fact, in your own decisions or anyone else's pitch.

Sources

External sources are provided for verification. NavoTech is not affiliated with and does not endorse the organizations cited.

Written by the team at NavoTech Digital Solutions. Have a project or counter-example? Get in touch.