AI governance in finance: controls, GDPR, EU AI Act

What AI governance in finance means

AI governance in finance is the set of policies, controls and records that decide which AI tools a finance team may use, on which data, for which tasks, and who reviews and approves what the AI prepares. It matters because AI output flows into the ledger, tax returns and reports, and the people who sign them remain accountable for them.

Governance does not need a new bureaucracy. Most of it extends controls a finance team already has: authorisation limits, segregation of duties, period locks, reconciliations and an audit trail. What AI adds is a new kind of preparer that is fast, tireless and occasionally wrong with confidence, plus two bodies of law that apply to it in Europe: the GDPR for personal data and the EU AI Act for AI systems.

This guide sets out a practical framework: a use policy, controls over AI-prepared entries, segregation of duties and logging, a worked review, then GDPR, the EU AI Act with its dates as of September 2026, and Canada's position. It is general information, not legal advice.

An AI use policy for the finance team

A useful policy fits on two pages and answers the questions staff actually ask: can I use this tool, can I paste this file, and who has to check the result. It should name an owner, usually the finance director or controller, and be reviewed at least once a year and whenever a new tool or use case is added.

• Inventory: every AI tool and automation in use, its owner, the processes it touches and the data it receives.
• Approved tools and plans: business plans or API access with processor terms, never personal accounts for company or client data.
• Data classes: what may be shared freely, what only after pseudonymisation, and what never, such as credentials and bank passwords.
• Permitted uses by mode: Read for answers and flags, Draft for entries that wait for approval, Auto only for low-risk reminders, reports and flags.
• Review and approval: who checks each type of AI output, against what, and up to which value.
• Records: what is logged for each AI action and how long it is kept.
• Incidents: how errors, data leaks and suspected prompt injection are reported and fixed.
• Training: the AI literacy measures for everyone who uses or supervises the tools.

Controls over AI-prepared entries

Treat every AI-prepared entry as prepared work that needs a named approver. The control environment then looks familiar: the AI is a preparer, a person is the approver, and the ledger records both. The controls below are the minimum for a team that lets AI draft journals, bills or bank matches.

Change management matters as much as review. A prompt, a matching rule or a model version is, in effect, an accounting procedure: when it changes, the output changes. Treat such changes like changes to posting rules, with approval, testing and a record.

• Identity: AI-prepared entries carry their own user or tag, so they can be filtered, reviewed and sampled separately.
• Thresholds: drafts above a value limit, or touching suspense, equity, intercompany or tax accounts, go to a senior reviewer.
• Least privilege: tools can read what the task needs and draft; no tool can post, pay or change master data without a person approving.
• Master data: supplier bank-detail changes proposed from a document are never applied automatically and are verified by phone on a number already on file.
• Testing: a set of past cases with known answers is rerun whenever a prompt, a rule or a model changes, and the results are kept.
• Period control: closed periods stay closed to AI exactly as to people.
• Monitoring: the controller reviews a monthly report of AI drafts, rejections and corrections after posting.

Segregation of duties when AI is in the workflow

Classic segregation of duties separates authorising, recording, custody and reconciliation. AI adds a fifth role: configuring the automation. The person who writes the prompt or the matching rules should not be the only person who approves the entries it prepares, because whoever controls the rules controls the output. The same logic makes an assistant's service account a user that needs its own access review.

In a small team one person often holds several roles. Then compensating controls carry the weight: the owner or an external accountant reviews the monthly report of AI-prepared entries, the changes to automation rules and a handful of entries traced back to source documents.

• Automation owner: configures prompts, rules and account mappings; cannot approve entries from the same automation.
• AI preparer: drafts entries and matches under its own identity; cannot post or pay.
• Reviewer and approver: checks drafts against source documents and policy, approves or rejects, and records why.
• Controller: monitors rejection rates and corrections, approves changes to automations and signs off the close.
• IT or system administrator: manages access and tokens; does not approve accounting entries.

Logging and evidence

If an AI action is not logged, it cannot be reviewed, audited or defended. The log should allow someone to reconstruct what the AI saw, what it proposed, which version produced it and what a person decided. National bookkeeping rules point the same way; Germany's GoBD principles, for example, expect records to be traceable and protected from undocumented change.

For high-risk AI systems, the EU AI Act makes logging a legal duty once the high-risk rules apply: Article 26 requires deployers to keep the logs the system generates, to the extent they control them, for at least six months unless other law provides otherwise. Most finance uses are not high-risk, but the same discipline is simply good practice.

• Who asked or which schedule triggered the action, and when.
• The input: document references and data extracts, not only a summary.
• The tool, prompt version and model name and version.
• The output: the proposed entry, match or answer, with any citations.
• The decision: approved, changed or rejected, by whom, with the reason.
• The posted result, linked to the ledger's own audit trail.

Worked example: an AI-drafted accrual under review

At the September month end, an AI assistant drafts the electricity accrual because the supplier's invoice arrives in October. It takes the last three invoices of EUR 4,500, EUR 4,700 and EUR 5,200, which total EUR 14,400, and proposes an accrual equal to the average of EUR 4,800: Dr Electricity expense 4,800 / Cr Accruals 4,800, reversing on 1 October. The arithmetic and the entry are correct.

The reviewer checks what the assistant could not know. The supplier's notice in the contract file shows a tariff increase of 10% from 1 September, so the expected charge is EUR 4,800 plus 10%, which equals EUR 5,280. She rejects the draft, records the reason, and approves Dr Electricity expense 5,280 / Cr Accruals 5,280, with the same reversal. Both entries balance.

Governance turns the correction into a lasting improvement. The reason code tariff change not in inputs is logged, the automation owner adds the contract notices folder to the inputs, the change is approved by the controller, and the test set gains a case with a tariff change. In October, when the invoice arrives at EUR 5,310, the EUR 30 difference is small and explained.

