Where AI Actually Creates Value in Operations (and Where It Doesn't)

Most AI initiatives inside operating businesses don’t fail because the model is bad. They fail because the project started from “we should use AI for something” instead of “this specific workflow is expensive, slow, or error-prone, and here’s why.” That ordering problem is the single biggest predictor of whether an AI initiative ships something people use or ends up as a pilot nobody remembers in six months.

Start with the workflow, not the model

A useful AI opportunity has three properties before a single line of code gets written:

A repeatable task with a real cost. Someone is doing the same judgment call, lookup, or classification dozens or hundreds of times a week, and you can point to the hours or the errors it costs.
Data that already exists. The information needed to make the decision is sitting in a system somewhere — a CRM, a ticketing tool, a shared drive of PDFs — even if it’s messy. If the data doesn’t exist yet, the project is a data project first and an AI project second.
A tolerance for being right most of the time, not all of the time. Drafting a first-pass response, flagging anomalies for a human to review, or summarizing a document are good fits. Anything where a wrong answer is expensive and unreviewed — financial approvals, medical guidance, anything customer-facing without a human checkpoint — needs a very different bar of confidence before it should run unsupervised.

If a proposed initiative is missing one of these, it’s not disqualified — it just means the real first project is building the data pipeline, or adding a review step, or narrowing the scope until it fits.

The pattern that actually works

The AI projects that hold up in production tend to follow the same shape: find the point in an existing workflow where a person is doing something mechanical — reading, sorting, matching, summarizing, drafting a first pass — and put a model there, with a human still making the final call until the error rate earns more autonomy. That’s less exciting than “we built an AI agent,” but it’s the version that survives contact with real data, real edge cases, and a real audit six months later.

Internal copilots for support and operations teams tend to work well because the stakes of an imperfect answer are low and immediately correctable. Fully autonomous customer-facing agents tend to work poorly on the first attempt because the stakes are high and mistakes are visible. The difference isn’t the sophistication of the model — it’s how much of the workflow around the model was actually designed, not assumed.

Where it doesn’t work

A few patterns reliably burn budget without producing anything durable:

Retrofitting AI onto a process nobody has mapped. If you can’t draw the current workflow on a whiteboard in ten minutes, you don’t yet know what to automate.
Treating a proof of concept as a finished product. A demo that works on ten curated examples and a system that works on the next ten thousand real, messy inputs are different projects, not two stages of the same one.
Skipping the “what happens when it’s wrong” conversation. Every AI system will produce a wrong answer eventually. The projects that hold up are the ones where someone decided, in advance, what happens next — a fallback, a review queue, a confidence threshold — instead of discovering it in production.

The practical takeaway

Before scoping an AI initiative, it’s worth spending more time than feels natural just describing the current workflow, the cost of the status quo, and what “good enough” looks like for the first version. That discovery work isn’t a delay before the real project starts — for AI specifically, it usually is the project. The build is often the fastest part; figuring out where the model should sit, what data it needs, and what the failure mode looks like is where the actual judgment gets applied.