Skip to main content

The decision boundary

Which business decisions should AI never make?

5 MINUTE READ

By Joseph de Silva, Founder, Visual State Studio

Joseph holds degrees in computer engineering, cyber security and graphic design, and did commercial photography and videography for over seven years before founding the agency.

Published 20 August 2026. Updated 21 August 2026.

OWNER QUESTION

What can the system handle on its own, and what has to come back to me?

BEST FOR

Owners and operations leads putting AI anywhere near customers, prices or promises.

Introduction

You are not choosing between all of it and none of it. Every workflow we build has a line through the middle. On one side is work the system prepares and carries. On the other side is a decision that stops with a person, by name, before it reaches a customer.

Most of the worry about AI in a business comes from not knowing where that line sits. So we write it down before anything is built, and you approve it.

What is the difference between preparing a decision and making one?

Preparing a decision means gathering what the decision needs. The job details, the site photos, the customer history, the pricing that applies, the information nobody has asked for yet. The system can do all of that at any hour, on every enquiry, without anybody remembering to.

Making the decision commits the business. The price that goes out, the date promised and the scope agreed all bind you to something. That is a different act, and it belongs to a person who can be named.

Most arguments about what AI should be allowed to do settle once you separate those two, because the question stops being how capable the system is and becomes who answers for what leaves the building.

Which decisions should always stop with a named person?

This is the boundary we write into every build. It does not move because a workflow has been running well.

  1. Price. The system drafts from your approved rates. You set the final number.
  2. Scope. The system collects what the job involves. You decide what is in and what is out.
  3. Capacity. The system can offer times you have already released. You decide what the business takes on.
  4. Commitments. Nothing the system sends creates a promise you have not approved.
  5. Complaints. A complaint goes to a person, with the whole conversation attached.
  6. Sensitive situations. Money trouble, safety, health, bereavement, a dispute: a person replies.
  7. Professional judgement. Anything needing a licence, a qualification or somebody standing on site stops with the qualified person.

Every one of those changes money, risk or a promise to a customer. None of them get better by being answered faster.

What can the system do without waiting for you?

Everything either side of those decisions, which is most of the volume.

It answers a new enquiry with something useful while you are on a job. It asks for the suburb, the access, the photos and the timing. It drafts the quote from your rates and puts it in front of you with the context attached. It sends what you approved, chases on the schedule you set, and stops when the customer replies. It asks for the review when the job is finished. It updates the record so nobody has to remember.

None of that is a judgement call. All of it currently waits for you to be free.

Which customer situations are too sensitive for an automatic reply?

Some messages are not routine even when they look routine. A customer chasing a refund. Somebody describing a hazard. A complaint dressed up politely. A person telling you they cannot pay this month. A message that mentions an injury, a death or a legal threat.

We build recognition for those situations into the workflow, and the recognition is deliberately cautious. If a message might be one of them, it stops and goes to a person. A person handling a routine message by mistake costs a few minutes. A system handling a sensitive one costs the relationship.

The same rule covers anything the system has not seen before. If a case is unusual, it stops and waits for somebody rather than working out a plausible answer.

What should you see before you approve something?

An approval is only real if the person approving can check it. A queue of drafts with no context trains people to click yes.

Before you approve, you should have the customer and their history, what was asked for, what the system prepared, where each price or claim came from, and anything it could not confirm, flagged rather than filled in.

That last one matters most. A system that quietly fills a gap is more dangerous than one that stops and admits it does not know.

When can a decision move to a more automatic path?

Boundaries can move, but only on evidence.

If a category of approval has run for a while and you have not changed a single one, that is worth looking at. Start with the ones you did change, and why. If the changes were all the same kind, the rule was wrong, and the rule gets fixed rather than the boundary. If there were genuinely no changes across a decent run of real cases, that category can move to a lighter check, with sampling instead of full review.

We record the change like any other launch: what moved, who approved it, what evidence supported it, and what would move it back. Our implementation standards cover the acceptance record we use for that.

How do you keep an off switch and a manual path?

Two things should be true of anything running in your business. You can turn it off without ringing anybody. Your team can do the job by hand while it is off.

Australian government guidance for businesses adopting AI says much the same. The business stays responsible for what its tools do, there should be a clear way to override or stop one, and critical work should have a path that continues if the system is unavailable or retired.

We build both, and we test both before launch rather than discovering them during an incident.

If a provider cannot show you the off switch on your own system, you do not yet have one.

FAQs

Does keeping decisions with people slow everything down?

No, because the volume is not in the decisions. Most of what happens around a customer is preparation, chasing and record keeping, and none of that waits for you. The decisions that do reach you arrive together, with the context attached, instead of interrupting you one at a time all day.

Who is accountable if the system gets something wrong?

You are, which is why the boundary is written before the build. Each workflow has a named owner inside your business, an approved set of rules, a list of decisions it may never make, and a record of what it did. If something goes wrong you can see what happened and who was meant to catch it.

Can we start stricter and loosen it later?

That is the sensible order. Start with more approvals than you think you need. Watch what you actually change. Loosen the categories where you changed nothing, and leave the rest alone.

SOURCES

Would rather show us than read about it?

Book an Operations Review and we will follow one real example through your business.

30 MINUTES. NO PAYMENT TAKEN.