Where AI Should Not Decide: Drawing Approval Lines in Small Operations

Start With the Cost of Being Wrong

Every AI-assisted task produces an output, and every output carries some chance of being wrong. The useful question is not whether the output might be wrong, since the answer is always yes, but what happens if it is. A misworded internal summary can be corrected in a minute. A misquoted refund policy sent to a customer can create a dispute, and a misstated figure in a financial report can shape decisions for months.

Sort your recurring tasks into three rough bands. The first band contains tasks where errors are cheap and easily reversed, such as brainstorming headlines, reformatting notes, or sorting a list of ideas. The second band contains tasks where errors are visible to others or costly to fix, such as customer-facing messages, published content, or changes to shared documents. The third band contains tasks where errors can cause legal, financial, or reputational harm that is hard to undo, such as anything involving payments, contracts, personal data, or public claims about your work.

This sorting is a starting point, not a verdict. Your own band placements depend on your audience, your margins, and your tolerance for mistakes. The value comes from making the sorting explicit rather than leaving it to habit.

Draw the Line Before the Task Runs

Approval lines work best when they are written down before a task begins. Once an AI workflow is running smoothly, people tend to stop checking its output, not because checking became unnecessary but because checking became tedious. A written rule interrupts that drift. For each task you automate or assist, record three things: what the system may do without review, what requires a human to read before it goes out, and what the system must never do at all.

For example, a rule might say that the system may draft replies to routine questions, that a person must read every reply before it is sent, and that the system must never quote prices or promise delivery dates on its own. The specific rule matters less than the act of writing it. A rule you can point to is easier to enforce, and easier to revisit when something goes wrong.

A Checklist for Mapping Decision Rights

Use the following questions to map each workflow. Work through them in order and write the answers down. First, name the task in one plain sentence, so that anyone reading the list understands what the output is for. Second, identify who receives the output, whether that is you, a teammate, a customer, or the public. Third, state the worst plausible error and how long it would take to notice. Fourth, decide whether a person must approve the output before it leaves the workflow, and record who that person is. Fifth, note what information the reviewer needs in order to judge the output, such as the source material, the policy in force, or the previous version.

Sixth, decide what the system is forbidden from doing, even if it could technically do it. Seventh, set a date to review the rule. Workflows change, and a line that made sense for a small volume of tasks may be too loose or too strict once volume grows. Finally, record what evidence would make you move a task from one band to another. Moving a task toward more autonomy should require evidence, such as a track record of reviewed outputs with few corrections, not simply a feeling that the system is probably fine.

Keep Review Real, Not Ceremonial

A review step is only useful if the reviewer can actually say no. If a person is asked to approve forty outputs an hour with no context, the approval becomes a signature on something nobody read. This is one of the most common failures in small operations: the human is technically in the loop but practically absent. When you design a review step, make sure the reviewer has the source material, enough time to read the output, and clear permission to reject it without a justification fight.

It also helps to track what reviewers change. If nearly every output is approved untouched, either the system is performing very well or the review is not catching what it should. Sampling a fraction of approved outputs and checking them again is a simple way to tell which of those explanations is true. Keep the sampling notes in the same place as your approval rules so they can inform the next review date.

Questions to Ask Before You Hand Off a Decision

Before moving any decision from a person to an automated process, ask whether the decision depends on information the system can actually see. Many errors come from systems making confident choices based on incomplete records. Ask whether the decision requires judgment about a specific person or situation that the system cannot know. Ask whether a wrong answer would be noticed by the affected person and whether they would have a way to correct it. Ask whether you could explain the decision to someone affected by it in plain language. If the answer to that last question is no, the decision probably belongs with a human.

A useful habit is to write a one-paragraph note for every workflow that explains why its approval line sits where it does. Six months later, when you or a teammate wonders why a step still requires sign-off, that note will save time and prevent both unnecessary caution and dangerous shortcuts. Approval lines are not a sign of distrust in your tools. They are a record of the decisions you chose to keep for yourself, and why.