Read, draft, act: deciding what AI can do without asking.
A practical way to discuss permissions before a useful assistant becomes an unpredictable operator.
“Human in the loop” sounds reassuring. It does not tell the team which human, at what point, or what they are supposed to review. Those decisions need to be designed into the work.
Separate access from action
A system may be allowed to read a customer record without being allowed to edit it. It may be allowed to draft a response without sending it. Treat those as separate capabilities, with separate owners and limits.
Reading is not automatically harmless. Sensitive information still needs access controls, and copying it into a new document can create another place where those controls matter.
Define three working boundaries
- Read within scope. Retrieve information the task needs and the requester is entitled to use.
- Prepare for review. Produce a draft, recommendation, or proposed change with enough context for a person to judge it.
- Act within an agreed policy. Execute only the specific actions the organization has authorized, with appropriate checks and a record of what happened.
These are discussion categories, not a universal permission policy. A draft containing sensitive data may need tighter controls than a routine update. Consequences, reversibility, recipients, and scope matter more than the label.
Make approval informative
“Approve?” is not much of a review. Show what will change, the destination or recipient, the information supporting the action, and anything unresolved. The reviewer should not have to reconstruct the entire task to understand the decision.
Approval should apply to a specific proposed action. If the destination or substance changes after approval, decide whether a new review is required. Do not treat a vague earlier request as unlimited authorization.
Do not turn every step into a checkpoint
A stream of low-value approval requests encourages people to click without examining them. Put review where a person has a meaningful decision to make. Keep routine, bounded steps within the policy the team has already agreed.
For a quote workflow, the system might assemble the approved sources and prepare the draft on its own. An unknown lane, conflicting customer terms, or the final external send can be a reason to stop and involve the designated reviewer.
Write down what happens when it cannot proceed
Missing information should produce a visible exception, not a confident guess. A rejected action should remain rejected. A failed connection should not be mistaken for an empty inbox.
Name the person who receives those exceptions, and provide a way to pause the workflow. Review the boundaries as you learn from actual use. They are part of operating the system, not a disclaimer attached at the end.
Take it into the next conversation.
For your first workflow, write three lists: what it may do, what it must prepare for approval, and what it must never do.
Have a workflow in mind?
Let’s talk about the work