Where the Machine Stops: Setting Decision Rights for AI in Small Operations
Most small operations adopt AI in the same way: a tool gets added to one task, then another, and eventually nobody can say exactly which outputs go out the door without a second look. The problem is rarely the model itself. The problem is that the team never decided, in advance, where a person must stay in the loop. This article offers a way to make that decision deliberately. It does not assume any particular tool or vendor, and it does not promise any outcome. It gives you questions to ask, a structure for answering them, and a checklist you can apply to your own workflows this week.
Start With Decisions, Not Tools
Before you ask which AI tool to use, list the decisions your operation makes repeatedly. Examples include: what to publish, what to charge, which customer to contact, what to say in a refund reply, which supplier to pay, and which idea gets a week of attention. Many of these decisions are made by drafting something first. A tool can produce that draft, but the decision itself is a separate act.
Write each decision on its own line. Next to it, note three things: how often it happens, what it costs to get wrong, and how quickly a mistake would be noticed. A weekly newsletter draft that is wrong in a small way is different from a pricing change that quietly affects every customer for a month. Frequency and reversibility matter more than how impressive the output looks.
Sort Tasks Into Three Lanes
A workable structure uses three lanes. The first lane is assisted work: the AI produces material and a person edits and approves it before anything leaves the team. Drafting replies, summarizing meeting notes, and generating first-pass product descriptions usually belong here. The second lane is supervised automation: the system acts on its own within limits that a person defined, and a person reviews a log or sample on a schedule. Sorting incoming support tickets into categories is a typical example. The third lane is decisions that stay with humans, even when AI supplies the analysis. Hiring, pricing, legal wording, and anything involving money leaving the business belong here.
The lanes are not permanent. A task can move from assisted to supervised once you have enough evidence that its outputs are consistently usable. Move it only after you have looked at real outputs, not after a demo went well.
Write the Review Rule Down
For every task in the first two lanes, write a one-paragraph review rule. It should state who reviews the output, what they check, how long they have, and what happens when they reject it. Vague rules such as 'someone checks it' are where errors slip through, because each person assumes another person is the real reviewer.
A useful review rule names specific checks. For a customer reply, the reviewer might confirm that the order number is correct, that no promise was made that policy does not support, and that the tone fits the situation. For a summary of meeting notes, the reviewer might compare it against two facts they remember and mark any action item without an owner. Keep the list short enough that a person will actually run through it.
Questions to Ask Before Any Task Goes Unattended
Before you allow a task to run without per-item review, ask these questions and answer them with evidence rather than optimism. What does a bad output look like, concretely? Have you seen one, or are you imagining it? If it went out unnoticed, who would find out, and how? Can the action be undone, and what does undoing it cost in time, money, or trust? Is there a limit on how much the system can do in one run, such as a maximum number of messages or a dollar threshold that stops it? Who owns the task when the person who set it up is unavailable?
If you cannot answer the last question, the task is not ready for unattended operation. Ownership is the piece most often missing from small setups, and it matters more than the sophistication of the model.
A Practical Checklist and Comparison
Use this checklist when you map an AI-assisted workflow. First, is the decision written down with its frequency, cost of error, and detection speed? Second, is the task placed in a lane, with a reason? Third, does each task in the first two lanes have a named reviewer and a review rule? Fourth, have you looked at at least a sample of real outputs before choosing the lane? Fifth, is there a stated threshold or stop condition for automated tasks? Sixth, does someone own the task by name?
To compare two workflows, put them side by side on the same five attributes: frequency, reversibility, detection speed, reviewer, and stop condition. The workflow with rare, reversible, quickly detected outputs and a clear stop condition is a reasonable candidate for supervised automation. The one with frequent, irreversible, slowly detected outputs stays in the human lane, regardless of how good the drafts look. Revisit the comparison each quarter, because the answers change as your volume and tools change.