Finance runs on controls, and AI doesn't get an exemption. The good news: AI risk in finance workflows is ordinary operational risk, and the discipline you already apply to people and spreadsheets extends naturally. The bad news: the default way teams adopt AI — an individual pasting data into a chat window — bypasses every control you have. This guide covers the control design that closes that gap.
Design the review, don't assume it
The central control decision for any AI workflow is what a human reviews, and when. Three workable designs:
Review everything (human-in-the-loop). Every AI output is checked before it takes effect. Right for: high-materiality outputs (journal entries, external communications), new deployments, and generate/synthesize work where errors are fluent and invisible. Note the honest accounting: you haven't removed labor, you've converted doing into reviewing. That's usually still a large win — reviewing an extracted invoice is much faster than keying one — but it belongs in your cost-per-outcome math.
Review by exception (confidence routing). Outputs meeting mechanical checks flow through; the rest route to a person. Right for: extract and classify at volume, once you have measured failure patterns. The routing rule must be mechanical (validation failures, amount thresholds, vendor-not-found), not the model's self-reported confidence, which is not a reliable control.
Review by sample. A fixed percentage re-checked, with a trigger to escalate to full review if the sample fails. Right for: mature, stable workflows with recoverable errors. This is the same logic as any monitoring control — but it only works if someone actually reviews the sample and the escalation trigger is written down.
Set review thresholds by materiality, exactly as you would for manual work: a $50 expense classification and a $5M accrual do not deserve the same scrutiny, whether a person or a model produced them.
Keep the audit trail the system creates for you
An AI workflow can be more auditable than a manual one — every input, instruction, output, and timestamp can be logged, which is more than you can say for a judgment call made in someone's head. But only if you keep it:
- Log the full exchange — input, the instructions/prompt used, model and version, output, cost, timestamp — for every production call, retained on your normal document-retention schedule.
- Record who reviewed what. If review-by-exception, log which rule routed each item. Your auditors will ask how you know the control operated; this is the answer.
- Pin versions. Model providers update models; behavior shifts. Production workflows should name a pinned model version, and a version change should go through change management like any system change — with a regression run against your test set (the one you built in the pilot playbook) before and after.
This is also the standard we hold ourselves to: every benchmark number we publish ships with its raw logs, prompts, and pinned model versions. Ask the same of any vendor's claimed accuracy.
Segregation of duties still applies
Map AI into your existing SoD matrix as if it were a (very fast) staff member:
- An AI that prepares may not also approve. If a model proposes journal entries, a person with approval authority posts them — no auto-posting paths that bypass the approval workflow.
- No new access paths. The AI integration should touch systems through accounts with the same least-privilege discipline as human users, and its credentials shouldn't be shared with the team operating it.
- Watch for control collapse in agentic tools. An "agent" that reads the inbox, codes the invoice, posts it, and emails the vendor has just merged four roles into one credential. Each step that would require a distinct human role needs a checkpoint or a distinct authorization.
Data handling: decide before the first paste
Vendor invoices, employee data, and unreleased financials are exactly the data your policies restrict — and a chat window is an external transfer like any other. Before deployment (not after), settle three things with the provider's actual terms in hand: training use (business agreements should exclude your data from model training — verify, don't assume), retention and residency (where prompts/outputs are stored, for how long, and deletion terms), and scope (which data classes may enter the workflow at all — many teams start with vendor-facing documents and hold back payroll and M&A entirely).
Then give people a sanctioned path. Shadow AI use is the predictable result of a ban plus a useful tool; an approved workflow with logging beats an invisible one without it, every time.
Change management and the failure drill
Two final pieces that separate a controlled deployment from a lucky one:
Treat prompt and model changes like code changes. The instructions driving a production AI workflow are configuration with financial impact. Version them, review changes, and re-run the regression set on every change — model upgrade, prompt edit, or vendor switch.
Rehearse the failure. Decide in advance: if error rates spike (the sample control catches it), what's the fallback — pause and queue for humans? Who decides, and how fast can the manual process absorb the volume? An AI workflow without a manual fallback isn't an automation, it's a dependency.
None of this is exotic. It's the same control philosophy your function already runs — applied to a new, fast, occasionally wrong worker. Teams that treat it that way pass their audits and keep their savings; teams that don't usually meet their first AI control finding within the year.