GDPR basics for AI in finance

Finance data contains personal data: salaries, bank details of sole traders, customer names, expense claims. The GDPR (Regulation (EU) 2016/679) applies whenever an AI tool processes it. In general terms, the finance team needs a lawful basis under Article 6, data minimisation under Article 5, a processor contract under Article 28 with the AI provider, a lawful route for transfers outside the EEA under Chapter V, appropriate security under Article 32 and an entry in the records of processing under Article 30. A data protection impact assessment under Article 35 is required where processing is likely to result in a high risk to individuals.

Article 22 matters most for finance. People have the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them, subject to limited exceptions and safeguards such as the right to obtain human intervention. Automatically refusing credit to a sole trader, or stopping an employee's expense claims without review, can fall into that territory. Keeping a person in the decision is both a GDPR safeguard and a control.

Check the provider's terms. As of September 2026, Anthropic's privacy centre, which covers its commercial products including the API, states that for Claude for Work business accounts the customer is the controller and Anthropic acts as processor, and that by default Anthropic does not use inputs or outputs from its commercial products to train its models unless the customer chooses to share them, for example as feedback.

The EU AI Act: risk tiers and what applies to finance

The EU AI Act (Regulation (EU) 2024/1689) regulates AI systems by risk. Some practices are prohibited under Article 5. High-risk systems, listed through Article 6 with Annex I for regulated products and Annex III for specific use cases, carry the heavy obligations. Certain systems carry transparency duties under Article 50, and everything else is minimal risk with no new obligations. Providers of general-purpose AI models, such as the companies that build large language models, have their own duties. Most finance teams are deployers: they use AI systems rather than build them.

Typical finance uses, such as coding invoices, matching bank lines, drafting variance commentary or answering how-do-I questions, are not listed in Annex III and are usually minimal risk. Two duties still reach almost every team. AI literacy under Article 4, as amended in 2026, requires providers and deployers to take measures to support the AI literacy of their staff and others operating AI on their behalf, without having to guarantee a specific level for any individual. And if the team builds a chatbot that talks to customers or suppliers, for example about overdue invoices, Article 50 requires that people are informed they are interacting with an AI system unless that is obvious.

Annex III point 5(b) is the finance use case to watch: AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with an exception for systems used to detect financial fraud. Credit limits for companies fall outside it, but consumers and sole traders are natural persons. From 2 December 2027, a deployer of such a system must use it according to the provider's instructions, assign human oversight to people with the necessary competence, training and authority, keep logs, and carry out a fundamental rights impact assessment under Article 27. Employment uses in Annex III point 4, such as tools that evaluate staff performance, are also high-risk.

EU AI Act dates as of September 2026

The timeline changed in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, dated 8 July 2026, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, amended the AI Act. It postponed the high-risk obligations, rewrote the AI literacy duty and added new prohibitions. As of September 2026 the application dates are as follows.

• 1 August 2024: the AI Act entered into force.
• 2 February 2025: prohibited practices and the AI literacy duty apply.
• 2 August 2025: obligations for providers of general-purpose AI models and the governance rules apply.
• 2 August 2026: the general date of application, including the Article 50 transparency obligations.
• 2 December 2026: the two prohibitions added by the Omnibus, on AI that generates non-consensual intimate images and child sexual abuse material, apply; providers of generative systems already on the market before 2 August 2026 must comply with the Article 50(2) marking duty.
• 2 December 2027: obligations for high-risk systems listed in Annex III, including creditworthiness scoring, apply, instead of 2 August 2026.
• 2 August 2028: obligations for high-risk systems covered by the product legislation in Annex I apply.

Canada's position: AIDA and after

Canada has no federal AI-specific statute in force as of September 2026. The proposed Artificial Intelligence and Data Act (AIDA) was part of Bill C-27, the Digital Charter Implementation Act, 2022. Parliament's LEGISinfo record shows the bill still under consideration in committee when the session ended on 6 January 2025; it was not passed. A 2023 voluntary code of conduct for advanced generative AI systems, published by Innovation, Science and Economic Development Canada, remains voluntary guidance for organisations that develop or manage such systems.

On 15 June 2026 the Minister of Artificial Intelligence and Digital Innovation introduced Bill C-36, the Protecting Privacy and Consumer Data Act. It is a privacy law rather than an AI act, but the Government of Canada says it would require organisations to be transparent about their use of automated decision making for significant decisions about individuals. As of September 2026 it is at second reading in the House of Commons. Until then, PIPEDA and provincial privacy laws, including Quebec's rules on decisions based exclusively on automated processing, govern AI that uses personal data.

Governance support in Skyline Nexus ERP

Skyline Nexus ERP applies these principles to its own AI. The in-app assistant answers from the product's help library, and every answer is verified before it is shown: the cited help page must exist and must be among the passages retrieved for the question, otherwise the user sees plain search results. AI calls are rate-limited per user. Live business figures come only from eight whitelisted reports, under the same permissions and permitted locations as the report screens, and the model never writes database queries. AI-drafted help pages wait for human review in an administrator cockpit before they are published.

For outside assistants such as Claude Desktop, an administrator issues each user a personal token for the Skyline Nexus ERP MCP server, limited to 60 calls per minute; apart from creating a support ticket, nothing can be written through it. In the ledger, roles and permissions decide who can create, post and reverse journals, so segregation of duties comes from how you assign them; journals at or above the approval threshold wait for approval when approval is switched on, locked periods refuse postings, and the Audit Trail records every change with old and new values.

AI drafting of journals, bills and bank matches for human approval, and scheduled AI automations, are being rolled out on the Skyline Nexus ERP roadmap; ask us for your go-live date.