An AI Risk Register for Finance and Operations Teams, and How Often to Review It

Executive summary

Ask a finance team that uses AI what could go wrong and you will get a good answer in under a minute. The data could be stale. The tool could be confidently wrong. Someone could stop checking. Then ask where that answer is written down, who owns each part, and when the control behind it was last shown to work. The room goes quiet.

That gap is the hidden risk. The risks are known. They live in people's heads, get discussed when something breaks and are forgotten when nothing does.

A register closes the gap only if every row has a named owner, a control that runs on a schedule, and the date that control was last tested. This guide names eight risks specific to AI in finance and operations, works an illustrative eight-row register, and sets a cadence: 15 minutes a month in the operating review, two control tests a quarter, and any miss logged within five working days.

Approval limits are covered in decision rights for AI actions, and every related page is in the AI trust and governance hub.

When to use this

Use this when:

• AI drafts or proposes anything that reaches a payment, a forecast, a customer, a lender or the board.
• The team can list the risks, but nobody can say which control was last tested, or when.
• One person set up the AI tools and is the only one who could explain them on a bad day.

If nothing is live yet, start with your first AI pilot in finance and build the register as the pilot goes live.

Diagnostic questions

Answer these about the AI you already use, including the assistant someone set up on their own.

1. Can you list every place AI drafts, proposes or takes an action in finance and operations?
2. For each, who owns the risk, as distinct from who uses the tool?
3. Which controls run on a schedule, and which run only when someone remembers?
4. When was each control last tested by feeding it a case it should catch?
5. How many AI proposals were rejected or sent back last quarter? If none, is that good news?
6. What did the AI cost last month, counting the hours spent checking it?
7. If the person who set it up left on Friday, who would run it on Monday?

If you cannot answer question 4 for most rows, you have controls on paper that nobody has shown to work.

Framework: eight risks, each with an owner and a dated test

Running is not the same as working

Most registers are built once, for an audit, and then sit. They record that risks exist, not whether anything works against them. A control runs when it happens on schedule: the daily alert, the monthly sample. A control is tested when somebody deliberately feeds it a case it should catch and watches it catch it. Plenty of controls run every week and would miss the one event they exist for.

A control that has never been tested is a hope with a name on it.

A register also starts to go stale the day it is finished. Whoever wrote it, an outside adviser or a tool's setup wizard, the document records the business as it was that week. Every vendor update, new use and departure after that makes it a little less true, and nothing in the document says so. The register is useful only as a routine someone runs every month.

A pattern that turns up often in diligence and operating reviews, offered here as illustrative: the register exists, was built for the audit committee, and has every control column filled. The "last tested" column is blank or missing. Ask for one control to be shown working and the answer is that it has never needed to be.

The eight risks

Risk 7 is the only one that grows as the AI improves. The costly failure with AI in finance is usually the month nobody looked, because the last forty answers were right. Every good month makes the next careless approval more likely.

So approval quality belongs on the register. Approval that is never exercised is theater. The approver has to see the reasoning, the sources and the record of past results, so the request can be judged rather than signed (see how to trust an AI finding). Then measure it: approve, reject and send-back rates, time to approve, approvals later reversed. Zero rejections over a long period is a warning sign.

Scoring

Score likelihood and impact from 1 to 3 and multiply. This scale is one company's own, written for this guide. It is not a standard. Set yours by the amounts that matter in your business.

The product can only be 1, 2, 3, 4, 6 or 9, which gives three bands: 1 to 2 low, 3 to 4 medium, 6 to 9 high. Change a score only when evidence changes (a miss, a failed or passed test, a new use). A score that moves because the room feels differently is not a score.

Step-by-step process

1. List every place AI acts or advises, including informal tools. Owner: CFO. Output: a one-page inventory.
2. Write one row per risk per use. Start from the eight and drop any that truly do not apply. Owner: controller.
3. Name one person per row. The owner answers for the control working, not for the tool. Owner: CFO.
4. Write each control as something that happens on a date. "We review outputs" names no person and no date. "The FP&A lead traces five findings to source on the first Tuesday of each month" names both. Owner: each row owner.
5. Score each row on the written scale. Owner: controller with row owners.
6. Test every high row within 60 days by feeding the control a case it should catch. Record date and result. Owner: row owner.
7. Put the register in the monthly operating review with a fixed 15-minute agenda (see Templates). Owner: CFO.
8. Apply the five-day rule. Any miss gets a new row or an update within five working days: what happened, what the control did, what changes. Owner: the affected row's owner.

