Judge each action separately
The same tool might prepare a private draft, post to a group or change a customer record. Each action has different consequences. Write down what it may do, when it may do it and who can approve it.
Check what the tool can read as well as what it can change. Opening a confidential document or including it in a draft can expose private information even when the original file stays unchanged. Reading still needs permission, and preparing drafts can cost money.
Three example review levels
| Level | Possible treatment | Example with conditions |
|---|---|---|
| Routine task with clear limits | May run under rules already approved, with access limited to the records it needs. | Prepare a private draft from authorised records for its intended reviewer. |
| Change to a shared record | Ask the person responsible for that record to review it. | Suggest a customer record update, showing the old value and the reason. |
| Action with wider consequences | Get approval from someone authorised to make that decision. | Send to a customer, commit resources, delete records or change permissions. |
The classification depends on the actual data and context. Posting internally can expose sensitive information to the wrong team. A reversible field change can trigger another system before it is reverted. A small transaction can still require authorisation. Your organisation's existing policy should determine the final rules.
Ask three questions before allowing an action
Can you undo it?
Can the organisation undo the practical effects, including downstream events and copies already seen by someone else?
What does it commit you to?
Does it authorise spending, change availability, promise delivery or alter a business obligation?
Who will see it?
Who receives the information, and are they authorised to receive those particular records?
Consider how often it runs too. One wrong update is different from the same error across hundreds of accounts. Test the number of cases and permissions the tool will really use, and set limits you can enforce.
A copyable policy table
| Operation | Review requirement | Checks to define |
|---|---|---|
| Read source records | Access already approved for this task. | Permitted accounts, fields and handling of removed access. |
| Prepare a private draft | Review before using the output for a consequential task. | Correct recipient, source references and visible missing information. |
| Update a shared record | Record owner or another authorised reviewer. | Old and new values, current record state and downstream effects. |
| Send externally | Named authority for the relationship and message. | Recipient, exact approved content, expiry and duplicate prevention. |
| Commit resources | Authority defined by the organisation. | Applicable limits, current availability and additional required approvals. |
| Delete or change access | System owner and the existing change process. | Scope, recoverability and verification of the intended effect. |
Assign an accountable owner and a deputy. A role can define authority, but the operating process also needs to resolve that role to an available person. Record what should happen while the approver is absent or a request is disputed.
Enforce the policy in the application
Telling an AI tool to ask permission is not enough. The software must block an action until the right approval has been recorded for that exact change. A document it reads must not be able to give the tool new permissions by containing instructions.
Approval should cover the exact content and recipient. Check permissions and the latest record again before acting. Decide what happens if approval is declined, expires or a request is repeated, and record the result. Data and approvals lists the questions we settle with your team.
Common mistakes
- Treating every read as harmless without checking what information it exposes.
- Approving a draft and then allowing its content or recipient to change before sending.
- Assuming a rejected action cannot be retried through another path.
- Ignoring downstream automation triggered by a seemingly small update.
- Reviewing only successful examples and leaving denied or incomplete cases untested.
- Adding more users or running many more cases without revisiting the limits.
Common questions
Must every operation wait for a person?
No single policy fits every task. Define which bounded operations may run under prior authorisation and which require a fresh decision. Enforce the boundaries and review their performance.
How should we test approval?
Try a permitted action, an unauthorised reviewer, a rejection, an expired decision, a changed output and a repeated request. Verify the resulting system state rather than only the message shown to the user.
Can the policy change?
Yes, through an explicit review of evidence and consequences. Repeated acceptance alone does not prove an action is safe to automate; check failure cases and downstream effects before changing authority.
Talk through your taskTell us what the tool would need to do and who could approve each action.