Guide · Foundational
When AI Should Not Be the Answer
Sophisticated systems combine rules, reasoning and people. They do not ask one method to do everything.
Choose a method for each decision, and define how the methods hand work to one another.
When rules are the right tool
Use a deterministic system when there is a known rule and a correct outcome that can be tested. Calculations, format checks, permission checks and many workflow triggers belong here. If an order total is the sum of agreed line values and tax rules, asking a language model to improvise the arithmetic adds uncertainty without adding useful interpretation.
Deterministic does not mean infallible. A wrong rule, stale input or missing exception produces a repeatable wrong result. The work is to establish the rule, govern its changes and test the boundaries. Correctness depends on the specification and evidence, not simply on the absence of AI.
When interpretation matters
AI can be useful when inputs are unstructured, language varies or several plausible interpretations need examining. It may help summarise interview notes, identify candidate themes in documents or propose questions about a contradictory account. These are reasoning tasks rather than simple transfers of known values.
The output should enter the workflow with an appropriate state. A proposed classification is not a verified fact. A convincing summary may omit a crucial exception. Define what evidence supports acceptance, what uncertainty requires review and what happens when the model cannot produce a usable result. Do not let fluent wording become the approval mechanism.
When people must decide
Human expertise matters where context, relationships, trade-offs, strategy and accountability shape the decision. A specialist may need to decide whether an unusual specification is safe, whether a customer commitment should change or whether a proposed intervention is acceptable to the people who will operate it.
Human review must be meaningful. A person who receives hundreds of unexplained outputs with no time to examine them is not an effective control. Give the reviewer the source, the proposed action, relevant uncertainty and the power to reject or pause. Specify who owns the decision after approval rather than hiding responsibility behind “the system”.
Combine methods at the boundary
Imagine an illustrative incoming purchase request. AI extracts candidate requirements from an email. Deterministic checks validate required fields, identifiers and permitted values. A human resolves an ambiguous specification. An integration then creates a draft order under the correct permissions. A runtime check confirms that the destination record exists with the approved values.
No single method owns the whole chain. The extraction needs interpretation; validation needs explicit rules; ambiguity needs expertise; creation needs authorisation; completion needs evidence. Make each handoff observable. If extraction fails, the request should remain usable by a person rather than disappearing because an optional reasoning step was unavailable.
Choose by failure consequences
Ask not only what each method can do, but what happens when it is wrong. A suggestion for a workshop question can tolerate more uncertainty than a payment instruction. A classification used for browsing may need different controls from one used to deny a service. Scope autonomy by consequence and recoverability, not just model capability.
This is not an argument against AI. It is an argument for giving it a job that benefits from its strengths while containing its limitations. Before introducing it, remove unnecessary work, clarify authority and establish observable outcomes. Then evaluate the combined system with representative cases, including ambiguous inputs and failures. The best design may use substantial AI, very little AI or none in a particular step.
Questions worth asking
- Is there a correct answer that can be specified as a rule?
- What ambiguity requires interpretation?
- Who remains accountable for the action and its consequences?
Foundational explanation and illustrative examples. This article does not report findings from client engagements or establish a pattern in your organisation.