On a Tuesday, a partner puts a question to the compliance officer of a firm with both an assurance and an advisory practice: can the tax practice use Claude for advisory memos, given that two people already do? The firm adopted its AI policy last year. It runs to five pages, uses the words "careful" and "confidential" and names Copilot as the preferred tool. It says nothing about Claude, nothing about an advisory memo containing a valuation, and nothing about the account those two people are using.
This is where an AI policy either works or doesn't. A firm's policy need not be long, but it has to answer that question: is this tool allowed, with this file, on this account, and if not, what should people use instead? The general structure of such a policy is covered in our guide to writing an AI policy, and there is a one-page AI policy example as well. This piece looks at what is different for an accounting firm.
Which questions does a firm's policy need to answer?
The same questions as anywhere else, with answers that fit the way a firm works.
| Question | What a firm writes down |
|---|---|
| Which tools are allowed, on which account? | A list of names with the account type next to each; Copilot in the firm's own environment and Copilot on a personal account are different things, and the AI feature in the accounts production software belongs on the list too |
| Which data never goes in? | Client names combined with figures, citizen service numbers and payroll data, IBANs, figures not yet adopted or published, valuations, anything from an audit file |
| How does assurance differ from advisory work? | Which tools are allowed in which practice, and that AI output in an audit file is not audit evidence without the accountant's own work |
| Who assesses a new tool, and how quickly? | An owner in the practice area answers the questions, the compliance officer reviews and there is a deadline |
| What do you do with a tool that has no decision? | Public information only, and where to request an assessment |
| How do staff hear about a change? | Where they open the tool, not in an email from three weeks ago |
| How do we see whether the policy is followed? | The list in the policy set against the tools people actually open, in counts, without names |
The second row is where a firm differs from most organisations. Most of what must never go in is not personal data: a revenue figure, a valuation, a figure the client has yet to adopt. The GDPR has nothing to say about that; the duty of confidentiality in the VGBA, the Dutch professional rules for accountants, does. So write that row as a confidentiality rule rather than a privacy rule, with examples from the firm's own work. What a junior accountant does with it in practice is covered in our article on ChatGPT and client files.
How does the assurance practice differ from advisory work?
By more than one rule, and the policy has to say which.
In advisory work the issues are confidentiality and what has been agreed with the client: some engagement terms say who may process the information, and a chatbot vendor is a third party. The assurance practice adds the audit file. What a chatbot says about a balance is an idea, not audit evidence; the accountant does the work and documents what was done. An AI-generated summary in the file without that work alongside it is the first thing a quality review will ask about.
That does not mean the assurance practice uses no AI. It means the policy sets out, practice by practice, which tools are allowed and for what: a tool for rewriting a client email can be allowed in both, while a tool for summarising an audit file needs a decision of its own. How much weight that carries varies by firm and by engagement; the line is drawn by the compliance officer and the firm's quality policy, not by this article.
What is the compliance officer's role?
Not the one they are usually given. In many firms the AI policy ends up with the compliance officer because it is about rules. That doesn't work, for the same reason "the DPO will handle it" doesn't work elsewhere: whoever reviews should not also decide and own. A compliance officer who approves the tools personally can no longer say, independently and later on, that something is wrong.
A better split looks like this. The compliance officer reviews a new tool against the professional rules and the quality system and, together with the DPO or privacy officer, against the GDPR: is there a data processing agreement, where does processing take place, is a DPIA needed? The decision itself rests with the board or the partners. And each tool has an owner in the practice area: the head of accounts preparation for the AI feature in the accounts software, the tax partner for Claude. That owner answers the questions, knows the work the tool is used for and drives the reassessment when the vendor changes something. How those roles fit together in general is set out in our article on AI governance roles and who does what.
How does the policy reach the accounts preparation team?
Not through the document. A five-page policy gets read once, during training or when someone joins, and the tool is opened hundreds of times after that. What does stick is one rule for each situation, given at the moment that situation arises. How to write that without burying people in rules is covered in our article on communicating AI policy without overloading people.
Back to the partner's question. The two tax advisers open Claude and see the short notice the firm has switched on for tools without a decision: no decision has been made about this tool yet, so do not share personal data or confidential business information here. They write the memo in Copilot that afternoon, leaving out the family's name and the valuation, and request an assessment. Three weeks later the firm has made its decision: limited use, only in the firm's business environment and without client data, with Copilot as the tool for anything involving a client. From then on, everyone who opens the tool sees that one sentence.
None of this is a complicated setup. It is the list from the first row of the table, with one of four statuses for each tool, visible where the work happens.
BeeSensible does this in the browser: the firm records a decision for each tool from the Inbox, and that decision appears when someone opens the tool, with the approved alternative as the first button. The extension does not block anything of its own accord and does not decide on the firm's behalf; whether someone can carry on to a not-allowed tool after the notice is a setting the firm chooses, and what happens next is counted without a user ID.
