Where AI Should Stop: Drawing Decision Rights for Small Operations
Most small operations do not fail because they adopted AI too slowly. They fail because nobody decided, in advance, which decisions the software is allowed to make and which ones still belong to a person. When a drafted email goes out unread, or a pricing suggestion quietly becomes the price, the problem is rarely the model. The problem is that the boundary was never drawn. This article offers a way to draw it before something goes wrong, using questions any solo builder or small team can answer in an afternoon.
Start With the Decision, Not the Tool
Teams often begin an AI conversation by naming a tool: a writing assistant, a scheduling bot, a reporting dashboard. A more useful starting point is the decision a task produces. Every workflow ends somewhere. An email gets sent, a refund gets issued, a product description goes live, a lead gets routed to a particular person. Each of those endpoints is a decision, and decisions have different consequences.
Write down the five or six recurring decisions in your operation. For each one, note who currently makes it, how long it takes, and what happens if it is wrong. You will find that some decisions are cheap to reverse, such as a draft social caption that nobody has published yet. Others are expensive, such as a customer-facing commitment about delivery dates. The reversibility and cost of error are the two variables that matter most when you decide how much autonomy a system should have.
A Three-Tier Model for Decision Rights
A simple model helps. Sort every recurring decision into one of three tiers. Tier one covers work the system may complete and finish without review, typically low-stakes, easily corrected, and fully visible afterward. Formatting a file, tagging an inbound message, or generating a first-pass summary usually belongs here. Tier two covers work the system may prepare but a person must approve before anything leaves the building. Drafts of outbound messages, proposed schedules, and suggested edits to live content fit this tier. Tier three covers decisions that stay with people entirely, where the system may inform but not recommend action. Anything touching money, legal terms, personnel, or a relationship that depends on trust usually sits here.
The value of the model is less in the categories themselves than in the act of assigning each task to one. Ambiguity is where operations drift. A task nobody classified will eventually be handled by whichever tool or person happened to be nearby.
Questions to Ask Before You Grant Autonomy
Before moving any task into tier one, ask a short series of questions. Could a wrong output be noticed within a day? Could it be undone without a customer or partner ever seeing the mistake? Does the task have a clear right answer, or does it require judgment about context that the system cannot see? What inputs does the task depend on, and how would you know if those inputs had changed or gone stale? If the answers are uncertain, the task belongs in tier two until you have evidence.
Also ask what the system is actually able to see. Many AI-assisted workflows operate on a slice of the picture: a single ticket, a spreadsheet export, a message thread. A decision that looks routine from inside that slice may conflict with something happening elsewhere. Note explicitly what information each step has access to, and treat the gaps as a reason for review rather than an invitation to guess.
A Practical Checklist for Your Next Review
Use this checklist when you set up or revisit an AI-assisted workflow. First, list every decision the workflow produces and name the person accountable for each one. Second, assign each decision to tier one, two, or three, and write one sentence explaining why. Third, identify the inputs each step relies on and note how you would detect a bad or missing input. Fourth, define what a human reviewer should look for at each tier-two checkpoint, so approval is a real check rather than a rubber stamp. Fifth, decide how errors get reported and who reviews the pattern of errors over time, not just individual mistakes. Sixth, schedule a recurring date to revisit the tiers, because tasks that were risky last quarter may have become routine, and new tasks will arrive without anyone classifying them.
The checklist is deliberately modest. It does not require special software or a dedicated team. It requires a written record and the discipline to update it when the operation changes. Many small operations find that the act of writing decision rights down reveals duplicated work, forgotten owners, and steps that exist only because someone once made a mistake there. Those discoveries are often worth more than the automation itself.
Keeping the Boundary Honest Over Time
Decision rights decay. A tier-two task gets approved so consistently that the reviewer stops reading carefully, and the boundary quietly becomes tier one in practice without anyone choosing it. To counter this, periodically sample the approved outputs and check whether the review step is still catching anything. If a reviewer has approved hundreds of drafts without a single edit, either the drafts have become excellent or the review has become ceremonial. Either way, you need to know which.
Finally, treat the boundary as a living record of what your operation has learned. Each time a decision goes wrong, ask whether it was misclassified, whether the inputs were inadequate, or whether the reviewer lacked the context to catch it. Those answers tell you where to move a line, and in which direction. Good AI operations are rarely the ones with the most automation. They are the ones where everyone involved can say, clearly, what the system does, what it does not do, and who is responsible when the two get confused.