Operations Disguised as AI Problems: The Executive Field Guide

Why your AI initiative feels stuck

Put a room of executives together and ask what they want from AI. You hear the same list every time: automate the workflows, answer the customers, speed up engineering, surface the insights.

Now ask what is stopping them. The list changes character completely. Our data is all over the place.

Nobody owns this. We cannot tell if the output is any good. Everyone is too busy.

We are afraid of what people will paste into a chatbot.

Read that second list again, slowly.

Not one item on it is about artificial intelligence. It is data architecture, accountability, quality assurance, capacity planning, and security policy. Every one of those problems is older than the transformer.

AI did not create them. AI exposed them, because it is the first technology that touches every function at once and turns out work faster than your existing controls can absorb.

So here is the diagnosis in one line: AI adoption is rate-limited by operational maturity, not by model capability. The models are already better than most companies' ability to put them to work. That is good news, because operations is a thing you already know how to fix.

The Costume Test: is it an AI problem or an ops problem?

You do not need a consultant to sort your AI questions. You need one substitution. Take the question and ask: would this problem still exist if you replaced "AI" with "a very fast new employee"?

How do we know their work is good? That is quality assurance. Who manages them?

That is an operating model. What can they access? That is permissioning.

What if they leak data? That is security policy. How much do they cost per unit of output?

That is unit economics.

If the question survives the swap, it is an operations question, and your playbook is management, not machine learning. You have run that playbook before.

The questions that do not survive the swap are the new ones: which model families to bet on, how to stay portable across vendors, how to judge output that comes out different every time, at scale. Those deserve real technical attention. In our experience they are maybe one question in five.

Where to start when processes are the problem

Skip the enterprise-wide AI strategy deck. Start with one workflow that is measured, painful, and owned by someone who wants it fixed.

Pick a process with a clear before-state: hours spent, cost per unit, error rate, cycle time. Instrument it. Deploy the smallest AI intervention that could improve it.

Measure the after-state. Then publish the difference inside the company.

That single loop, run honestly, does more for adoption than any mandate from the top. It turns AI from a belief system into a line item, and people argue with beliefs but they copy line items.

Then run it again, and let the pattern spread by pull instead of push. The companies furthest ahead did not roll out AI. They stacked dozens of small, measured wins until the operating model reorganized around them.

The five ops debts AI will make you pay

Every company carries these five. AI just sends the bill sooner.

Data debt. Every silo is a wall your AI cannot see past. You do not need a two-year unification project.

You need a retrieval layer over the systems you already have.

Ownership debt. If nobody owns a process, nobody owns its automation, and unowned automations rot. Assign owners before you assign tools.

Measurement debt. If you cannot measure the quality of human output, you cannot evaluate machine output either. Your evals inherit from the QA culture you already have.

Process debt. Automate a broken process and you get a faster broken process. The oldest rule in operations survives the AI era untouched.

Policy debt. If your data access rules live in people's heads, AI will break them innocently and at scale. Write them down before the tools arrive, not after the incident.

Pay these five down in that order and the AI part gets easy, because by then it is only the AI part.

Operators First: what the companies getting paid by AI have in common

A small group of companies is making real money from AI, and when you look at how, it barely looks like an AI story.

The big group is not. Boston Consulting Group surveyed 1,000 senior executives and found 74 percent of companies had yet to show tangible value from AI. S&P Global found the share of companies abandoning most of their AI initiatives rose from 17 percent to 42 percent in a year.

The small group shares three traits. We call them Operators First.

They spend on people and process before software. BCG found that the leaders follow a rough rule: 10 percent of the effort goes into algorithms, 20 percent into technology and data, and 70 percent into people and processes. Most companies we meet have that ratio upside down.

They buy the tool and hope the process shows up.

They can say the problem in one sentence. RAND researchers interviewed 65 experienced data scientists and engineers about why AI projects fail. By some estimates more than 80 percent do, which RAND notes is twice the rate of technology projects without AI.

The most common cause they heard was not the model, the data, or the budget. It was leaders who misunderstood, or never clearly said, what problem they wanted solved. That is the Costume Test showing up in the research.

A problem you cannot state is not an AI problem yet.

They rebuild the work instead of bolting a tool on. McKinsey's global survey reports that only 37 percent of respondents say AI has contributed to their company's earnings, a share that barely moved in a year. Among the high performers, nearly three quarters have fundamentally redesigned workflows because of AI, up from 55 percent the year before.

Same tools, same models, different result. The difference is whether anybody redrew the process.

"Those are surveys of giant companies."

You may be thinking that numbers from thousand-person enterprises do not apply to a company your size. They apply more.

Look at why projects die. When Gartner predicted that at least 30 percent of generative AI projects would be dropped after the proof of concept, it listed four reasons: poor data quality, inadequate risk controls, escalating costs, and unclear business value.

Read that list the way we read the executives' list at the top of this article. Not one of the four is "the model was not smart enough." Data, controls, costs, and value are all things an operations lead already manages.

A big company has to get forty people to agree before it can fix any of them. You have to get three. That is the one real advantage a smaller company has in AI, and it only pays if you spend it on the process and not on a bigger subscription.

The old operations idea of finding the constraint still holds. Find the one step that limits the whole workflow and fix that step. If the constraint is ownership, our article on who owns AI is the next read.

What to read next, and why

The Root Causes of Failure for Artificial Intelligence Projects (research report): The most useful thing written on why AI projects fail, because the authors asked the people who built them.

Where's the Value in AI? (report): Read it for the 10-20-70 rule. Then check your own budget against it.

The State of AI (survey): Look for the gap between companies using AI and companies earning from it. The gap is the whole story.

Gartner's prediction on abandoned projects (press release): Short. The four reasons in the first paragraph are a ready-made checklist for your next pilot.

So the simple takeaway is this: the companies winning with AI did not find a better model. They fixed the work first, and then almost any model was good enough.