Decision Rights for AI Actions: A Matrix for Who May Approve What

Executive summary

Most businesses know who may sign what. A purchasing manager can commit up to one amount, the controller up to another, the CEO above that. It is written down and an auditor can test it. Then an AI tool is connected to the ERP through a service account, and it can change a thousand reorder points tonight. The delegation of authority does not mention it.

The matrix was written for people. The thing with the widest write access in the building has no row. Until someone writes one, that service account holds more standing authority than the CEO: no limit, no approver, no expiry.

This guide extends the decision rights matrix template to AI actions without repeating its roles or threshold method. It gives four levels of what an AI may do, a fifth that comes later and stays narrow, an approval request that can be judged rather than just signed, and the rules for moving an action up or down. In the worked example, one action earns more authority and one loses it.

"Do we trust AI?" has no useful answer. "Which actions, at what size, with whose name on them?" does.

When to use this

Use this guide when:

• An AI tool has write access to a system of record (ERP, accounting, CRM, pricing), or is about to.
• People describe a tool's permissions as "whatever the integration user can do."
• One person approves AI output all day and almost never says no.
• A pilot went well and someone wants to "let it run" without saying what "it" covers.
• An auditor or lender asks who approved a change, and the answer is a system account.

If you are still choosing where to start, read your first AI pilot in finance first.

Diagnostic questions

Answer these in writing, with the controller and the tool's owner in the room.

1. Which AI tools can write to a system of record today, and under which account?
2. Does your delegation of authority mention any of them? If not, who decided what they may do?
3. When a tool changes a record, whose name appears in the log: a person, or a service account?
4. How many AI approvals did each approver give last week, and how many did they reject or send back?
5. What does the approver see: the action alone, or the reasoning, the sources and how often this kind of action has been right?
6. Could the approver judge the work by hand?
7. Which AI actions were reversed last quarter, and did anyone change what the tool may do as a result?

Questions 2 and 3 find the gap. Questions 4 to 6 test whether approvals are real.

Framework: five levels, one request, two rules

A delegation of authority for people works because each limit is attached to a role, each decision leaves a name, and authority narrows when it is misused. AI tools usually get none of that: they inherit an account, the log shows that account, and nothing narrows when they are wrong. The fix is the instrument you already trust. Add AI action types as rows, each with a level, a threshold, an approver by role, the evidence the request must show, and what is recorded.

A dashboard never needed a row, because the worst it can do is show a wrong number. The row becomes necessary the day a tool writes to a record, and it has to exist before that day. Written after the first reversal, it is a post-mortem.

The default you already have

Every AI tool with write access already sits at a level. Nobody chose it. Under an integration account it can usually change any record that account can touch, at any size, with nobody approving first and nothing narrowing when it is wrong. By the levels below, that is level 5 with no scope, no expiry and no named approver: the highest authority in the matrix, held by the actor with the shortest record.

A pattern that comes up often in mid-market diligence, described here as a composite rather than any one company: the integration user was cloned from an administrator's profile during setup because that was faster than scoping it, the pilot ended, and the permissions stayed. When a lender or buyer asks who approved a run of changed records, the delegation of authority that was tested line by line for people has nothing to say, and the log shows a username nobody owns.

So the first pass through this matrix takes authority away. It gives some back only on the record.

The levels

Every action starts at level 4 or below. Level 5 exists because approving 40 identical, low-value, reversible actions a week one by one is how real review dies. It is still approval: a named person approves the class of action in writing, the way a standing purchase order is approved, and every action under it is inside that scope before it runs and on the record after.

Two rules hold at every level. Each row has one named approver role. And an AI never moves itself between levels; a person does, on the record.

The approval request, built to be judged

"Change reorder point for SKU 4471 from 400 to 352. Approve?" can be signed. It cannot be judged. A request built to be judged shows four things.

The track record is the line usually missing. For testing the finding itself, see how to trust an AI finding.

Approver competence and approval fatigue

Two failures turn approval into theater.

The approver cannot judge the work. A signature from someone who could not tell a good reorder point from a bad one adds nothing. Each row's approver should be the person expected to make that decision by hand, within the limit they hold by hand. If nobody can judge an action, it stays at level 3.

Volume turns review into rubber-stamping. An approver clicking yes 200 times a week is no longer reading: approval rates near 100%, approval times in seconds, no send-backs. Treat a long run of zero rejections as a warning sign. Tier by risk. Keep high-impact rows at level 4, and earn standing authority on narrow, reversible, high-volume rows so attention is left for them.