Wherever an AI tool proposes an action, a named person approves it before it runs. The register checks whether that approval is still being exercised.

Worked example: an eight-row register at a mid-market distributor

Illustrative. The company, figures and scores are invented to demonstrate the method. They are not benchmarks.

A distributor with about $60 million of revenue uses AI to draft three things: the weekly supplier payment run, which the controller approves; variance findings for the monthly review; and collection emails, which the credit team approves and sends. This is the register after the October review.

Score is L × I. Arithmetic check: 9 + 6 + 6 + 6 + 4 + 3 + 3 + 3 = 40 across eight rows. Four rows are high and reviewed monthly (next: November). Four are medium and reviewed quarterly (next: January). Six of eight controls were tested in the last 12 months, or 75%. The two marked "Never" are this quarter's two tests. Every row has one named owner.

Two rows with numbers behind them

Row 7, scored 9. Last quarter the controller approved 212 drafted payment runs and supplier changes and rejected or sent back none of them. Median time to approve fell from about four minutes to under one. That does not prove any approval was wrong. It shows nothing in the data would tell you if one were. The quarterly known-duplicate invoice, planted in the queue, was caught in September. So the only item sent back all quarter was the one placed there to be sent back. The test passed, and it still tells you less than the 212 approvals around it.

Row 5, scored 3. Usage fees ran at $2,600 a month against a $2,000 budget, 30% over and past the 20% threshold. The bigger number was elsewhere: reviewers logged 14 hours a week checking AI drafts. At an illustrative $75 an hour, that is $1,050 a week, about $4,550 a month (1,050 × 52 ÷ 12), or 1.75 times the usage fees ($4,550 ÷ $2,600). It sat in no budget line.

Check the score against the scale. The October review set impact at 1 from the usage overrun alone: $600 a month, about $7,200 a year, under $10,000. Count the checking hours and the cost is about $54,600 a year ($4,550 × 12), which is impact 2 and a score of 6. The hours log is new evidence, so the change goes to the November review. A cost row scored on the visible fee alone will look low on the register.

The control that was never tested

This is a composite, illustrative pattern. It describes no single company, and is told as the history of the distributor's row 1 to show how that row reached a 6.

When the payment-run drafting went live, the systems lead set up a freshness alert: if the bank feed had not refreshed in two days, an email went out. The first register scored the row 2 for likelihood and 2 for impact, a 4. Last tested: blank. It was an alert. Nobody thought it needed testing.

In August the bank changed how it connected to outside software, and the feed stopped. The alert fired every day, to the mailbox of an analyst who had left in the spring. For nine days the AI drafted payment runs from a balance that no longer existed. Each draft looked like the last, and the controller approved each in under a minute. On the ninth day two large supplier payments took the account overdrawn, the bank charged fees, and one supplier put the account on hold.

Every part of this was recorded. The sync log showed a failure each day. The alert system showed nine alerts sent. The approval record showed nine approvals, each with a name on it. The record was complete, and nothing in it was responsible for what happened next.

The five-day rule ran: found on a Thursday, row updated the following Tuesday, three working days later. The alert now goes to a shared mailbox checked each morning. Every run shows the "as of" date of its balance, and the controller sends back any run where that date is more than one working day old. Each quarter the feed is paused in a test copy to confirm the alert arrives. Likelihood moved from 2 to 3 because it had happened, so the score moved from 4 to 6: a change driven by evidence, the only kind the register should allow.

The uncomfortable part: the control was never missing. It ran every day and sat on the register. Nobody had ever asked it to work.

Templates

Register layout

Write the scale above the table and sort by score. Review 6 and 9 monthly, 3 and 4 quarterly, 1 and 2 twice a year.

Miss log

Monthly review agenda (15 minutes, inside the operating review)

Attends: CFO (chair), controller, FP&A lead, IT or systems lead, and the owner of any row scored 6 or 9.

