Use AI where ambiguity exists
Before writing any code, decide which parts of a process should be deterministic, configurable, probabilistic or human-controlled.
00 // BriefingThe most expensive AI mistake is a category error
Most failed AI projects do not fail because the model was weak. They fail because a model was asked to do a job that should never have been probabilistic: holding the state of a case, enforcing a regulation, approving a payment. The opposite mistake is just as common: hand-coding brittle rules for work that is genuinely ambiguous, such as reading a scanned form or sorting free-text complaints.
The fix is a decision you make before any code is written. Take each step of the process and ask what kind of decision it is.
Use AI where ambiguity exists. Use deterministic software where correctness, state and compliance matter.
01Four kinds of decision
Every step in a business process falls into one of four kinds. Naming them makes the architecture almost obvious.
- Deterministic. The answer must be the same every time and provably correct: calculating a premium, moving a case to its next state, checking a date against a limit. This is code, and it should stay code.
- Configurable. The logic is deterministic, but the business changes it often: routing rules, eligibility thresholds, approval limits. These belong in versioned configuration such as decision tables, owned by the people who change them.
- Probabilistic. The input is ambiguous and a best guess is useful: reading a document, classifying an email, summarising a long case history, matching a candidate to a role. This is where models belong.
- Human-controlled. The outcome carries judgement, accountability or risk that the organisation wants a person to own: an underwriting exception, a hiring decision, a refund above a limit.
A single feature usually contains all four. An insurance application, for example, is read by a model, routed by configurable rules, priced and recorded by deterministic code, and approved by a person when the model is unsure.
If you cannot say which of the four kinds a step is, you do not understand that step well enough to automate it yet.
02A worked example: one insurance application
Here is the same sorting applied to a single term life application, step by step. The point is not the insurance details; it is how quickly the architecture falls out once every step has a kind.
| Step | Kind | Why |
|---|---|---|
| Read the proposal form, KYC bundle and medical report | Probabilistic | Scans, handwriting and free text vary; a good first read saves hours of keying. |
| Check KYC status, age limits and required documents | Deterministic | Must be exact, repeatable and explainable to an auditor. |
| Price the plan: base premium, riders and tax | Deterministic | Regulated, and must be reproducible to the last rupee. |
| Route the case: straight through, review or underwriter | Configurable | The business changes routing often; it belongs in a versioned decision table. |
| Resolve fields the model was unsure about | Human-controlled | A person owns the judgement, and sees only the doubtful field. |
| Approve a medical disclosure | Human-controlled | Risk and accountability sit with an underwriter. |
| Record what happened and why | Deterministic | An append-only record, so the decision can be replayed later. |
Notice how little of the process is actually a model. One step out of seven is probabilistic, yet that one step is what removes most of the manual work. Everything around it is what makes it safe to use.
03Where models earn their place
- Extraction: pulling structured fields out of documents, emails and forms.
- Classification and triage: deciding what kind of request something is and where it should go next.
- Summarising and drafting: turning long histories into short briefs, or drafting a reply that a person will check.
- Reasoning over messy context: comparing a claim against policy wording, or spotting what is missing from an application.
- Exceptions: the long tail of cases that rules never quite cover.
What these have in common is that a good-enough answer, checked where it matters, is better than no answer, and the cost of an occasional error is bounded and visible.
04Where they do not
- State: what stage a case is in, who owns it and what happened before. Models do not hold state reliably; databases and workflow engines do.
- Approvals and permissions: who may do what. These must be explicit and auditable, never inferred from a prompt.
- Calculations and compliance checks: if a regulator could ask how a number was produced, it should come from code or configuration you can show.
- Anything that must be replayed: if you need to explain a decision months later, the decision itself must be deterministic, even when a model supplied one of its inputs.
A model’s output can be an input to a decision. It should rarely be the decision itself. When it is, put a person in the loop and record what they saw.
05The human gate
Between probabilistic output and anything that ships sits a gate. Designing it well is most of the work.
- Route by confidence. Confident results pass straight through and uncertain ones go to a person. The threshold is a business decision, tuned against real cases.
- Show only what needs judgement. The doubtful field, the evidence the model used and the options, not the whole case from scratch.
- Make the review fast. A reviewer who has to hunt for context will end up rubber-stamping.
- Record the outcome. What the model said, what the person decided and why. That record becomes your best evaluation data.
In the insurance case on this site, document AI reads the proposal, a versioned rule routes the case, and an underwriter reviews only the field the model scored below 0.85. Nobody re-keys the whole application, and nobody trusts a guess.
06The sorting checklist
Run this on the next feature before anyone opens an editor.