If your answer to AI risk today is "a person reviews everything," count last week's approvals and how many were turned down. If the second number is zero, nobody is reviewing anything. One person is clicking yes.

Earning and losing standing authority

Authority goes up by the quarter and comes down by the day.

To move a row up to level 5, all of these must hold, from the record: at least two full quarters at level 4 with enough volume to judge; send-backs or rejections above zero in each quarter, with reasons, so you know the approver was reading; approvals later reversed under a written rate; every miss (something the AI should have proposed and did not) explained and fixed; an action that is low-value and can be undone within a working day; a scope narrower than the level-4 threshold, with a sampling rate, expiry and revocation triggers; and the signature of the named approver who will answer for it. Nothing on that list comes from a demo, a vendor's promise or a sponsor's enthusiasm. All of it comes from the record.

To move a row down, any one is enough: a reversal with a cash, customer or supplier consequence (down one level the same day, pending review); a sampled error rate above the trigger; a change in what the action depends on, such as a new template, system or customer terms; or an expiry date passing without review.

Moving down never needs a meeting. Moving up always does.

Step-by-step process

1. List the AI action types. For each tool with write access, list what it can send, change, post, pay or price. One row per action type. Owner: controller with the tool owner.
2. Assign a starting level. Level 3 or 4, never 5. Owner: CFO.
3. Set thresholds and approvers. Use the threshold method in the people matrix. The AI threshold never exceeds the approver's own limit for the same decision. Name a backup. Owner: CFO and function heads.
4. Write the evidence column. The approver for each row lists what they need to judge it. Owner: row approver.
5. Write the escalation rule. Outside the threshold, in an exception, or when nobody answers. Owner: controller.
6. Fix the record. Every action carries the approver's name and the request as shown, not a service account. Owner: tool owner.
7. Report approval quality monthly by row: approve, edit, send-back and reject rates, time to approve, approvals later reversed, misses. Owner: controller.
8. Review levels quarterly, and write every change as an authority change record the day it is decided. Owner: CFO.

The policy and ownership around this sit in AI governance for finance and operations; reversals and misses feed the AI risk register and review cadence.

Worked example: a distributor's AI action matrix

Illustrative. The company, thresholds, volumes and outcomes are a composite invented to show the method. They are not recommendations or benchmarks.

The matrix

A regional distributor connects an AI tool to its ERP, AR and purchasing systems and writes four rows.

Row 4 stays at level 3 because a price is hard to take back, and the discount approval matrix already says who decides. Row 2 mirrors the AP manager's manual limits in the AP approval process.

Escalation rule. An action outside its threshold drops to level 3 and goes one approver up. An action touching a customer in dispute, a supplier on hold or a seasonal SKU is level 3 at any size. A request unanswered after one working day goes to the backup. It never runs by default. Silence is not approval.

The row that moved up: payment reminders

After two quarters at level 4, row 1's record showed:

Approved in total: 988 + 36 = 1,024. Two were later reversed (reminders to customers whose payment had arrived but was not yet applied): 2 ÷ 1,024 = 0.2%, under the 0.5% rule the distributor had written. Send-backs and rejections were above zero in both quarters, with reasons, so the AR lead was reading. Three misses traced to customer records with no email address, and were fixed. The request now shows that the bank feed was checked the same day.

The CFO approved standing authority for a narrower scope than level 4 allowed: up to $25,000, 1 to 30 days overdue, no open dispute or unapplied credit, standard template only. It expires at the next quarterly review unless renewed, and any of the downward triggers above ends it the same day. The AR lead signed as the approver who answers for it, samples 1 in 10 sent reminders weekly and reads every customer reply.

At 40 requests a week (1,040 ÷ 26 weeks) and about 3 minutes each, approving reminders took 120 minutes a week. Sampling 4 at about 5 minutes takes 20. As an illustration, 100 minutes a week move to row 2, where a wrong date can cost a discount or a shipment.

The row that moved down: reorder points

Over the same two quarters, row 3 produced 180 requests: 171 approved, 6 sent back, 3 rejected. In the second quarter the purchasing manager approved a cut on one SKU from 400 to 352 units, a 12% change inside the 15% threshold. The request showed 13 weeks of demand. A customer's annual stocking order, placed every March, sat outside that window. The SKU stocked out for 9 days, the change was reversed, and expedited freight cost $4,800.

The ERP recorded all of it, the field change under the integration account included. Nothing in it connected the stockout to the change, and nothing was responsible for asking whether the tool should keep the right to make the next one.

