Most of Your AI System Should Not Be AI

Most of Your AI System Should Not Be AI

The question worth asking before you build anything is not which model to use. It is how much of the system should call one at all. Get that ratio wrong in either direction and the project fails: too little AI and you have shipped ordinary software with an inflated price tag, too much and you have shipped something nobody can predict, test, or hand over. The systems that actually make it to production and stay there share an unglamorous trait. Most of them is not AI.

Read that list again. Cost, unclear value, and risk controls are architecture and governance problems, not intelligence problems. A smarter model does not make a system's cost predictable, does not make its value legible to the person who has to justify the budget, and does not make its failures auditable. Those three things come from how much of the system is deterministic, and deterministic is exactly what a model is not.

The Difference Between a Rule and a Judgment Call

Every step in a business process is one of two things. It is a rule, meaning the same input should reliably produce the same output, or it is a judgment call, meaning the correct output depends on context that cannot be fully specified in advance. The test is simple to state and usually clarifying to apply: if you would fire an employee for handling two identical cases differently, it is a rule. If you would expect them to handle two similar-looking cases differently because the details actually differ, it is a judgment call.

Rules belong in code. They run in microseconds, cost nothing per execution, never drift between two runs, and can be tested exhaustively because their behaviour is fully specified. Judgment calls are where a model earns its cost, because a model can weigh context a rule cannot enumerate. The mistake that produces Gartner's 40% is routing rules through a model anyway, either because it was faster to prototype that way or because "AI-powered" was the thing that needed to be in the pitch.

A Worked Example

Take invoice processing, a process almost every mid-market company runs and almost every vendor demos with a model doing all of it. Broken into its actual steps, most of it is not a judgment call at all. Reading the PDF and extracting line items is pattern matching against a known layout, a rule once the layout is known. Matching the invoice to a purchase order is a lookup. Flagging a duplicate is a lookup. Routing to the right approver by amount and department is a lookup against an org chart. Posting to the ledger once approved is a rule with zero ambiguity.

The genuine judgment calls are narrower: deciding whether an unusual line item is a legitimate exception or something that needs a human to look at it, and reading a vendor's free-text dispute email to work out what they are actually asking for. In a representative build, that is two or three model calls out of a process with a dozen distinct steps. The rest is code, and the code is what makes the two model calls trustworthy, because everything around them is fully specified and fully tested.

The Determinism Ratio Is a Cost Argument Three Times Over

Confining the model to genuine judgment points is not a purity position. It is a cost argument, a latency argument, and an auditability argument at once, which is why it survives contact with a finance team in a way "we used AI for everything" does not.

On cost: a rule executed in code has no per-run marginal cost worth measuring. A rule executed through a model call has a marginal cost on every single invocation, forever, and that cost scales with volume in a way a fixed engineering cost does not. On latency: code runs in microseconds; a model call is an API round trip, and a chain of them compounds. On auditability: code has a call stack you can read after the fact. A model's reasoning for a specific output is, at best, an approximation the model itself constructs afterward, which is a weak foundation for an answer you have to defend to a regulator or an auditor.

A recent architecture paper on what its authors call "compiled AI" makes the same case from the engineering side rather than the cost side: have the model generate the workflow logic once, during a compilation step, then run that logic deterministically with the model removed from the runtime path entirely, calling back into it only at the narrow points that genuinely need judgment. On function-calling tasks, the compiled version completed 96% of runs using zero execution-time model tokens, because the branching, retries, and tool selection were already resolved into ordinary code before the workflow ever ran.

Why This Is Also the Buying Argument

Every AI-first vendor has a structural reason not to tell you this. Their pricing, their demo, and their pitch all improve the more of the system runs through the model, because the model is the product. A vendor whose revenue scales with model calls has no incentive to route your invoice matching through a lookup table instead. That misalignment is worth naming plainly, because it is the reason so many production systems are more AI than they need to be, and it is exactly the failure mode Gartner is describing when it points to escalating cost as a top reason projects get cancelled.

We map this boundary explicitly, on your actual process, as one of the artifacts an embedded operator engagement produces: an AI Boundary Map that states which steps are rules, which are judgment calls, and what each model call is costing you per run. The map is only honest if it is built from watching the real process rather than the one described in a workshop, which is the subject of our companion piece on why the documented process is rarely the real one. It is also the piece that determines whether you are buying a staffing arrangement or an actual architecture decision, which we cover in how to buy AI delivery that actually ships.

Sources & References