Building an AI Governance Policy for Your Accounting Firm

7/18/2026

The reason to write this policy now is not that a rule requires it. It is that your staff are already using these tools, and a firm without a policy does not have no practice — it has an undocumented practice, established by whoever downloaded something and started pasting client information into it.

That is the actual risk, and it is a confidentiality risk before it is anything else.

The Principle the Whole Policy Rests On

Write this into the document, because everything else follows from it:

The practitioner remains responsible for the work product regardless of what produced it.

A tool that drafted, summarized, computed, or cited something does not shift responsibility, does not constitute a defense, and does not satisfy a diligence obligation. Our posts on tax research and on return review make the same point from two directions, and it is the sentence that makes a policy coherent rather than a list of permissions.

The Twelve Sections a Policy Needs

1. Scope and definitions

What the policy covers, and specifically that it covers tools embedded in software the firm already uses — not only standalone chatbots. This is the part policies miss: assistants inside tax software, document management, spreadsheets, email, meeting platforms, and research tools are all in scope, and staff do not think of them as "AI."

2. Approved tools, by name and by tier

A named list, maintained, with the tier specified. The distinction matters because the same vendor's consumer and business offerings frequently have entirely different data terms — and a firm that approved an enterprise tier while staff use the free one has not implemented a control.

State plainly: consumer tiers are not approved for any client information.

3. What may never be entered

• Client identifying information
• Tax return information, absent the required consent
• Credentials, keys, or access tokens
• Unreleased financial data
• Anything covered by a confidentiality agreement or protective order
• Personnel and payroll data
• Draft documents subject to privilege

4. The consent question for tax return information

The provision that carries the sharpest consequence. The statutory restriction on disclosure and use of tax return information requires client consent in a prescribed form and manner, with penalties for violation.

The policy should state whether the firm will seek such consent at all, and if so, the exact form and process. Many firms will reasonably decide not to seek it and instead to prohibit entering that information anywhere — which is a cleaner control and costs very little, because as our post on AI use in practice explains, the useful applications work on de-identified input.

5. The de-identification standard

With examples rather than a principle. Names, entity names, identifying numbers, addresses, and distinctive figures replaced with placeholders — and a note that a combination of non-identifying details can still identify a client in a small market.

6. Permitted and prohibited uses

Permitted, per the categories established across this series: drafting and structuring documents from your own substance; summarizing a document you supply; translating a technical conclusion into client language; adversarial testing of your own reasoning; formula construction; issue-spotting and research framing.

Prohibited: obtaining authority or citations; reaching conclusions; generating client-facing advice; computing client figures; and anything entering a filed return, a report, or a memorandum without verification.

7. The verification requirement

The operative rule, stated so it can be enforced in review:

No citation, authority, figure, or factual assertion enters a work product without verification against the source. For authority, that means reading it in the primary source — not accepting a summary, and not accepting that a retrieval tool cited something real.

The reviewer's role should include confirming that cited authority was attached, which makes a verification failure visible in review rather than discoverable later.

8. Documentation and retention

Two decisions to make deliberately rather than by default:

Whether AI use is recorded in the engagement file. There is no universal requirement, and a firm should decide, state the decision, and apply it consistently.

Transcript retention, where a tool retains conversations. Those transcripts may contain client information and are subject to the firm's retention schedule, access controls, and confidentiality obligations.

9. Client disclosure

Treated honestly: there is no universal requirement to tell clients that a firm uses these tools, engagement letters increasingly address it, and clients occasionally ask.

The policy should state the firm's position — silence, a general statement in the engagement letter, or disclosure on request — and the reasoning. What a firm should not do is have no position and improvise when a client asks.

10. Roles

Who approves a tool, who owns the policy, and who answers questions — named. A policy with no named owner is not maintained, and in a field changing this quickly an unmaintained policy is quickly wrong.

11. Training

Required, before use, and repeated when the approved list changes. As our post on tool adoption argues, an untrained tool is shelfware — and an untrained policy is a document nobody follows.

12. Incident response — the section every policy omits

And the one that will actually be used.

What to do when client information was entered somewhere it should not have been. Staff will do this — by accident, in haste, or by not understanding the tier distinction — and a policy with no route for reporting it guarantees that nobody reports it.

