What deserves AI, and what doesn't

Everyone asks the same question: where should we use AI. It is the wrong question, because it assumes the answer is somewhere, and mostly the answer is nowhere yet. The useful question is the inverse. Where does AI not belong, so that the few places it does belong stand out.

I went looking for a clean decision framework for this and could not find one. The consulting versions are a value-versus-feasibility box that never tells you the thing that actually matters, whether a plain rule would do the job better than a model. So here is the one I assembled, from the operator tests in the pieces I have written, the routing pattern the field keeps landing on, and a few things that are just true if you think them through. It is seven gates. Run them cheapest first, and every time a use case fails one, the gate hands you the cheaper move.

Most work does not deserve AI

Start from the default, because the default is where most of the value already lives. A model is the most expensive, least predictable, hardest-to-verify way to get a step done. That is not a knock on models; it is a description of what they are for, which is the small set of steps where nothing cheaper works. Anthropic's own guidance for building with their models makes half the case: find the simplest solution possible, and add complexity only when it demonstrably improves the outcome, moving from a single model call up to a workflow and then an agent. The other half is the rung Anthropic starts above. Below the simplest model call sits a plain deterministic rule, and a rule beats a model whenever it applies: it is cheaper, faster, and certain. You climb the whole ladder, rule to model call to workflow to agent, only when the rung you are on visibly fails.

So the burden of proof sits on the model, not on the status quo. A use case does not deserve AI because AI is available and impressive. It deserves AI only after it survives a filter designed to reject it. The rest of this is that filter.

Put simply: The model is the expensive option of last resort, not the default. Make every candidate earn its way up from a rule, and assume the answer is no until the gates say otherwise.

First: is it worth doing at all?

Three gates decide whether the work is worth automating by any means, before AI even enters.

The first is value, and the trap here is measuring it gross. An initiative has to move one of exactly three numbers, revenue up, risk down, or cost down, net of what the AI costs to build and run. That last clause is where most AI budgets die. Cheap intelligence lowers the cost of every project, which lifts a whole band of low-value work across the worth-doing line for the first time. It is real positive return, and it is still the lowest-value work you have.

The second gate is the constraint. Even a genuinely valuable step is not worth automating if it is not your bottleneck, because speeding up a non-constraint just fills the backlog downstream faster. The third is volume. A judgment that happens twice a year does not want a system built around it, however juicy it looks; you do it by hand and move on. Automation earns its keep on the workflows that are both high-stakes and high-frequency.

Put simply: Before anything technical, three questions: does it move revenue, risk, or cost after you subtract its own cost; is it actually your bottleneck; and does it happen often enough to be worth a system. Two noes out of three and you are building a monument to a rounding error.

Then: what should do the work?

Now, and only now, the routing question. It resolves into three tiers, and the discipline is to default to the cheapest tier that clears the bar and move up only when forced.

The base is deterministic software: rules, formulas, API calls, anything with one right answer. It is nearly free, nearly certain, and it is most of any real workflow. The middle tier, the model, earns only the genuinely non-deterministic steps, the ones that need judgment or pattern-matching a rule cannot express. Running a model on a step costs real money per call and, more importantly, buys you a probabilistic answer where you might have had a certain one. The tip is the human, reserved for the steps you should not hand to either. The instinct to route a whole workflow to a model is the expensive mistake; the craft is carving out the two or three steps that actually need one and leaving the rest as boring, reliable code.

Put simply: Rule first, model only when a rule provably cannot do it, human for the rest. The model is the middle of the stack, not the whole stack, and most of the work should never reach it.

Last: is it safe to deploy?

A step can be valuable, non-deterministic, and still not deployable, because AI has a failure mode ordinary software does not. Three gates cover it.

Readiness comes first: is the data and context ready for this specific question. Readiness is the ceiling on the whole thing, and it is not general; the same model scores ten percent or ninety percent on the same task depending on whether the meaning underneath it has been written down. If the data is not ready, the move is to fix readiness, not to ship the model on top of rubble and hope.

Then verifiability, which is the gate people skip and regret. A wrong answer from a model looks exactly like a right one; there is no stack trace, no exception, just a confident sentence that happens to be false. If you cannot tell when it is wrong, with an eval or a set of golden answers, you cannot deploy it, you can only hope in production. Last is reversibility. The higher the cost of a wrong action and the harder it is to undo, the more a human belongs on the trigger. The pattern that works is the agent drafts and a person commits, so the machine does the intake and the reasoning and a human owns the irreversible step.

Put simply: Deployable means three things: the data is ready for this exact question, you can detect a wrong answer before it ships, and a human owns anything you cannot undo. Miss any one and you are not deploying, you are gambling at machine speed.

The gates, in order

Put together, it is seven gates, run cheapest first, and the reason to run them in order is that each no is cheaper than the next. You would rather kill a use case at the value gate than discover its data is not ready after three months of building.

Among the use cases that clear all seven, sequence them the way an acquirer would: by the size of the number they move against how ready they are, and then break ties toward the ones that deposit into something you own. An automation that also builds a data asset or deepens a customer relationship compounds; a one-off that saves some hours does not. The whole filter reduces to one sentence you can say in a meeting: AI deserves a step only when it moves a number you named, on a bottleneck that is actually binding, that happens often enough to automate, doing work a rule cannot, on data that is ready, in a way you can check, with a human on anything you cannot undo.

None of this is about being cautious for its own sake. It is the same logic as every profit pool I have traced: the value is not in the expensive, impressive input everyone can buy, it is in the judgment about where that input actually pays. The gates are how you find the few places it does.

Put simply: Seven gates, cheapest first, each no cheaper than the next, and a one-sentence test you can run out loud. Then sequence the survivors by impact over readiness, and prefer the ones that compound. That is the whole framework.