Not Every Problem Needs Artificial Intelligence

The question that matters isn’t whether a model could do the task. It’s whether you would notice when it got it wrong.

A pattern we see often: a team wants a model to decide which invoices need manager approval. The policy is simple. Anything over $5,000, or from a vendor added in the last 30 days, gets escalated.

That is a four-line function. It runs in microseconds, returns the same answer every time, and you can write a test for every edge of it. A language model can approximate the same policy. It will be right most of the time, wrong in ways nobody predicted, and it will bill you per invoice, indefinitely.

Nobody proposes this out of carelessness. “AI” has quietly become the default name for “have the computer handle it,” so the first question in the room becomes which model to use. The better question comes earlier, and it’s a technical one: what kind of problem is this, and what happens when the answer is wrong?

The constraint isn’t capability. It’s verifiability.

Modern models can do an astonishing range of tasks, so “can it do this?” is rarely the limiting question. The limiting question is whether you can tell, cheaply and before it costs anything, that an answer is wrong.

Conventional software mostly fails loudly: a validation error, an exception, a total that doesn’t reconcile with the ledger. A language model fails fluently. The wrong answer arrives in the same confident prose as the right one. That single property changes how the whole system has to be engineered.

It also explains where AI fits comfortably and where it doesn’t. It fits when checking is much cheaper than doing: a drafted reply a person skims before sending, an extracted invoice total shown beside the line of the PDF it came from, generated code that has to pass a test suite. It fits badly when checking costs as much as doing, such as a model’s reading of a contract clause that someone would have to re-derive from scratch before trusting it.

That leads to a rule we apply before writing any code: if you can’t write the test, you’re not ready for the model. In practice that means a few hundred real examples with known-correct answers, rerun on every prompt or model change. Without that set, “it seems to work” is the only evidence anyone has, and it stops being true the first time something changes.

Match the tool to the shape of the problem

Most business problems fall into a handful of shapes, and only some of them call for a language model.

1. Explicit rules over structured inputs (Approvals, pricing, eligibility)
Reach for: Plain code or a rules engine.
Why: Exact, testable, and explainable line by line.

2. Lookups, filters, totals, and reports (Over your own data)
Reach for: SQL and a search index.
Why: A GROUP BY is no place for probabilistic behavior.

3. Predicting an outcome from structured history (Churn, fraud, demand)
Reach for: Classical machine learning.
Why: Often outperforms neural approaches on tabular data, is cheap to run, and is straightforward to evaluate.

4. Sorting high volumes of text into fixed categories
Reach for: A small trained classifier.
Why: Faster, cheaper, and more consistent than prompting a large model on every request.

5. Turning messy text or documents into structured fields
Reach for: A language model, with validation.
Why: Handles format variation that rules can’t; code checks the result.

6. Drafting, summarizing, and answering questions over documents
Reach for: A language model, with human review.
Why: Checking is cheaper than writing from scratch.

The fourth point hides a useful pattern. A large model is an excellent way to label a few thousand examples quickly. A small classifier trained on those labels is then faster, cheaper, and more consistent in production, and you can measure it properly. The large model is how you build the system. It doesn’t have to be the thing running inside it.
One more case belongs on this map: decisions someone may have to justify, such as a declined application or a denied claim. A rule can show exactly why it fired. A model can produce an explanation, but that explanation is another generated output, not a record of how the answer was reached. Where accountability matters, the decision should live in logic you can audit, with a model, if any, assisting a person.

Put the model at the edge, not in the middle

Where a model does belong, the most reliable architecture confines it to the part of the problem that needs it. Rules are written for clean inputs, and real inputs aren’t clean. So the model sits at the boundary and turns mess into structure, and ordinary code takes over from there.

1. The model reads the messy input (an email, a scanned form, a free-text note) and proposes values for a fixed set of fields.

2. Code validates the proposal against a strict schema: types, ranges, required fields, and cross-checks against records you already hold, such as whether that vendor ID exists.

3. Deterministic rules make the decision, using only validated fields.

4. Anything that fails validation goes to a person, with the source text shown beside the proposed values.

5. Every step is logged: the input, the model and prompt version, the output, and the outcome, so errors can be traced and the test set grows from real cases.

The model proposes; the code decides. This turns silent failures into loud ones. A hallucinated vendor ID doesn’t quietly flow into a payment run. It fails the lookup and lands in a review queue. It also keeps the probabilistic part small, which keeps the whole system testable.

The arithmetic most proposals skip

“95% accurate” sounds like a result. At 10,000 items a month it is 500 errors, and the numbers that matter are what each one costs and whether anyone would find it. Errors also compound. If a workflow chains five model-dependent steps, each right 95% of the time, and the errors are independent, the whole chain succeeds about 77% of the time. At ten steps it is about 60%. This is a large part of why autonomous multi-step workflows are much harder to make dependable than single, well-bounded tasks, and why every step you can make deterministic or verifiable raises the reliability of everything around it.

Human review is the usual answer, and it isn’t free. When a reviewer sees correct output 95% of the time, attention drifts and checking turns into approving. Researchers call this automation bias. A review step that works is designed to work: it shows the source beside the answer, asks for a decision instead of a glance, and measures how often reviewers actually override the model. A review step that exists only on the process diagram provides the appearance of control and little else.

What it costs after launch

A prototype hides costs that production exposes:

• Behavior changes underneath you. Providers update and retire models, and a prompt is code without a compiler: a small edit can shift behavior in places nobody tested. Pin model versions and rerun the test set on every change.

• Output varies. Even with randomness turned down, hosted models aren’t guaranteed to return identical output for identical input, which matters wherever you need repeatability.

• Latency and unit cost scale with volume. A rule evaluates in microseconds and costs effectively nothing. A model call takes a noticeable fraction of a second or more and is billed per use, which is trivial at hundreds of requests and a line item at millions.

• Data crosses a boundary. Depending on the architecture, customer records may be sent to a third party for processing. That should be a decision someone made on purpose, with the contract and retention terms read.

Five questions before you build

1. Can you write the rule? If yes, write it. It will be cheaper, faster, and exact.

2. Can you write the test? You need labeled examples and a definition of “correct” before you can say whether a model is good enough.

3. How would you catch an error? Name the mechanism: a validation check, a comparison against the source, a reviewer who can see the evidence.

4. What does an error that gets through cost? Per instance, and per month at your volume.

5. What does the dumb baseline score? Try a keyword search, a regular expression, or a spreadsheet formula first. If it gets you 90%, the model has to justify the remaining 10%, and sometimes it can. At least then you know what you’re paying for.

Start with the problem

At PraneoTech, we build with language models when they’re the right tool, and we’ll say so plainly when they aren’t. The process doesn’t change: define what “correct” means, decide how errors will be caught, use the simplest component that clears the bar, and put the model only where nothing simpler can. Sometimes that’s a model at the edge of a rules engine. Sometimes it’s a database query and a well-designed form.

The best AI engineering often looks like less AI: a model doing one narrow job well, wrapped in code that can tell when it hasn’t.

In the next article in this series, we’ll look at what changes once you’ve decided AI belongs: why your AI is only as good as the information it can access.