A specialized AI assistant should be able to complete low-risk preparation and coordination without asking for permission at every step. It should pause before an action creates an external commitment, moves money, changes access, alters an important record, or makes a decision where only a person can weigh the consequences.
That is human-in-the-loop AI: people keep control of the decisions that matter, while the system handles defined work inside approved boundaries.
Ability is not permission. What a specialized AI assistant may do should come from the responsibility, the risk, and the company's policy.
Use a permission ladder, not one autonomy switch
The choice is not “fully automatic” or “manual.” Give each tool and action an appropriate level of authority.
| Level | Assistant may | Example | Human role |
|---|---|---|---|
| 1. Read | Retrieve approved information | Gather current project status | Defines allowed sources and access |
| 2. Prepare | Summarize, compare, or draft | Prepare a weekly operations brief | Reviews quality during launch and sampling |
| 3. Recommend | Propose a decision with evidence | Suggest how to route an unusual request | Makes or approves the decision |
| 4. Act with approval | Package an action and wait | Prepare an external email for approval | Reviews context and authorizes execution |
| 5. Act within limits | Complete a narrow, reversible action | Update a low-risk internal status field | Sets limits and monitors exceptions |
An assistant can have different levels for different tools. It might read a customer record, prepare a brief, recommend a next step, and still be unable to send a message without approval.
Start with the least authority needed to prove the responsibility. Expand only when testing and operating evidence show that a broader permission creates value without exceeding the company's tolerance for mistakes.
The OpenAI practical guide to agents recommends human intervention when a system exceeds failure thresholds and before sensitive, irreversible, or high-stakes actions. The same guide treats guardrails as layered controls rather than one setting. That is the right mental model for business approvals.
Seven decisions that should stop for a person
The exact boundaries depend on the company and workflow. These seven categories are a strong starting point for an owner-level review.
1. Making an external commitment
A message can create expectations even when it does not contain a formal contract. Promising a delivery date, approving scope, accepting a complaint, offering a remedy, or confirming a policy exception can commit the business.
Let the assistant gather context and prepare the response. Require a person to approve new commitments, unusual claims, or messages that change the customer relationship.
2. Moving money or changing financial terms
Payments, refunds, discounts, credits, purchasing, bank details, and pricing changes should have explicit approval and value thresholds.
An assistant can prepare the invoice package, compare the request with policy, identify missing support, and recommend a disposition. The financial decision should remain with an authorized person unless the company has deliberately approved a narrow, reversible action under a defined limit.
Budget limits for the assistant's own operating cost also matter. A poorly scoped recurring task can consume model or service fees even when it never touches company funds directly.
3. Deleting or overwriting important records
Deleting files, merging customer records, replacing approved content, closing a case, or changing the system of record can be difficult to reverse. Even a well-intended cleanup can remove context that someone else needs.
Prefer draft changes, a review queue, version history, and reversible status updates. If the system detects duplicates or stale records, it can present the evidence and proposed action instead of deciding which record survives.
4. Granting access or handling credentials
Creating accounts, changing roles, sharing restricted files, issuing keys, and using credentials should follow the company's normal identity and access processes.
The assistant should receive only the access required for its job. It should not pass credentials between tools, store secrets in ordinary notes, or widen its own permissions to complete a task.
This area is receiving active standards attention. NIST's 2026 AI Agent Standards Initiative includes agent identity, authorization, secure operation, and interoperability. For a business owner, the practical takeaway is simple: treat a tool-using assistant as an identity with defined authority, not as a feature that inherits whatever access is convenient.
5. Deciding a high-impact people, legal, health, or safety matter
Employment actions, legal positions, health decisions, safety exceptions, and other high-impact matters require accountable human judgment and may carry specific professional or regulatory duties.
An assistant may help gather approved information, check completeness, prepare a chronology, or identify a policy that a qualified person should review. It should not make the final decision or present its output as professional advice.
6. Publishing in the company's name
Public posts, website changes, advertisements, proposals, announcements, and mass communication affect reputation and can create factual or legal exposure.
The assistant can research, prepare, fact-check, and format the work. A person should approve publication until the company has a well-tested class of content, approved source rules, and a clear correction process. Even then, sensitive claims and new positions should stop for review.
7. Creating a new exception or interpreting uncertain policy
An assistant should not turn an ambiguous situation into a new company rule. If the available policy conflicts, the relevant information is missing, or the request falls outside known examples, the correct action is escalation.
A well-designed assistant makes uncertainty visible, gathers the evidence, and routes the question to the policy owner. The resulting decision can then be documented for future cases.
Build an approval matrix for each responsibility
Use a small matrix during design. It forces the owner and implementer to agree on authority before the system receives access.
| Action | Consequence if wrong | Reversible? | Starting control |
|---|---|---|---|
| Read approved project status | Incomplete internal brief | Yes | Allow and log sources |
| Draft an account update | Inaccurate wording | Yes | Prepare for review |
| Change an internal task status | Work routed incorrectly | Usually | Allow within named projects and log |
| Send a customer commitment | Customer expectation or dispute | Not easily | Require approval |
| Approve a refund | Financial loss and policy precedent | Sometimes | Authorized person decides |
| Change a user's access | Data exposure or service disruption | Sometimes | Follow identity process and require approval |
Add the owner, value threshold, timeout, and escalation path where relevant. Review the matrix when the job, connected tools, or business policy changes.
Keep approvals useful instead of exhausting
Too many low-value prompts train people to click approve without reading. Too few prompts leave the business exposed. Design approval around meaningful decisions.
Approve a plan or outcome, not every mechanical step
If the assistant needs to read five approved records to prepare one brief, the reviewer should not approve each read. Review the plan before a large body of work begins or review the completed action package before an external change.
Anthropic's 2026 discussion of trustworthy agents describes this pattern: users can review and approve a plan, then retain the ability to intervene while it runs. The useful oversight point is often the strategy or consequential action, not every click.
Give the reviewer a complete decision package
An approval request should include:
- What the assistant proposes
- Why it proposes it
- Which approved sources it used
- What changed since the last approval
- The likely consequence
- The deadline or effect of doing nothing
- A way to approve, reject, or request a change
An unexplained “Approve?” button shifts the investigation back to the person and removes much of the assistant's value.
Use thresholds and escalation
Not every case has the same consequence. A company may allow a reversible internal update while requiring review for external actions. It may set a spending ceiling, restrict publication to an approved content type, or route a policy exception to a named owner.
Silence should not become approval. If a decision is time-sensitive, send it to the next authorized person or pause the work.
Keep an activity and decision record
Record what the assistant read, proposed, changed, and received approval to do. This helps answer operational questions, investigate mistakes, and improve the instructions.
Paperclip's current governance model illustrates approval gates, plan review, budget caps, and an activity trail around agent work. That product is one technical example, not a universal design. The wider principle is that useful independence needs visible control.
Review the boundary over time
Human-in-the-loop design should change based on evidence. Begin with representative tests and stricter review. Track corrections, uncertainty, exceptions, and attempted actions outside the role. Then decide whether a narrow category can receive more authority or needs a tighter boundary.
The NIST Generative AI Profile notes that generative AI may require added human review, tracking, documentation, and management oversight. It also frames governance and pre-deployment testing as lifecycle practices. Approval design is therefore part of ongoing operation, not a box checked at launch.
Before assigning a responsibility, confirm:
- A human owner is named
- Approved sources and tools are listed
- Each tool has a permission level
- The seven decision categories have been reviewed
- Value and action thresholds are written down
- Approval requests include evidence and context
- Timeouts and escalations are defined
- Work and decisions are logged
- The team can pause the responsibility
- Boundaries are reviewed after changes and incidents
Northern Logic can define these controls while building and managing a specialized AI assistant. The broader managed AI service covers ongoing monitoring, correction, and improvement. You can also review Northern Logic's security approach or book a free 15-minute AI assessment to discuss one responsibility and where a person should stay in control.
The aim is not maximum independence. It is useful work with authority that the business can understand, review, and change.
Sources
- OpenAI, A Practical Guide to Building AI Agents
- Anthropic, Trustworthy Agents in Practice, April 9, 2026
- NIST, AI Agent Standards Initiative, created February 17, 2026
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 26, 2024
- Paperclip, Governance and Approvals