Where AI does not belong in your business

The most useful question in an AI project isn't "what can we automate?" It's "what should we leave alone?"

That sounds like caution for its own sake. It isn't. It's the difference between the projects that pay for themselves and the ones that end up in the statistics - and the statistics are brutal. MIT researchers put the failure rate of generative-AI pilots at 95%. Most of those pilots didn't fail because the model was bad. They failed because nobody decided where the model belonged before turning it on.

The "put AI on everything" era

The first wave of business AI had a simple strategy: give everything to the model and let it figure things out. Feed it the emails, the documents, the tickets. Let everyone in the company use it for whatever they want.

The results are becoming well-worn stories. Companies that gave the whole organization access to a model budget meant to last a year and burned through it in a quarter - everyone experimenting, nobody accountable, spend climbing fast. The sad part isn't the bill. It's that the bill usually bought nothing measurable. No process ran faster, no error rate dropped, no customer noticed. Spending on intelligence without deciding where it goes converts budget into activity, not results.

The correction now underway is selectivity: being deliberate about which steps of which workflows get a model, and what surrounds it.

Triage, step by step

Take a workflow - say it has ten steps. Before any tooling gets discussed, each step gets three questions.

1. Is the behaviour fully known? If a step is a rule - when the amount exceeds X, route to approval; when the customer is in segment Y, use template Z - it belongs in ordinary code. Not because AI couldn't do it, but because code does it perfectly, instantly, for effectively nothing, and behaves the same way on run ten thousand as on run one. Putting an if/then decision into a prompt is renting a slower, less reliable if/then.

2. What does a mistake cost? A mis-tagged internal note costs nothing and is fixed in seconds - automate freely. A wrong amount on an outgoing invoice, an email to the wrong customer, a contract clause - those are expensive or impossible to take back. Steps like that keep a human approval gate regardless of how good the model looks in testing.

3. Is it worth anything? Volume times time saved, against the cost of building and running it. A step that takes someone four minutes twice a month is not a project. It's fine for work to stay manual.

Run a real workflow through this and a typical pattern appears: of ten steps, six or seven are rules and belong in deterministic code and API calls. Two or three genuinely require judgment - reading an ambiguous inquiry and deciding what it's about, pulling structured data out of documents that follow no format, drafting something a human will finish. Those are the steps where a model earns its place. The step everyone was most excited about often turns out to be a rule wearing a trench coat.

Sometimes the answer is the whole workflow

The same triage applies one level up. There are three good reasons to leave an entire workflow alone:

• The risk outruns the accuracy. If the honest projection is 80% accuracy on something customer-facing, that's one customer in five getting a wrong answer. Not worth it - not until the design changes.
• The return is too small. Low volume, low pain. The map should say so plainly instead of inflating it into a use case.
• It already works. A cron job that has synced two systems reliably for four years does not need to become an agent. Working boring software is a finished result, not a modernization backlog.

"Not here, and here's why" is a deliverable. When I map a company's workflows, the leave-alone list gets the same care as the automate list - it's the half of the analysis that saves the money.

You can't triage a process you don't know

One dependency: all of this assumes you know what the ten steps actually are. Most process descriptions are the clean version - the real one, with its exceptions and undocumented judgment calls, only surfaces when you go looking for it. Triage the clean version and you'll put the model in the wrong places with great confidence.

So the order matters: first the real process, then the judgment about where intelligence belongs, and only then the build. If you want a second pair of eyes on where AI would actually pay off in your operation - and where it wouldn't - that's exactly the kind of work I do.