Governance, audit & compliance

AI governance for finance — from policy to working practice

Why finance teams need their own AI policy, what it should contain, and how to design governance that fits the close cycle, audit requirements, and a four-eyes culture.

7 min
  • governance
  • policy
  • compliance
  • finance

AI governance for finance is the set of rules, roles, and controls through which a finance team decides which AI applications run where, who owns them, and how actions stay traceable. Unlike a general IT policy, it must align with the close cycle, audit requirements, and the four-eyes principle — not overwriting IT policy, but building a finance layer on top.

A finance team is different. Not because the people are different, but because the data is. A marketing employee pasting a draft post into a free ChatGPT account causes, at worst, reputational damage. A controller pasting a "supposedly anonymized" ledger — with customer names, IBANs, and revenue per debtor — breaches confidentiality clauses in virtually every customer contract, likely leaks personal data, and exposes their employer to a 72-hour GDPR notification obligation. Same paste window, different world.

AI governance for finance is not about "is this OK with legal." It's about which finance data, in which tools, by which role can be used — and how to make that visible without slowing adoption. Getting that answer onto one page is half the work.

Why finance teams need their own framework

In most SMEs and scale-ups, the general AI policy is about tools, data types, and privacy. Those frameworks don't fit finance one-to-one, for three reasons.

Data sensitivity is high by definition. Almost every file a controller handles contains personal data (employees), commercially sensitive information (customer revenue, margins, salaries), or third-party data under NDA (supplier prices, contracts). For most other teams, "confidential" is the exception; for finance, it's the norm.

The ledger is legal truth. Unlike a marketing plan or a process memo, a journal entry has legal and tax force. An AI that writes a ledger entry is simultaneously writing into something the tax authority and external auditor can review. The question "who entered this" is not a process question but an audit question.

The culture is precision and four-eyes. Finance teams are trained on double-checks, authorization matrices, and periodic controls. An AI policy that ignores this — "anyone can do anything, just be careful" — doesn't fit how the team already works. Governance lands much better when it follows the same template the team already knows for payments and bookings.

Almost every mid-sized finance team by now has some form of shadow AI: a controller analyzing an Excel extract in a private Claude account, an AP clerk pasting an AP aging into free ChatGPT, a CFO running draft board decks through a personal Copilot subscription. The answer is not to block — that only moves the use onto personal phones. The answer is a limited, explicit set of approved tools, paired with an agreement on which finance data goes into which tool.

Four parts of a workable framework

A finance policy fits on one or two pages. Four questions need clear answers.

1. Data classification, finance-tuned

The generic four-tier classification works, provided you sharpen it for finance:

  • Tier 1 — public: published annual figures, press releases, public prospectuses. Allowed in any AI tool.
  • Tier 2 — internal: internal KPIs, aggregated management reports without customer names, process documentation. Only in approved enterprise tools.
  • Tier 3 — confidential: ledger extracts, open-items lists with customer or supplier names, salary data, forecast scenarios, draft board packs. Only in enterprise tools with a DPA, anonymized where possible.
  • Tier 4 — restricted: payment files (IBANs, mandates), salary records at person level, M&A documentation under NDA, files in active litigation. No AI, or only in a customer-owned environment with explicit written approval.

Two extra rules often forgotten in finance:

  • Anonymized isn't always anonymized. A ledger where you replace customer names with "customer_001" looks anonymized to an outsider, but for your bookkeeper it's directly traceable via invoice number or amount. Treat it as Tier 3.
  • Aggregation level counts. Total revenue per month is Tier 2; the same revenue broken down per customer is Tier 3; add IBAN and it's Tier 4.

2. Approved tools per role

