Require human approval when an AI action is hard to reverse, materially affects a person or the business, falls outside a defined policy, or lacks enough evidence. Allow bounded autonomy for routine, reversible actions with clear permissions, monitoring, and an exception path.
Use business impact, reversibility, and uncertainty as the gate
Do not decide autonomy from the model name or a single confidence score. Decide it from the action the AI is about to take. A draft that an employee can discard is different from sending a customer a binding price, issuing a refund, changing payroll data, or deleting a record. The same AI capability may be safe to use autonomously for one step and require approval for the next.
A practical gate asks four questions: How large is the possible impact? Can the action be reversed cleanly? Is the situation inside a documented policy? Is the evidence complete enough for this task? If the impact is material, reversal is difficult, the case is unusual, or the evidence is weak, route the proposed action to a named human owner before execution.
Create three operating levels instead of one AI switch
Use a simple operating model. In assist mode, the AI gathers information or drafts a recommendation but cannot change the system of record. In approve-before-action mode, it prepares a specific action and the responsible employee accepts, edits, or rejects it. In bounded-autonomy mode, it may execute defined low-risk actions within explicit limits and send exceptions to a queue.
For example, an AI employee could classify an incoming request and prepare a reply in assist mode. It could schedule a standard follow-up after approval. It might autonomously tag complete records or send an internal reminder when both actions are reversible and covered by policy. Moving between levels should require evidence from real use, not enthusiasm after a successful demonstration.
Define the approval policy before building the interface
Write the rule in operational language: who owns the decision, what information they must see, which thresholds require review, and what happens when that person is unavailable. Avoid a generic approve button that gives the reviewer no reason, source evidence, or description of the proposed effect.
The NIST AI Risk Management Framework calls for organizations to define roles and responsibilities for human-AI configurations, document how outputs are used and overseen, and establish human-oversight processes that match organizational policy. Translate that guidance into acceptance criteria the business can test: the right reviewer sees the relevant evidence, understands the exact action, and can stop or change it before the effect occurs.
Give the reviewer enough context to make a real decision
Show the source records, the proposed action, the policy or rule that applies, and the consequence of approval. Highlight missing or conflicting evidence rather than hiding it behind a probability. A reviewer who must reconstruct the whole case in another system will either slow the workflow or approve without meaningful review.
Measure the review step itself. Track how often reviewers accept, edit, reject, or escalate proposals; how long decisions wait; and which reasons repeat. High approval volume is not proof of good automation. Repeated edits may reveal a weak prompt, missing data, an unclear policy, or a task that should remain manual.
Keep execution permissions narrower than reasoning permissions
An AI may be allowed to read several records to prepare an answer while receiving permission to change only one field, create one draft, or call one approved operation. Enforce those limits in the surrounding software and service accounts. A written prompt such as do not issue refunds over a threshold is not an access control by itself.
Separate read, propose, approve, and execute permissions. Set transaction and volume limits where the workflow supports them. Require a fresh authorization for sensitive actions instead of reusing a broad credential. Log the inputs, proposed action, reviewer decision, final execution result, and policy version needed to explain what happened.
Design exceptions, override, and shutdown before launch
Every autonomous path needs a visible exception route. Define what happens when required data is missing, systems disagree, a tool call fails, or the case falls outside the supported policy. The safest response is often to preserve the work, stop the next effect, and assign the case to a person with enough context to continue.
NIST's playbook recommends ongoing monitoring, incident response, appeal and override mechanisms, and clearly assigned responsibility. For a business workflow, that means an owner can pause automation, inspect pending work, reverse supported actions, and recover without searching raw logs. Test these controls with deliberate failure scenarios before increasing the AI's authority.
Expand autonomy only after a measured operating review
Start with representative work and include difficult cases, not only clean examples. Record the baseline: processing time, error and correction patterns, review effort, and the business consequence of mistakes. Then compare the AI-assisted workflow against the same outcome. The goal is dependable completed work, not the largest number of automated steps.
Hold a scheduled review with the business owner and technical owner. Promote a task from assist to approval or from approval to bounded autonomy only when the policy is stable, exceptions are understood, controls are working, and the remaining risk fits the organization's tolerance. Reduce authority when the workflow, data, model, or connected systems change materially.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.