When AI Is the Wrong Answer to an Operations Problem

We turn down this work more often than we take it

A COO describes a process that is visibly failing. Invoices sitting for weeks. Quotes going out wrong. A queue that three people spend their mornings sorting by hand. Then comes the sentence that started the meeting: we think AI can fix this.

Sometimes it can. More often the process is broken in a way a model cannot reach, and putting one on top of it buys an expensive, confident version of the same failure. Saying so costs us the engagement. We say it anyway, because the alternative is a client who spends nine months finding out and correctly concludes we were the ones who sold it.

The failure numbers make this less contrarian than it sounds. S&P Global Market Intelligence surveyed over a thousand enterprises and found 42 percent abandoned most of their AI initiatives in 2025, up from 17 percent the year before, with the average organization scrapping 46 percent of its proofs of concept before production. MIT's Project NANDA study put 95 percent of generative AI deployments at zero measurable P&L impact. Those are not model quality numbers. Models got dramatically better across the same period. Those are problem-selection numbers.

Here are the four shapes where the answer is no.

Shape one: the process has one right answer

If a task has a single correct output and the rule that produces it can be written down, a model is a downgrade. You are adding latency, per-call cost, and a nonzero rate of confident wrong answers to a problem that a deterministic rule solves exactly, every time, for free, with an audit trail.

This sounds obvious and it is the single most common thing we talk clients out of. The reason it keeps happening is that nobody in the room has actually written the rule down. The process feels complicated because it lives in three systems and one person's head, and complicated gets read as needs judgment. It usually does not. It needs someone to sit with it for a week and discover that ninety percent of the volume follows four paths.

The tell: ask the person who does the work to describe how they decide. If they answer in if-then sentences, you have a rules problem wearing an AI costume. If they answer with "it depends, let me show you a few," you may have a real one.

Approvals, payroll, inventory reconciliation, tax logic, anything where an auditor will eventually ask why a specific decision was made. Those want determinism. That is not conservatism about AI, it is matching the tool to a requirement the tool cannot meet.

Shape two: the data does not exist yet

Gartner predicted that through 2026, organizations would abandon 60 percent of AI projects unsupported by AI-ready data, on the back of a survey where 63 percent of data management leaders either lacked the right practices or did not know whether they had them. In our experience that prediction was optimistic about how early the abandonment happens. Most of these projects do not fail at the model. They stall in month three, when everyone finally agrees on which system holds the real customer record.

The version of this that catches good operators: the data exists, but it only exists as an outcome, not as a decision. You have five years of closed tickets. What you do not have is what the rep considered and rejected, which is the actual thing you wanted the model to learn. The archive looks like training data and is a record of results with the reasoning deleted.

You cannot fix that with a better vendor. You fix it by instrumenting the process now and having something worth training on in a year, which is a real plan, just not the one that was on the agenda. We wrote about what that groundwork costs in what an AI pilot actually costs, including the parts nobody quotes, because it is almost never in the quote.

Shape three: the bottleneck is a person, a policy, or a handoff

This is the one that stings.

Map a slow process end to end and you often find the work itself takes forty minutes. The elapsed time is eleven days. The gap is queueing: waiting on an approval from someone who checks that inbox on Tuesdays, waiting for a handoff between two teams with different definitions of done, waiting because a policy written in 2019 requires two signatures on anything over a threshold nobody has adjusted for inflation.

Automate the forty minutes and you have an eleven day process. Congratulations on the fastest step.

We keep coming back to this because it is where the honest money is. Removing a signature requirement is free. Changing a queue policy is free. Merging two intake forms costs a week of someone's time. None of it demos well, no vendor is incentivized to find it, and it routinely delivers more cycle time reduction than the model would have. The uncomfortable follow-on is that these fixes are political rather than technical, and a software purchase is often the more comfortable way to avoid an argument about whose approval is unnecessary.

A model dropped on a broken process just produces the wrong answer faster. We have started calling those projects artificial urgency.

Shape four: nobody has said what success is

73 percent of failed AI projects had no agreed definition of success before they started. Read that as a scoping failure, not a measurement failure. When a project starts without a number, everyone in the room gets to keep a private version of what winning means. The CFO is thinking headcount. The COO is thinking cycle time. The vendor is thinking usage. Twelve months later all three are right and the project is dead.

The gate is not complicated. Before anything gets built, one sentence: this process currently takes X and costs Y, and this is worth doing if it takes A and costs B. If the room cannot agree on X, you do not have a measurement problem yet, you have a process nobody actually understands, which is shape three with better lighting.

What we say instead of no

The honest recommendation usually has three parts, and it is smaller than what was asked for.

Fix the queue first. Whatever is politically hardest and technically free, do that before you buy anything, because it changes the baseline you would have measured the AI against and sometimes changes the decision entirely.

Then use a model only where the work genuinely resists a rule. Reading messy unstructured input, drafting a first pass a human will edit, sorting things into buckets where the boundary is fuzzy. Deterministic steps for the routing and the delivery, judgment only where judgment is required. That is a component inside a workflow, not a replacement for one, and it prices very differently.

Then hold the vendor to the narrow version. The questions that separate a real product from a wrapper are in our piece on how to evaluate an AI vendor, and the discipline of moving from a pilot to something that survives contact with production is in going beyond the AI pilot.

None of this is an argument against AI. We spend most of our time on engagements where it is the right call, and the ones that work tend to look boring: narrow scope, clean input, a number agreed in advance, a human holding the exception path. The pattern in the failures is not that companies were insufficiently ambitious. It is that the problem was never the shape the tool fits.

Where this stops being an article

What writing can do is tell you which questions decide the outcome. Whether your specific bottleneck is the forty minutes or the eleven days, whether your archive holds decisions or only results, whether the rule your team follows can actually be written down. Those are answerable, but not from here. They take a week in your systems and some direct conversations with the people who run the process.

If you are holding a proposal and you cannot tell which shape you are in, that is exactly the conversation to have before you sign. Talk to us. We will tell you if the answer is to buy nothing.