When AI Is the Wrong Answer

The operational problems that look like AI opportunities but aren’t

 

I have deployed AI in an operation and watched it work. Call analysis that rebuilt a sales process. Digital workflows that replaced back-office systems held together with paper and habit. That experience is exactly why I have become skeptical of most of what gets pitched as an AI opportunity.

In a portfolio company or any operating business, the sentence “we should use AI for this” almost always arrives before anyone has defined the problem. And the numbers around that pattern are not kind. MIT’s NANDA initiative found that 95 percent of enterprise generative AI deployments produced no measurable P&L impact. RAND put the failure rate for AI projects above 80 percent, roughly double the rate for other technology projects. The common thread in the post-mortems is not bad models. It is that someone reached for AI before asking whether the problem in front of them was an AI problem at all.

Here are the cases I have learned to recognize, the ones where AI is the expensive answer to a question that had a cheaper one.

The problem is a broken process, not a missing model

This is the most common one by a wide margin. AI gets pitched to automate a workflow that is broken, undocumented, or living entirely in one person’s head. Automating that does not fix it. It just produces the wrong output faster and with more confidence.

The move is boring and it works. Map the process first. Write down what actually happens, not what the org chart says happens. Half the time the fix is in that exercise, a step nobody owns, a handoff that loops back on itself, an approval that exists for a reason that retired in 2019. McKinsey’s research backs the sequence. Companies that see real financial return from AI are twice as likely to have redesigned the end-to-end workflow before choosing any technology. Fix the process, then ask what, if anything, AI still improves.

Figure 1. Most “automate this” requests are really “untangle this” requests. The process work is the project.

The data isn’t there, or you can’t trust it

AI output is capped by input quality. That rule did not go away with generative models. It got more expensive to ignore, because a modern system will give you a fluent, well-formatted, completely wrong answer and never flag its own uncertainty.

In lower mid-market businesses the data is usually thin, inconsistent, or scattered across a few people’s spreadsheets. Gartner attributes a large share of AI project failures to poor data quality or missing data outright. And the work to fix that is the actual project. Teams that succeed spend somewhere between half and two-thirds of their timeline and budget on data readiness, the extraction, the cleanup, the governance, before the model does anything interesting. That part is almost never in the pitch, which is how a six-week demo becomes an eighteen-month slog that quietly gets shelved.

Figure 2. The model is the small part. The data plumbing is where the time and money go. Illustrative.

The volume doesn’t justify the build

AI earns its return on scale and repetition. A task that runs thousands of times with a clean, learnable pattern is a good candidate. A task that happens twelve times a year, or carries forty edge cases and no real pattern, is not, no matter how annoying it is.

So run the math the vendor will not put in front of you. Build cost plus ongoing maintenance against the actual frequency and the real hours saved. Two variables decide it, how often the thing happens and how standardized it is. High on both, AI pays off. Weak on either, the honest answer is a trained coordinator with a good checklist, or a plain rules engine that does exactly what you tell it every single time.

Figure 3. Only one quadrant justifies the build. The other three have cheaper, more reliable answers. Illustrative.

The cost of being wrong is too high for a probabilistic system

AI is probabilistic. It is right most of the time, and “most of the time” is a perfectly good standard for a first-draft email or a rough summary. It is a dangerous standard for a payroll run, a compliance filing, or anything where a person’s safety or money is on the line.

The senior move is matching error tolerance to the tool. Where a wrong answer is cheap to catch and cheap to fix, let the machine run. Where a wrong answer is expensive, unsafe, or hard to reverse, a human belongs in the loop or a deterministic rule belongs in the path. This is not caution for its own sake. Regulators are writing it into law, with the EU AI Act requiring qualified human oversight for high-risk systems. Design the checkpoint on purpose. Do not discover you needed one after the filing goes out wrong.

What this looks like done right

None of this is an argument against AI. It is an argument for asking four questions before you spend a dollar. Is the process sound. Is the data real. Does the volume justify the build. Can we live with the system being wrong sometimes. Only what clears all four is a genuine AI opportunity.

The wins I have had came in that order, not around it. The process work and the data work came first. The tool that stuck was aimed at one real bottleneck, and it was boring. It did not demo well. It just moved the number. That is what a real AI opportunity tends to look like from the inside, far less exciting than the pitch and far more valuable.

The unglamorous answer

The market rewards saying yes to AI. Boards want to hear it, vendors are paid to sell it, and “we’re deploying AI” is an easier sentence than “we fixed the process and cleaned up the data.” The operator’s edge is knowing when the answer is no, or not yet, or fix the workflow first.

In a portfolio company that discipline is worth real money. The person who can tell a real AI opportunity from an expensive distraction protects more margin than the one who greenlights all of them and hopes. Knowing where the tool does not belong is not a lack of ambition. It is the judgment that makes the tool worth having.

References