Define an AI assistant’s approval limits before it acts
Write an AI action-authority matrix that names the target, permitted change and approver. Decide when approvals expire and how uncertain results are checked.
An AI assistant's approval rule should identify the action, target record, permitted change and person who can authorize it. “Ask a human before important actions” leaves the assistant and the reviewer to invent the boundary each time. Write the boundary before connecting the action to live work.
Start from the consequences of a mistake. Preparing an internal draft, changing an accepted order and sending a customer message have different effects. The organization should decide which actions may run automatically within a tested scope, which need approval and which remain unavailable.
This is an original operating-policy worksheet. NIST's AI Risk Management Framework is a voluntary resource for incorporating trustworthiness considerations into AI design, use and evaluation; it does not supply the specific action limits below or certify that a system enforces them. NIST AI Risk Management Framework.
Define authority with more than a job title
For each action, name the record, fields and circumstances covered by the authority. A service manager may be permitted to correct an internal appointment note without being authorized to change the customer's agreed charge. An accounting reviewer may review a draft without having authority to alter bank details.
Use the AI data permission guide to establish the read and write boundaries first. Approval by the wrong person should not become a shortcut around those boundaries.
| Proposed action | Boundary to decide | Evidence required before execution |
|---|---|---|
| Prepare an internal draft | Allowed source, destination and fields | Source reference and visible draft state |
| Update an operational record | Specific fields and permitted record state | Current values, proposed values and responsible owner |
| Change an accepted commitment | Who can authorize this kind of change | Exact revised terms or scope approved by that person |
| Send information outside the business | Recipient, content and disclosure authority | Reviewed final content and destination |
| Delete or make a difficult-to-reverse change | Whether the action is available at all | Explicit policy, qualified authority and recovery evidence |
These rows are prompts for policy decisions, not universal permissions for a business or a tool. Leave an action unavailable when its owner or recovery path is unresolved.
Make the approval describe the actual change
Imagine a fictional assistant preparing an appointment update. The reviewer approves moving a named job to Thursday morning. Before execution, someone changes the assigned technician and the customer requests Friday instead.
The earlier approval no longer describes the proposed action. Define which changes invalidate it: target record, recipient, scope, amount, date or other material input. Require a new review when those conditions change. A general “looks good” in a conversation should not be stretched to cover a different result.
Show the reviewer the current state, proposed state, source evidence and material consequences. The reviewer needs enough context to decide, but should not have to reconstruct the entire conversation to discover what they are authorizing.
Separate organizational permission from software enforcement
A written rule establishes the intended policy. The implementation must demonstrate how that policy limits execution. Ask which controls check identity, record state and approval at the moment the action runs.
Odoo, for example, documents user and group access rights, operation permissions and record rules. Those mechanisms are relevant to the technical design, but their presence alone does not prove that an AI action follows your specific approval policy. Odoo 19 access rights.
Use the Odoo AI action tests when implementing that boundary in Odoo. For another platform, use its actual permission model and inspect the resulting records. Do not transfer a passing test from one tool to a different execution path.
Define what happens when the result is uncertain
An interrupted response can leave the team unsure whether an action happened. Specify who checks the target system, what evidence establishes completion and when a retry is permitted. The assistant should not receive blanket authority to repeat an action merely because its own confirmation was lost.
Name the person who can disable the action and the person who investigates an incorrect result. Preserve the source, proposed change, approval, execution identity and outcome in an appropriate record. Keep access to that evidence consistent with the business data it contains.
Review the matrix when the workflow, tool, permissions or responsible roles change. A narrow action may earn a broader boundary after demonstrated results, but that should be a recorded policy decision. The durable output is a set of action limits that people understand and the system has been tested to enforce.