Define an assistant's authority through the actions it can execute, not a sentence promising “human review.” Drafting, changing a record, sending a message and approving a price are different activities with different permissions. A controlled workflow makes clear what the system proposes, what the reviewer sees, exactly what approval authorizes, and how uncertainty stops the process or returns it to manual handling.
An approval button is insufficient if the assistant can send different wording or change the recipient afterward. Human review also fails as a control when the person lacks time, evidence or rejection authority. This article concerns action boundaries and responsibility handoff, rather than model selection, accuracy evaluation or knowledge-source organization.
Write an allowed-action matrix
Start with a short list: read approved fields, suggest a category, prepare a draft and show it to an authorized person. Alongside it, list prohibited actions: independent sending, price changes, permission changes and access beyond the user's authorized records. Do not grant broad tool permissions and rely only on text instructions to keep them unused.
| Action | Proposed authority | Required evidence |
|---|---|---|
| Read inquiry details | Assistant within specified access | Approved source and authorized identity |
| Suggest a reply | Assistant, as a draft | Missing information and assumptions identified |
| Approve text and destination | Authorized person | Final text, recipient and attachments |
| Send | Restricted path after matching approval | Valid approval for that exact operation |
| Grant an exception or new commitment | Relevant decision owner | Separate process outside assistant authority |
Product Discovery & Requirements can clarify these roles and states before integrations are built. NIST's governance guidance emphasizes documented responsibilities and delegated authorities. Using that reference does not establish certification, or mean that adding a person eliminates risk. NIST Govern guidance.
Bind approval to what will actually happen
The approval view should show final content, destination, executing account, attachments and any record changes. The reviewer also needs the source or basis for the suggestion, not merely a reassuring explanation that cannot be checked. If wording, recipient or attachment changes, obtain approval for the changed operation instead of inheriting the old permission.
Define approval validity according to the process. A reply may become stale when a new message arrives or an underlying fact changes. Do not apply one universal timeout without considering consequences. Rejection must lead to a useful state rather than generating new drafts indefinitely until someone accepts one.
Hypothetical example: drafting a reply to a service inquiry
Imagine a business receiving inquiries about its services. The assistant reads selected fields from an authorized inquiry and proposes wording based on an approved service description. It cannot set prices, promise delivery dates or send independently. This is a fictional workflow, not a claim that LAB operates an automated sales team or achieves particular savings.
A customer asks for a special price and an early delivery date. The assistant drafts a request for information needed to scope the work, marking price and timing as matters for an authorized owner. The employee sees the wording, recipient, source and unresolved fields. They can edit, reject or approve the final version within their own authority. Silence cannot become approval.
After approval, an update changes the recipient address. Sending stops until the new destination is reviewed. In another test, an authorized send attempt loses its response. The workflow records an uncertain outcome and checks delivery status before retrying, to avoid duplicate messages. If the assistant is unavailable, the original inquiry remains in a manual queue rather than acquiring a fabricated ready-to-send response.
Design the queue around real review capacity
Use distinct states for ready-to-review drafts, missing information, escalation, rejection, approval, execution and uncertain outcomes. Do not hide pending cases inside a broad success figure. Every state needs an owner for the next step and a way to reassign work when the usual person is unavailable.
Ask how much review the team can genuinely perform and what happens when waiting increases. Producing more drafts is not useful if employees begin approving them without reading. Narrowing the pilot or pausing generation may be appropriate. Expanding automatic sending to clear a backlog requires a separate decision and evaluation, not an unnoticed configuration change.
Marketing Automation and Lifecycle Journeys may be relevant where the workflow involves customer communication, consent and sales handoff. Preserve consent, audience and destination limits: permission to build a drafting assistant is not permission to send campaigns or contact new people.
Test prevention and fallback, not just the draft
Implementation within AI & Machine Learning Engineering needs actual permissions matching the written boundary. Software Quality Assurance can verify state transitions and prevention of unapproved actions. Confirm a suitable domain reviewer and operating owner rather than assuming the customer will find someone afterward.
Acceptance should demonstrate that:
- Sending cannot happen without approval from the authorized person.
- Changes to content or target invalidate approval for the changed operation.
- Rejection and expired approval do not become automatic execution.
- Incoming-message content cannot extend tool or source permissions.
- Integration failures produce an investigable state instead of repeating an action with an unknown outcome.
- Disabling the assistant leaves a usable manual route with the necessary information.
- The record distinguishes proposal, approval and execution without retaining secrets or unnecessary data.
These cases should be exercised with permitted test accounts and data. A successful demonstration of one approved message does not prove that the rejection, change and uncertainty paths work. Include the negative cases in the acceptance record.
Know when the design needs a new review
Adding a channel, new recipient group or write permission changes the task. It should not be treated as a minor setting that inherits the original pilot's approval. Revisit impact, permissions, reviewer capacity and evidence before expanding scope.
This approach should not be used to quietly delegate high-impact decisions to autonomous systems. Sensitive decisions remain with appropriately authorized people and processes. The workflow can assist their preparation without claiming the authority to decide on their behalf.
Frequently asked questions
Does every output need separate approval?
That depends on the action and its boundary. Delegating a low-impact category still requires definition, testing and permission; it does not authorize unrelated actions.
What if the reviewer is absent?
Reassign to another authorized person, keep the work manual or leave it pending. Absence is not implied consent and does not justify bypassing the gate.
Can the assistant suggest a price?
Only from permitted sources within explicit authority boundaries and an appropriate approval process. It should not invent a price, discount or commitment to complete a reply.
What should we provide first?
Bring the current workflow, permitted and prohibited actions, approval owners and redacted input/output examples. Start with one path whose controlled behavior and manual alternative can be demonstrated before expansion.
Reference
NIST AI RMF Playbook: Govern, reviewed 26 October 2026. The example is fictional, not a staffing-replacement promise or a guarantee of error-free operation.
