Which Decisions Should AI Make in Your Business?

Most conversations about AI in a business start with the wrong question. "Can AI do this?" is almost always answerable with yes, because a modern model can produce a plausible attempt at nearly anything. The question that decides whether the project succeeds is different: should AI make this decision, and if so, with how much supervision?

Here is the working rule we apply when scoping AI systems for clients: if a decision has a right answer every time, it belongs in code. If it needs interpretation, it is a candidate for AI. If someone must be accountable for it, a person stays in the loop. Most production failures we see trace back to one of those three lines being drawn in the wrong place.

Why "can AI do this?" is the wrong question

A capable model will attempt anything you ask. It will classify an enquiry, draft a response, decide whether a discount is within policy, and it will do all of these with equal confidence. What it will not do is tell you which of those tasks it should never have been given.

The result is a familiar pattern. A team builds an AI workflow, it performs well in testing, and weeks later someone finds decisions that were quietly wrong: not dramatically, not visibly, just wrong in the way that only turns up when someone audits the output. The system did not break. It was asked to do something that should never have been delegated to a probabilistic system in the first place.

The first line: rules with a right answer belong in code

Some decisions are deterministic. Is this order above the approval threshold? Is this contact in the exclusion list? Does this date fall inside the notice period? These have exactly one correct answer every time, and ordinary software gets them right every time, for a fraction of a penny, in a millisecond.

Handing a fixed rule to an AI model converts a certainty into a probability. The model will apply your £10,000 approval threshold correctly most of the time. "Most of the time" is a catastrophic downgrade from "every time" for a rule whose whole point is that it is a rule. And because the model phrases its output confidently either way, the failures do not announce themselves.

The engineering answer is boring and correct: keep the threshold check in code, and let the AI do the part code cannot do. In a quoting workflow, that means software checks the discount limit, and the model drafts the explanation to the customer. Each component does the work it is actually good at.

The second line: interpretation is where AI earns its keep

The decisions worth delegating to AI are the ones that need reading, judgement of tone, or synthesis across messy inputs. Which of these 200 enquiries is a genuine sales lead? What is this customer actually complaining about, underneath the politeness? Which clauses in this supplier contract differ from our standard terms?

These tasks have no lookup table. Before AI, they consumed skilled people's hours; the honest alternative was often that nobody did them at all. This is where the return on an AI system is real, and it is why AI agents are typically built around interpretive work connected to the systems that hold the facts, rather than around rule enforcement.

One caution from delivery experience: keep the toolset tight. An agent given every system connection "just in case" chooses between overlapping options less reliably than one given the three connections the job needs. Scoping what the AI can touch is part of deciding what it should decide.

The third line: accountability decides the level of supervision

Between "code decides" and "AI decides" sits the question of how much human oversight the AI's decisions need. The useful test is not how often the model is right. It is what one wrong decision costs, and whether you can take it back.

• Reversible and cheap to get wrong: let the AI act, and review samples after the fact. An internal draft, a suggested categorisation, a first-pass summary.
• Reversible but visible: AI acts, a person approves before it leaves the building. Customer-facing messages sit here for most businesses.
• Hard to reverse, or someone is accountable for it: the AI prepares, a person decides. Pricing commitments, contractual language, anything a regulator or a customer would ask a named person to answer for.

Notice what is absent from that list: decision volume. Routing every AI output to a human reviewer regardless of stakes feels safe but produces the opposite, because a reviewer approving 400 low-stakes items a day stops reading them, and the one item that mattered goes through with the rest. Review effort should concentrate where mistakes are expensive, which is a governance design choice. Our guide to AI governance for UK businesses covers how to write that down so it survives contact with a busy quarter.

A worked example: the sales enquiry pipeline

Take a workflow we build often: inbound enquiries arriving into a CRM. Applying the three lines splits it cleanly.

Code decides: deduplication against existing contacts, routing by territory, whether a required field is present. Fixed rules, right answer every time.

AI decides: what the enquiry is actually about, how urgent it reads, which service line it maps to, a drafted first response in the company's voice. Interpretation, all of it.

A person decides: whether the drafted response to the £200,000 prospect actually goes out, and anything involving a price. The AI has done most of the work; the accountable last step stays human.

The failure mode is building this as one undifferentiated "AI handles enquiries" system. It will work in the demo. The threshold that gets misapplied, the duplicate that gets created, the confident response to the prospect that needed a director's eye: those arrive later, in production, where they cost real money.

How to run this decision for your own workflows

For each step of a workflow you are considering automating, ask four questions in order:

1. Does this step have a single correct answer every time? If yes, it is software, not AI.
2. Does it require interpreting language, context or intent? If yes, it is an AI candidate.
3. What does one wrong answer cost, and can it be undone? That sets the supervision level, not the vendor's confidence.
4. Who answers for this decision if it is challenged? If the answer is a named person, that person stays in the loop.

Written down for a real workflow, this takes an afternoon, and it is the highest-value afternoon in the project, because every architectural choice that follows (which model, which integrations, what the build costs) hangs off where these lines sit. It is the first exercise in our own AI implementation scoping work, and the step most often skipped in the projects we get asked to rescue. Where this sits in the wider journey from first experiment to production system is mapped in our AI transformation ladder; where the lines should sit for your specific workflows is exactly what a diagnostic is for.

Frequently asked questions

Should AI ever apply fixed business rules, like discount limits?

No. A fixed rule has a right answer every time, and code applies it correctly every time at almost no cost. An AI model applies it correctly most of the time, and fails silently when it does not. Keep rules in code and give the AI the interpretive work around them.

Which decisions should always stay with a person?

Decisions that are hard to reverse, carry regulatory or contractual weight, or that a named person is accountable for: pricing commitments, legal language, dismissals, anything you would not want to explain to a customer as "the system decided". AI can prepare these decisions; it should not make them.

How do we decide how much autonomy to give an AI system?

Set it by the cost and reversibility of a wrong action, not by how accurate the model looks in testing. Cheap, reversible actions can run unattended with sampled review. Expensive or irreversible ones need a person approving before anything happens. Accuracy determines how often the safety net is used, not whether you need one.

What happens if we get the split wrong?

Usually nothing, at first, which is the problem. Misdelegated decisions fail quietly and surface in an audit, a complaint or a bill. The fix is cheap early (move the boundary, add a gate) and expensive late. This is why we scope the decision split before writing any code.

John Kelleher is a Claude Certified Architect (Foundations and Professional) and leads SpotDev, a Claude Registered Partner and OpenAI Select Partner.