Answer
When does AI add unnecessary complexity?
When it sits on a step that was already solved, when it replaces a form, and when it avoids deciding something.
When it sits on a step a rule already handled, when it interprets input a form could have structured, and when it substitutes for a decision the business has never made. All three are visible in advance.
The first case is the solved step. Something already works — a rule, a lookup, a validation, a template — and a model is placed on it because the surrounding project is an AI project. The result costs money per execution, introduces variance where there was none, and removes the ability to say why an item was handled a particular way. Nothing was gained and three things were lost.
The second is interpretation that structure would have avoided. A business receives enquiries as free text and builds a workflow to extract what the customer wants, when the enquiry form could have asked. Extraction from prose is a genuine capability and it is being used to compensate for a design choice made upstream. Where the input is under your control, changing the input is cheaper and more reliable than interpreting it, and the effort belongs there.
The third is the most consequential: using a model to avoid a decision. Which enquiries are worth pursuing, what counts as urgent, when to escalate a complaint, which supplier to prefer. Asked to make these, a model will, and the answer will be plausible and consistent enough that nobody notices a policy was set by inference. The business then has a rule it never agreed to, cannot state, and cannot change deliberately.
There is a fourth that is smaller and very common: conversational interfaces on things that were fine as forms. Asking a model to collect five fields through dialogue is slower for the user, more expensive, and fails in more ways than five inputs on a page. This is worth mentioning because it is the most frequently built demonstration and the least frequently useful outcome.
The test that identifies all four in advance is to ask what the model is deciding, and then to ask whether anyone could state that decision as a rule. If they could, it should be a rule. If they could not because the business has never decided, that is a decision to make rather than a task to delegate. If they could not because the input is genuinely unstructured language, that is the legitimate case and the one worth building.
There is a real cost to getting this wrong beyond the money. Every model step in a workflow is a place that can vary, a place that needs checking, and a place that will need investigating when something goes wrong. Complexity is not paid once at build time; it is paid on every occasion the system is examined, which is precisely when the business is under pressure.
A model asked to infer what the business never decided will produce a decision, and nobody will know that is what happened.
Siddharth Sharma, Context Theory
Related questions
Is it wrong to use AI on something a rule could do, if it is faster to build?
It is a legitimate trade for a prototype and a poor one for something that runs. Building the rule takes longer once; the model step costs on every execution, varies, and cannot be audited. Where the model version is a way to find out what the rule should be, that is a good use of it, provided the rule follows.
How do you tell a genuine language task from a structure problem?
Ask whether you control the input. Language arriving from customers, suppliers or the public is genuinely unstructured and interpretation is the right response. Language arriving through your own form, your own template or your own process is a structure you chose, and the cheaper fix is upstream.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Odds of qualifying a lead — replying within the first hour vs after it | 7× | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Placing a model on a step already handled deterministically adds per-execution cost and output variance while removing the ability to explain why an item was handled a particular way, with no offsetting gain. | Comparing cost, variance and auditability for a step before and after a model was introduced into it. |
| Software | Extraction from free text used on input the business controls compensates for an upstream design choice, so changing the form is cheaper and more reliable than interpreting what the form failed to collect. | Checking whether the unstructured input being interpreted arrives through a channel the business designed. |
| Constraint | A model asked to make a decision the business has never made will produce one plausibly and consistently, leaving the business with an operating policy it did not agree, cannot state and cannot change deliberately. | Asking whether anyone in the business can state the rule the workflow is applying to a contested category of item. |
| Buying behaviour | Complexity from a model step is paid on every occasion the system is examined rather than once at build time, which places the cost at the moment the business is investigating a problem. | Comparing the time to diagnose a failure in a rule-based step against a model-based one. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one