The approver was competent. The request was not built to be judged: it showed 13 weeks when the decision needed 52, and median approval time on the row was under two minutes. The row moved to level 3 the same day, and the evidence column now requires 52 weeks of demand and named annual orders. To return to level 4 it needs a full quarter at level 3 in which no recommendation would have caused a stockout.

Templates

Template A: AI action matrix

A tool that can do five things has five rows.

Template B: Authority change record

One paragraph for every change of level, scope or approver, written the day it is decided:

On [date], [action type, row #] moved from level [n] to level [n], scope [threshold and conditions]. Why: [one sentence]. Evidence from the record: [requests and period; approved, edited, sent back, rejected; approvals later reversed; misses and their causes]. Review after the change: [sampling rate, or each action approved]. Reverts if: [triggers], or on [expiry date] if not renewed. Approved by: [name, role], who will answer for it.

For row 1, the evidence line would read: 1,040 requests over two quarters; 95.0% approved as drafted, 3.5% edited, 1.0% sent back, 0.6% rejected; 2 approvals later reversed (0.2%), cause fixed; 3 misses from missing contact data, fixed.

Metrics and KPIs for AI decision rights

Level-change lag is the most telling. A row moved down in a hallway and written up three weeks later kept its old authority for three weeks.

Common mistakes

1. Granting by tool, not by action. "The AI can access AP" says nothing about moving a payment date.
2. Starting at standing authority after a good pilot. A pilot proves the drafts are good. Nothing more.
3. Approvers who cannot judge the work. A signature without a judgment.
4. Requests that show only the action. The approver is asked to trust, not to decide.
5. A service account in the log. The delegation cannot be tested.
6. Moving down slowly. Waiting for the quarterly review after a costly reversal leaves the authority in place for the next one.

AI prompt assistance

These prompts help build and test the matrix; they do not set thresholds. Do not paste confidential data into a tool your company has not approved.

1. Find the actions inside a tool's permissions.

Here is the permission list for an integration user in our ERP (pasted). List every action type it allows that changes a record, sends a message outside the company, or moves money, grouped by business process. Do not judge which are safe.

Check: the system administrator confirms the list against live permissions before it becomes rows.

2. Read approval quality from the record.

Here is one quarter of AI approval requests: row, approver, decision (approved, edited, sent back, rejected), minutes to decide, and whether the action was later reversed. For each row and approver, compute each decision rate, median minutes to decide and the rate of approvals later reversed. Flag any approver with no rejections or send-backs. Show the arithmetic.

Check: recompute one row by hand and confirm the export includes every request, not only completed ones.

3. Draft an authority change record.

Using only these facts (pasted), write one authority change record paragraph: date, row, old and new level, scope, reason, evidence from the record, review after the change, revert triggers and expiry. Leave the approver name blank.

Check: the CFO reads it against the record, edits it and signs it before the level changes.

Implementation guide

No row moves to level 5 in the first 90 days.

Governance: the CFO owns the matrix and signs every level change. Each row's approver owns its evidence column. The controller keeps the approval quality report and change records. Review it in the same quarterly session as the people matrix.

Downloadable assets

Template A and Template B are designed to be copied into a spreadsheet and a document, with the metrics table as a second tab. No calculator exists for this topic.

Related resources

• AI trust and governance hub: the guides on trusting, approving and recording AI work.
• Decision rights matrix template: the people matrix and threshold method this guide extends.
• AI governance for finance and operations: the policy and roles the matrix sits inside.
• How to trust an AI finding: testing the reasoning and sources behind a recommendation.
• AI risk register and review cadence: where reversals and misses become tracked risks.
• Discount approval matrix governance: the price authority row 4 defers to.

Frequently asked questions

What are decision rights for AI?

Written rules for which actions an AI tool may take, at what size, and who must approve them. They work like a delegation of authority for people: one row per action type, with a level, a threshold, a named approver role and a record.

Who should approve AI actions?

The person who would make the same decision by hand, within the same limit. If they could not judge a reorder point without the AI, they should not approve one with it. Name a backup for every row, and never let an unanswered request run by default.

Should AI ever act without approving each action?

Only for a narrow class of low-value, reversible actions, after at least two quarters of records show the approvals were real and rarely reversed. A named person still approves the scope in advance, a sample is reviewed afterward, and the authority reverts the day a trigger fires.

What should happen after an AI action is reversed?

If the reversal had a cash, customer or supplier consequence, move the row down one level the same day. Find what the request failed to show, add it to the evidence column, and write an authority change record. The row earns its level back on the record.

How this works in a System of Performance

An AI action matrix holds only if each request carries its evidence and each level change is written down when it is decided. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. To see where your own approvals stand, bring it to us as a launch partner.