The audit committee pack for September has a new item. The chair has asked what AI tools the finance team uses, what data goes into them, and who checks what comes out. The controller knows the answers for her own team. She is less sure about FP&A, and has no idea what the shared service centre started using in the spring.
A finance AI use policy is how those questions get one answer instead of several. It does not need to be long. It does need to exist, be specific to finance, and be kept current. This guide covers what to put in it, section by section.
Why finance needs its own AI use policy
Many companies already have a general acceptable use policy for AI, usually written by IT or legal. It is a good start, and it rarely goes far enough for finance, for three reasons.
Finance data is different. Bank details, payroll, tax identifiers, unreleased results and, for listed companies, inside information. A general policy tends to treat all confidential data alike. Finance needs finer distinctions.
Finance outputs are different. A journal, a payment, a disclosure, a reconciliation sign-off. These change records or leave the company, and they sit inside controls that auditors test.
Finance runs the controls. Segregation of duties, approval limits and review evidence already exist in finance. An AI policy for finance should plug into them rather than sit beside them.
The practical answer is a finance annex to the company policy, or a standalone finance policy that references it. Either works. What matters is that the rules for finance data and finance outputs are written down and owned.
What to put in an AI use policy: a template outline
The outline below covers what most finance functions need. Adjust the depth to the size of the team and the reach of the tools.
| Section | What it should say | Owner |
|---|---|---|
| 1. Purpose and scope | Which teams, entities and contractors are covered, and that it applies to any AI tool used for finance work, approved or not | CFO |
| 2. Roles | Who owns the policy, who approves new tools, who maintains the tool list, who handles incidents | CFO, with IT security |
| 3. Approved tools | Reference to a maintained list of tools, versions and the data classes each is approved for | Finance systems lead |
| 4. Data classes | How finance data is classified and which class may go into which tool | Controller, with IT security |
| 5. Permitted uses | The tasks AI may help with, by role, with examples | Function heads |
| 6. Prohibited uses | What AI may not do or be used for in finance | CFO |
| 7. Review requirements | Which outputs need human review, by whom, against what, before use | Controller |
| 8. Record keeping | What is logged and retained, where, and for how long | Controller |
| 9. Incidents | What counts as an incident, who to tell, how fast, and what happens next | CFO, with IT security |
| 10. Training | What people must complete before using approved tools, and refreshers | Finance operations lead |
| 11. Exceptions and review | How to request an exception, and when the policy itself is reviewed | CFO |
Sections 3 and 4 do most of the work, and both change often. Keep the tool list and the data class table as appendices, maintained by their owners, so the body of the policy can stay stable for a year.
Data classes: the section that does most of the work
People rarely misuse AI on purpose. They put the wrong data into the wrong tool because nobody told them where the line was. A simple table answers that question in advance.
| Data class | Finance examples | Public or consumer AI tools | Company-approved general assistant | Approved finance tool with system controls |
|---|---|---|---|---|
| Public | Published accounts, press releases, public regulations | Allowed | Allowed | Allowed |
| Internal | Process notes, policy manuals, chart of accounts, templates | Not allowed | Allowed | Allowed |
| Confidential | Management accounts, forecasts, customer and vendor lists, contracts | Not allowed | Allowed if the tool is approved for confidential data | Allowed |
| Restricted | Bank details, payroll, tax identifiers, unreleased results, inside information | Not allowed | Not allowed unless specifically approved | Allowed only where approved, with logging |
The labels will differ from company to company, and should match whatever classification IT already uses. The finance-specific part is the examples column. Writing "payroll" and "unreleased results" into the table removes most of the guesswork.
Permitted and prohibited uses
Permitted uses are best written by role, with examples. For accounts payable: suggesting invoice coding for review, drafting replies to vendor queries, summarising exception queues. For FP&A: drafting first-pass variance commentary from the ledger, summarising board pack changes. Examples teach people more than principles do. An earlier issue covers ranking AI use cases by volume, rules and risk.
Prohibited uses should be few and clear. A typical finance list:
Review requirements and record keeping
Review by output type. Not every AI output needs the same scrutiny. A draft internal email needs the sender to read it. A reconciliation conclusion needs the usual reviewer, who knows it was AI-assisted. Anything that changes a record, leaves finance or feeds external reporting needs a named reviewer, a check against source and a recorded approval. Write those three tiers into the policy so people do not have to judge each case.
Record what an auditor would ask for. For AI-assisted steps inside a financial process, keep the input or a reference to it, the output, the tool and version used, the reviewer and the decision. Retain these on the same schedule as the financial records they support. AI Guardrails for Finance Data: Access, Logging and Human Sign-Off covers logging in more detail.
Keep a register. A simple list of every finance process step where AI is used, the tool, the owner and the related control. It takes an afternoon to start, and it answers the audit committee's question directly.
Incidents and training
Define an incident broadly. Restricted data put into the wrong tool. An AI-assisted output with an error that reached someone outside finance. A tool behaving unexpectedly after an update. A suspected attempt to manipulate a tool through a document. People should report all of these, without blame for honest mistakes, to a named contact within a set time, such as one business day.
Say what happens next. Contain it, assess whether data protection, contractual or disclosure obligations are triggered, fix the cause and record the outcome. Data protection notification deadlines can be short, so the policy should route incidents involving personal data to whoever handles privacy, straight away.
Training before access. Anyone using an approved tool for finance work should first complete short training on the policy, the data classes and how to review output. This is good practice anywhere. For organizations within the EU AI Act's scope, an AI literacy obligation has applied since 2 February 2025.
The standards and rules to align with
ISO/IEC 42001:2023. Published in December 2023, it sets requirements for an artificial intelligence management system: policy, roles, risk assessment, controls and continual improvement, in the familiar structure of other ISO management system standards. Most finance functions will not seek certification. The standard is still a useful reference for structure, and an AI use policy is one of the elements it expects. If your company is pursuing certification, align the finance policy with the company AI policy from the start.
The EU AI Act. Regulation (EU) 2024/1689 entered into force on 1 August 2024. The prohibitions and the AI literacy obligation have applied since 2 February 2025, and the governance rules and obligations for general-purpose AI models since 2 August 2025. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, moved the dates for high-risk systems. Obligations now apply from 2 December 2027 for high-risk systems under Article 6(2) and Annex III, and from 2 August 2028 for those under Article 6(1) and Annex I.
Most finance uses of AI, such as coding suggestions, reconciliation matching and commentary drafts, are unlikely to fall in the high-risk categories. Some uses close to finance can, including assessing the creditworthiness of individuals and certain employment decisions. Whether any of your uses are in scope is a question for counsel, and the policy should route it there rather than answer it.
The NIST AI Risk Management Framework. For US companies in particular, NIST's voluntary framework of January 2023 and its Generative AI Profile of July 2024 offer a structure many risk teams already know. The guardrails piece in this series maps finance controls to it.
Keeping the policy current
Review on a schedule and on events. Twice a year is reasonable while tools are changing quickly. Review sooner when a new tool is approved, a significant incident occurs, the law changes or the auditors raise a point.
Keep the appendices live. The tool list and the data class table should change whenever reality does. A policy whose tool list is six months out of date tells people the rules are optional.
Check use against the policy. Once a quarter, compare the register, the approved tools and what people actually use. Gaps usually point to a missing approved tool rather than bad behavior.
What an AI use policy will not do
It will not make anyone follow it. A policy works when the approved route is the easiest one: an approved tool that does the job, clear examples and a quick answer when someone asks whether something is allowed. If the approved tools are poor, people will use others and stop mentioning it.
It will not substitute for controls in the systems. A rule saying restricted data must not go into an unapproved tool helps, and a technical block helps more. Where the systems can enforce a rule, let them, and use the policy for the judgments they cannot make.
Frequently asked questions
What is an AI use policy for finance?
An AI use policy for finance is a short written set of rules covering which AI tools the finance team may use, with which data, for which tasks, what review is required, and what records are kept. It usually sits as an annex to, or alongside, the company's general AI policy.
What should an AI use policy include?
It should include scope, roles, approved tools, data classes, permitted and prohibited uses, review requirements, record keeping, incident handling, training and a process for exceptions and updates. The tool list and data class table work best as appendices that change more often than the policy.
Does the EU AI Act apply to finance teams using AI?
It can, depending on where the company operates and how AI is used, so check scope with counsel. The AI literacy obligation has applied since 2 February 2025. After the Digital Omnibus, high-risk obligations apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems.
Do we need ISO/IEC 42001 certification?
Most finance functions do not need certification, though the standard is a useful reference for how to structure AI policy, roles, risk assessment and review. Certification is a company-level decision, usually driven by customers or regulators.
Who should own the AI use policy in finance?
The CFO should own the finance AI use policy, with IT security, legal and the controller contributing to the sections they know best. The tool list and data class table each need a named owner who keeps them current.
How often should an AI use policy be reviewed?
Review it twice a year while tools are changing quickly, and sooner when a new tool is approved, an incident occurs, the law changes or the auditors raise a point.
Where CFOLogic fits
We help CFOs set the guardrails around AI adoption in finance, including the finance AI use policy, the data classes and the review steps, as part of a wider adoption approach. The tools we design run read-only on top of existing systems, and anything that leaves the team is approved by a person. We do not give legal advice, and questions of legal scope go to your counsel. Our CFO Success Partners page covers the engagement model.