AI Governance for Finance Functions: A Practical Framework
AI governance for finance: define access, review, and agent authority with a practical delegation matrix and evidence of control.
Maebh Collins FCA10 min read
Published 26 January 2026 · Updated 1 October 2026
AI governance in finance needs to show who authorised a tool, what it may do, and how the team checks the result. Define that evidence before the workflow becomes part of the close or payment process. This framework sits within the wider AI in finance strategy.
What AI governance in finance actually means
AI governance is not a policy document. A policy document is a component of governance, but governance is broader and more operational than that.
AI governance in a finance context is a set of decisions, documented and maintained, covering: who can use what AI tools on what data; what level of human review is required before an AI recommendation becomes a decision; how errors in AI outputs are caught, corrected, and documented; who is accountable when an AI-assisted process produces a wrong outcome; and how you demonstrate to auditors that your AI-assisted processes are controlled.
The last point is increasingly practical rather than theoretical. External auditors are already asking about AI-assisted finance processes in their risk assessments. ISA 315, the international auditing standard on risk assessment, requires auditors to understand the entity’s use of technology in financial reporting. That includes AI tools that influence posting decisions, approval workflows, or reconciliation outputs. The significance of any control gap depends on the process, risks, and evidence the auditor assesses.
The governance framework does not need to be elaborate to be functional. It needs to answer specific questions clearly.
The four governance decisions every finance function needs to make
Before deploying any AI tool that touches financial data or processes, four governance decisions need to be made explicitly, documented, and communicated to the team.
Decision one: data access controls.
What financial data can the AI tool access? Who authorised that access and on what basis?
This matters because AI tools often request broader data access than their specific function requires. An invoice processing tool that requests read access to your entire ERP database rather than the AP module. A forecasting tool that wants access to payroll data to improve its model when payroll data was never part of the approved scope.
The principle is least-privilege access: the AI tool should have access to the minimum data required to perform its function. Define that scope in writing before you connect the tool to your systems. Review it at each renewal.
This is also where you document your data residency and processing decisions. Where is the vendor processing your financial data? What contractual protections govern that? What happens to your data if you terminate the contract? These are procurement and legal questions, but they are governance questions too. Finance data is sensitive. The governance around it should reflect that.
Decision two: human review thresholds.
At what value, exception type, or confidence score does human sign-off become mandatory, regardless of what the AI recommends?
Available controls depend on the product and configuration. Where a confidence score influences approval, establish what it measures and whether testing supports that use. Set review requirements for material amounts and defined exceptions, then test whether the system enforces them.
The specific thresholds matter less than the fact that they exist and are explicitly decided rather than defaulted. Vendor defaults are set for general applicability. Your thresholds should reflect your specific risk appetite, your transaction mix, and your regulatory environment.
Write down the thresholds. Review them quarterly in the first year as you understand the error distribution in your environment. A threshold that was appropriate at go-live may need adjustment once you have three months of production data on where the AI is making errors.
Decision three: error correction processes.
When the AI is wrong, what is the documented workflow for correction, and is it auditable?
This is the governance question that most implementations fail to answer adequately. The system goes live and the question of what happens when it makes a mistake is treated as something to handle at the time. The result is an ad hoc, inconsistent, undocumented correction process.
An error correction process needs four elements: a mechanism for identifying the error; a defined escalation path to the person with authority to correct it; a documented correction workflow with mandatory fields capturing what went wrong, why, and what action was taken; and a feedback loop to the AI tool or the team responsible for it so that recurring errors are addressed at source rather than corrected repeatedly.
The agentic AI governance post covers error correction in the higher-stakes context of AI that takes direct actions. The same principles apply to recommendation AI, with somewhat less urgency around the speed of the correction workflow.
Decision four: model change management.
When the vendor updates the model, what is your validation process?
This is a governance gap that is near-universal. Finance teams deploy an AI tool, validate it thoroughly at go-live, and then accept ongoing model updates from the vendor without any re-validation. A model update that changes how the tool handles a specific exception type, or that updates its training data, can materially change the tool’s behaviour in your environment without any signal that something has changed.
The minimum requirement is three things: a contractual notification obligation from the vendor when significant model changes are deployed; a defined validation run against a test dataset before the update goes to production; and a rollback procedure if the updated model produces worse outcomes in your environment.
For most AI tools in a finance context, a monthly validation run against 100 manually-reviewed transactions takes a few hours and catches most model drift issues. This is not onerous. It is the equivalent of monthly reconciliation discipline applied to your AI tools.
Give each agent a defined authority
September’s announcements make the boundary between assistance and execution more concrete. Oracle describes Fusion Claw as operating within permissions, approval requirements, and delegated authority, with a record of each outcome. Payhawk’s Playbooks act through a connection that applies the user’s permissions. These are vendor descriptions of mechanisms, not independent evidence that a customer’s controls operate effectively.
For a finance team, I would translate the proposed workflow into a delegation matrix. The example below is illustrative. Its limits need to be agreed for the actual system, transaction types, and risk appetite.
| Action | Proposed agent authority | Accountable owner | Evidence retained |
|---|---|---|---|
| Read | Access the approved entity and datasets | Data owner | Access scope and relevant activity record |
| Prepare | Draft an entry from permitted evidence | Financial controller | Source references, calculation, and draft |
| Post | Post only within the approved workflow after required review | Financial controller | Entry ID, review, and action identity |
| Approve | Escalate to the designated authorised person | Named approver | Decision and identity |
| Pay | Prepare a proposal; hold release for the agreed payment controls | Treasury or authorised payment owner | Verification, approvals, and payment reference |
Permissions should enforce these boundaries. A sentence in a prompt asking an agent to respect the policy is insufficient evidence that it cannot exceed its authority. Test the behaviour with the actual identities and supported interfaces.
For example, ask a user without posting permission to request a journal posting through the conversational interface. Establish whether the action is prevented or held for the required approval. Repeat through the ordinary interface and retain both results.
Then test a proposed payment that lacks a required approval. The expected result should follow the agreed control design. A confident explanation from the agent does not substitute for the missing approval.
Check what the record attributes to the person and to the agent or service account. The reviewer needs to establish who requested an action, which authority permitted it, and what actually happened. Where the product cannot provide that evidence, record the limitation before approving the workflow.
The finance configuration acceptance checks show how to turn these permissions into transaction tests. Use the same matrix when a connection, model, or workflow changes. A new capability should receive a new authority decision where needed. The previously accepted scope should not expand simply because the tool can now perform another action.
What you actually need to build
Governance does not need to be bureaucratic to be effective. The finance functions I have seen implement AI governance well do it with a small set of practical documents, consistently maintained.
A one-page AI use policy for the finance function. This covers: what AI tools the function uses; what those tools are authorised to do; what they are not authorised to do; and who to contact if there is a concern about an AI output. One page, readable in three minutes. Updated when tools are added or changed.
A data access register for AI tools. A simple register documenting every AI tool that has access to financial systems or data: what data it can access, when that access was authorised, who authorised it, and when the authorisation should be reviewed. This register is the answer to the auditor’s question about your AI data controls. It does not need to be more than a well-maintained spreadsheet.
A defined escalation path for AI errors. When someone on the finance team identifies a likely AI error, who do they tell? How is it logged? Who has the authority to make the correction? How is the correction documented? A simple escalation flowchart, circulated to the team and posted in your finance function’s shared workspace, serves this purpose.
These three documents constitute a functional AI governance framework. Their scope and supporting evidence need to reflect the actual finance processes and risks.
UK and EU regulation now take different routes
For UK-regulated financial firms, the FCA has confirmed that it does not plan to introduce a separate AI rulebook. Its June 2026 position relies on existing frameworks including Consumer Duty, the Senior Managers and Certification Regime, and established governance and control expectations.
That does not mean AI is unregulated in the UK. It means the question is framed through existing accountability. Which senior manager owns the outcome? How does the use meet Consumer Duty? What controls demonstrate that the firm understood and managed the risk?
The EU route is more prescriptive for defined high-risk systems. The European Commission confirms that the AI Omnibus entered into force on 27 July 2026, moving Annex III obligations to 2 December 2027. Most general finance uses still sit outside Annex III, but Article 4 literacy, general-purpose model rules and existing GDPR, DORA and sector obligations remain relevant. The current position is set out in EU AI Act Annex III for finance teams.
An Irish group with UK operations may therefore need one governance system that produces evidence for two regulatory styles. The practical control set is still recognisable: named ownership, authorised use, data controls, documented review, incident handling and monitoring. Build that evidence once, then map it to the applicable rulebook in each jurisdiction.
The audit conversation
Keep the authority matrix, access register, review evidence, and error records available for the audit team. These records support an explanation of the processes in use; their adequacy depends on the actual risks and controls. A policy alone does not demonstrate that a control operated.
The FRC’s 2026 research on AI in corporate reporting also makes reviewer accountability relevant to external reporting. Connect each material output to its evidence and the person who approved it. The audit management article explains the wider preparation discipline.
Start with one AI-assisted workflow and demonstrate its permissions, review, and correction process. Then use the findings to improve the framework. If you need senior finance leadership to build that evidence into everyday operations, get in touch.
Maebh Collins is a Fellow Chartered Accountant (FCA, ICAEW) with Big 4 training and twenty years of operational experience as a founder and senior finance leader. She writes about AI in finance transformation from the inside out.