Brought: the register with changes marked; the miss log; the approval-quality report (approve, reject and send-back rates, median time to approve, approvals later reversed); usage spend against budget and checking hours; any vendor change notices.

A row that needs longer gets its own meeting that week. The agenda fits the monthly meeting in the operating review system.

Metrics and KPIs for the risk register

The first metric matters most. A register full of blank test dates is a list of intentions.

Common mistakes

Building it for the audit committee. Your annual risk spreadsheet records what you worried about last year. It cannot catch a feed that broke in August. A yearly review hears about an August failure months after the business has paid for it. Move it into the monthly meeting.

Naming a team as owner. "Finance" owns nothing. One person answers for each control.

Treating "it runs" as "it works". The alert in the example ran every day for nine days.

Reading zero rejections as success. It may mean the AI is excellent, or that nobody is reading. The quarterly known-wrong item tells you which.

Leaving checking time out of the cost. Usage fees are the visible part. Checking hours are often larger, and appear nowhere unless logged.

AI prompt assistance

AI is a drafting and checking aid here. It should not score your risks or choose your controls. Do not paste confidential data into a tool your company has not approved.

1. Draft rows from an inventory.

Here is a list of the places AI drafts, proposes or takes actions in our finance and operations work, with what each reads and produces. For each, draft register rows for: stale or wrong source record, wrong cause stated confidently, action outside authority, vendor or model change, cost drift, data exposure, people stop checking, one person understands the setup. Give how each would show up and the early signal. Leave owner, scores and control blank.

Check: each process owner deletes any row that does not match how the work is actually done.

2. Turn vague controls into scheduled ones.

Here are the controls in our register. For each, say whether it names a person, a frequency and a specific action. Rewrite any that do not in the form "[person] does [check] on [schedule]". Do not add controls.

Check: each row owner confirms they will actually do the rewritten control on that date.

3. Summarize approval quality.

Here is an export of AI proposals for three months with approver, decision (approve, reject, send back), time to decide and whether the approval was later reversed. By approver, compute each rate, median time to decide and reversals. Flag any approver with no rejections or send-backs. Show the calculations.

Check: recompute one approver's figures by hand before the review.

Implementation guide

Expect at least one control to fail its first test. Better then than on the day it is needed.

Governance: the CFO owns the register and chairs the review. Each row owner answers for their control and keeps its test date current. Approvers of AI-proposed actions stay named on every approval, and their approval-quality numbers are read monthly. Limits are set in the decision rights matrix template.

Downloadable assets

The register layout, miss log and monthly review agenda above are designed to be copied into a spreadsheet or shared document. No calculator exists for this topic.

Related resources

• AI trust and governance hub: every page on trusting AI that acts in finance and operations.
• AI governance for finance and operations: the policy the register sits under.
• Decision rights for AI actions: the limits risk 3 checks against.
• How to trust an AI finding: what an approver should see before saying yes.
• Your first AI pilot in finance: where to start the register.
• Operating review system: the meeting the 15-minute review fits inside.
• SaaS vendor renewal calendar: vendor terms and changes on a schedule.

Frequently asked questions

What is an AI risk register?

A list of the ways AI in your business could cause harm, one row per risk. Each row has a named owner, a scheduled control, a score and the date the control was last tested.

What risks should an AI risk register include for finance teams?

Start with the eight in the framework table, from stale source records to a setup only one person understands. Add anything specific to how you use AI, and drop rows that truly do not apply.

How often should an AI risk register be reviewed?

Monthly, for 15 minutes inside the operating review, with high rows discussed every month and medium rows quarterly. Test two controls a quarter. After any miss, add or update a row within five working days.

How do you score AI risks?

Score likelihood and impact from 1 to 3 on a scale your company writes down, then multiply. The scale here is one company's own, not a standard. Change a score only when evidence changes, and record the evidence beside it.

Does a risk register replace human approval of AI actions?

No. Wherever AI proposes an action, a named person approves it before it runs. The register checks that the approval is real, using rejection and send-back rates.

How this works in a System of Performance

A register is only as current as the evidence that reaches it, and that evidence (source dates, approval rates, test results, misses) usually sits in separate systems and arrives at the review by hand. 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 numbers stand first, bring it to us as a launch partner.