A short list of allowed tools, each with its tier ceiling. An example that works in SME finance:

  • Microsoft 365 Copilot — Tier 1-3, provided Flex Routing is turned off (see below). Closest to where the team already works: Excel, Outlook, SharePoint.
  • Claude Pro or Team — Tier 1-3, ISO 27001 + ISO 42001 certified, DPA on request. Strong option for analyses and draft commentary.
  • ChatGPT Business — Tier 1-3, EU data residency since January 2026. Suitable for general research.
  • Saldus.ai — Tier 1-4 inside a customer-owned environment, because context stays inside your infrastructure and your own model choice. Specifically for finance workflows on the accounting system.
  • Free ChatGPT, Claude, Gemini, Grok — Tier 1 only. Grok in 2026 isn't defensible for business use because of ongoing GDPR/DSA investigations.
  • Fireflies.ai — Tier 1-2 for internal meetings. Not for calls where customer or HR matters are discussed by name.

A watchpoint since April 2026: Microsoft Copilot has Flex Routing on by default. Queries get routed to US servers as soon as EU capacity is saturated. For Tier 3 finance data, an administrator has to switch this off explicitly. If not, your tool effectively runs on US infrastructure without anyone noticing.

3. Rights per role — finance edition

Not everyone in finance has the same rights on the accounting system, and that should hold for AI too:

  • AP and AR clerks: chat access on Tier 1-2; for Tier 3 only on data within their own responsibility (own open-items list, own mail folder).
  • Controller: chat access on Tier 1-3. Read-only connectors to the accounting system and MS365. No write rights on the ledger without an approval layer.
  • Finance manager / CFO: all tiers within approved tools. Authority to authorize exceptions (Tier 4 occasionally in a segregated environment).
  • External auditor or audit party: gets no direct AI access to your data — they work on exports you provide, with the same NDA and retention terms as other documentation.

This follows the same template as your authorization matrix for payments. Not a coincidence — it's exactly why finance teams often adopt governance faster than other departments, provided it's framed in familiar language.

4. Audit layer and incident procedure

Two rules are enough:

  • Anything above Tier 1 uses audit logging — every enterprise tool supports it; it just has to be switched on and reviewed periodically (quarterly).
  • On any suspicion that finance data has leaked via an AI tool: notification within 24 hours to the GDPR officer and the CFO. On suspicion of customer IBANs or salary data: also bring in the DPO for the 72-hour notification to the data protection authority.

Audit grade — what this means for traceability

The step that sets finance governance apart from general AI governance: every AI action on finance data must be reconstructable down to the auditor's level. In practice this means three things.

A timestamp, a user, and an input snapshot per AI interaction that touches the ledger. Not just "Claude proposed a journal entry on 19 May," but: which version of the ledger was input, what was asked, which model answered, and which answer was approved by whom. Without that chain, an external auditor can't establish whether a journal entry is correct — and in audit context "not establishable" effectively means "not acceptable."

Four-eyes on write actions. An AI can prepare a booking, a payment, or external communication, but the second pair of eyes stays human. This doesn't have to slow adoption — if the AI has already done 80% of the work, the human approval costs a fraction of what the whole action used to.

Log immutability. An audit trail that the user can amend or delete is not an audit trail. Pick tools where the log is kept by the vendor (or in your own infrastructure, append-only), not by the individual employee.

How to land this in finance without slowing adoption

The fastest route is to let the CFO or finance manager hold the pen — not IT, not legal. From a business angle: what do we have to be able to do to run a better close faster, and what risks are acceptable in doing so? That first version then goes to IT and legal for review. Instead of a policy that blocks everything out of caution, you get one that enables the work and is later sharpened on real risks.

Invest half an hour of training per finance staff member at rollout. Not "what is AI," but: these are our three approved tools, this is allowed and this isn't, this is what you do if you accidentally paste something into the wrong tool. A policy without training is dead letter within three months.

Name one policy owner (typically the CFO or a designated AI champion in finance) who reviews the tool list, tier classification, and role allocation every quarter. Models, prices, and terms change every few months — a static policy is outdated within a year.

Saldus in practice

In Saldus several of these governance questions are built in by design rather than left to the user: role allocation per agent, audit logging on every tool call, a policy layer that routes write actions to an approval inbox by default, and a per-agent choice of which model is used (Claude, GPT, Gemini, or a local model for the most sensitive data). The platform doesn't replace the policy — you write that with your team — but it makes the framework visible in the software rather than in a Word document on SharePoint.

Further reading

GDPR-compliant processor
Audit-grade logging
Pen-tested platform