The section should state: report immediately, to a named person, without blame for the report itself; what the firm will do (establish what was entered, what the vendor's terms permit, whether deletion is possible, and whether the client must be notified); and that concealing an incident is a separate and more serious matter than causing one.

A firm that gets this section right learns about its exposures. A firm that omits it does not.

Vendor Terms to Establish Before Approving Anything

In writing, per tool:

Whether inputs are used to train the vendor's models, and whether that can be disabled.

Where data is processed and stored.

Retention — how long inputs and outputs persist, and whether deletion is available and verifiable.

Who at the vendor can access it.

Subprocessors, and their terms.

Breach notification commitments and timeframes.

Contractual confidentiality obligations.

And the tier the terms apply to, since this is where firms are caught.

The Enforcement Problem

Worth stating because it determines whether any of this works.

A policy staff route around is worse than no policy, because the firm now has a document asserting a control that does not exist — which is a worse position in front of a client, an insurer, or a board than an acknowledged gap.

Which means the policy has to be livable:

Approve something that actually works, and make it available to everyone who might otherwise improvise. A firm that prohibits everything and provides nothing has chosen unmonitored use.

Do not write a blanket prohibition. It drives use underground, removes the firm's visibility, and is unenforceable in a world where these capabilities are embedded in ordinary software.

Make the sanctioned path easier than the unsanctioned one. That is the actual control, and it is more effective than any sanction.

Ask periodically what people are actually using, without penalty, and update the approved list accordingly.

The Professional Standards Overlay

Three obligations the policy should reference rather than restate:

Competence. A practitioner using a tool they do not understand well enough to evaluate its output has a competence problem independent of the tool.

Diligence, including in tax practice under the rules governing practice before the IRS.

Independence, where the firm might build or implement a client's AI process. As our post on audit analytics notes, designing or implementing a client's monitoring or controls can be a non-attest service raising independence questions for an attest client — and a client asking the firm to build what the firm recommended needs that analysis before anyone agrees.

A Short Outline to Adapt

1. Purpose and the governing principle: the practitioner owns the work product
2. Scope, including embedded tools
3. Approved tools and tiers
4. Prohibited inputs
5. Tax return information and consent
6. De-identification standard
7. Permitted uses
8. Prohibited uses
9. Verification requirement and the reviewer's role
10. Documentation and transcript retention
11. Client disclosure position
12. Roles and approvals
13. Training requirement
14. Incident reporting and response
15. Review cadence and version history

Keep it short enough to be read. A four-page policy people follow beats a twenty-page one they do not.

Structured coverage is available through the AI courses for accountants and CPAs catalog, the AI for Accountants Certificate Program, AI Essentials for Accountants, AI Applications for Accountants, ethics training and professional conduct, tax practitioner regulations, penalties, and security, and the tax preparer certification courses listing.

Review It Quarterly at First

The tool landscape changes faster than an annual policy cycle accommodates. Quarterly review for the first year, then semiannually — with a version history, because "which version was in effect when this happened" is a question that eventually gets asked.

What to look at each time: the approved list, whether anyone has requested something not on it, any incident reported, whether the vendor terms have changed, and whether the verification requirement is actually being enforced in review.

What Not to Put In It

A blanket prohibition, per above.

A list of specific prompts, which dates immediately and misses the point — the policy governs categories of use and handling of information, not phrasing.

Aspirational language with no mechanism. "Staff will use AI responsibly" is not a control.

A requirement nobody will meet, such as logging every use, which produces non-compliance the firm then has to ignore — and a policy the firm knowingly does not enforce is worse than a narrower one it does.

Where Policies Fail

• Written after an incident rather than before
• Embedded tools out of scope, so most actual use is ungoverned
• Approved at the vendor level rather than the tier level
• No position on tax return information, leaving the sharpest exposure unaddressed
• A de-identification principle with no examples
• No verification requirement, or one not enforced in review
• No decision on engagement file documentation, so practice varies by person
• No client disclosure position, improvised when a client asks
• No named owner, so the policy is never updated
• No training, so the policy is unread
• No incident section, guaranteeing that incidents go unreported
• Vendor data terms never established in writing
• A blanket prohibition, driving use underground and removing visibility
• A requirement the firm will not enforce, which undermines the rest
• Never reviewed, in a field that changes quarterly

The summary for a firm owner: your staff are using these tools now, so the choice is between a documented practice and an undocumented one. Write four pages — the responsibility principle, the approved tools with tiers, what may never be entered, the verification rule, and an incident section people can actually use — approve something that works so the sanctioned path is the easy one, name an owner, and review it quarterly.

Frequently Asked Questions

Why write a policy now rather than waiting for guidance?

Because staff are already using these tools, so a firm without a policy has an undocumented practice rather than no practice — established by whoever started pasting client information into something. The exposure is a confidentiality exposure first, and it exists whether or not the firm has addressed it.

What single principle should the policy state?

That the practitioner remains responsible for the work product regardless of what produced it. A tool that drafted, summarized, computed, or cited something does not shift responsibility, is not a defense, and does not satisfy a diligence obligation. Every other provision follows from that.

What do policies most often leave out of scope?

Tools embedded in software the firm already uses — assistants inside tax software, document management, spreadsheets, email, meeting platforms, and research tools. Staff do not think of those as "AI," so a policy aimed only at standalone chatbots leaves most actual use ungoverned.

Should a firm seek client consent to enter tax return information?

Many firms will reasonably decide not to, and instead prohibit entering that information anywhere. The statutory restriction requires consent in a prescribed form with penalties for violation, and a prohibition is a cleaner control that costs little — because the genuinely useful applications work on de-identified input.

Which section do policies omit and most need?

Incident response. Staff will enter client information somewhere they should not have, and a policy with no reporting route guarantees nobody reports it. The section should require immediate reporting to a named person without blame for the report itself, describe what the firm will do, and state that concealing an incident is more serious than causing one.

Why is a blanket prohibition the wrong answer?

Because it drives use underground, removes the firm's visibility into what is happening, and is unenforceable when these capabilities are embedded in ordinary software. A policy staff route around is worse than none, since the firm now asserts a control that does not exist. The real control is approving something that works and making the sanctioned path easier than the alternative.