Separate four different kinds of involvement
| Checkpoint | What the person does |
|---|---|
| Advice | Uses a suggestion to inform their own work; the system does not decide for them. |
| Confirmation | Checks the specific action about to happen, including its target and values. |
| Approval | Makes a required business decision before the process may continue. |
| Escalation | Takes over because the request is uncertain, outside scope or unsuccessful. |
A confirmation button is not automatically the business approval your procedure requires. For example, confirming a message send does not necessarily approve the commercial offer described inside it.
- Prepare a proposal
- Review evidence and impact
- Approve or reject
- Verify the outcome
Make the decision understandable
The reviewer needs to see the proposed outcome, the relevant evidence and the consequences. For a record update, show the target record and important values. For an outbound message, show the recipient and final text. Give the person a workable way to reject or correct the proposal.
Avoid a screen where the easiest action is to approve information the reviewer cannot inspect. If the evidence is missing, “request clarification” should be a legitimate outcome rather than a failure to complete the task.
A worked example: changing a service commitment
Illustrative scenario. An agent prepares a response to a customer requesting an earlier delivery date. It can summarise the request and relevant account information, but a named colleague must approve any change to the promised date. The configured update route checks the approval before applying the change.
Test what happens when the colleague rejects the proposal, the record changes while it is being reviewed, or the update fails. The final message must describe the outcome that actually occurred.
Treat instructions and enforcement separately
An instruction such as “always ask first” describes intended behaviour. If approval is mandatory, the permitted action needs an enforced check that cannot be satisfied merely by a model saying approval exists. The exact mechanism depends on the implementation.
NIST’s AI Risk Management Framework organises risk work across governance, context, measurement and management. For a business workflow, that means assigning responsibility and checking the deployed process rather than stopping at a written policy. [1]
Check the channel before assuming the same experience
REDA AI can expose configured work through different channels. Some actions may execute without an approval card, depending on configuration and channel. An external assistant host can also present interactions differently. Do not copy a screenshot of one confirmation flow into an assurance for every surface.
Review the chosen channel and action with your administrator. Our governance guide explains the control boundaries; the pilot should demonstrate the required checkpoint with a representative user.
Sources
- NIST — AI Risk Management Framework. Accessed 22 September 2026.