AI Security for Accounting Firms: What the Rules Actually Require

Key Takeaways

• An AI vendor receiving client data is a "service provider" under 16 CFR 314.2, so all three duties in 16 CFR 314.4(f) attach: capable selection, contractual safeguards, periodic reassessment.
• The small firm exception at 16 CFR 314.6 exempts four program elements below 5,000 consumers, and vendor oversight is not one of them.
• Adopting an AI tool that touches client data is likely a material change under 16 CFR 314.4(g), and (c)(7) requires change management; neither is exempt below 5,000 consumers.
• An IRC 7216(a) violation is a misdemeanor carrying up to one year imprisonment or a $1,000 fine, and 26 USC 6713 adds $250 per disclosure, capped at $10,000 a year.
• One vendor incident starts three clocks for a California firm with 500 or more affected consumers: 15 days to the California AG, 30 days to individuals, 30 days to the FTC.
• Reported surveys put AI use among accounting professionals at 98%, while only about one in five firms has an AI policy.

AI security for accounting firms is a client data problem before it is a technology problem

AI security for accounting firms starts the moment client information leaves your building. Send it to a third party AI system and you have made a regulated disclosure. Four rule sets fire at once: the FTC Safeguards Rule, IRC 7216, the AICPA Code, and state breach law. None mention AI. All apply anyway.

Partners tend to frame AI security for accounting firms as a question about the tool, which is a vendor question. Regulators ask a different one: what did you disclose, to whom, under what contract, with whose consent, and can you prove it. A SOC 2 report answers none of those five. To decide which workflows are safe to automate at all, start with the accounting workflow automation matrix. For what the tools are used for day to day, see how CPAs actually use ChatGPT. This page covers the obligations that attach once client data is involved. This is information, not legal advice.

Table of Contents

1. The four rule sets that fire when client data reaches an AI tool
2. What the FTC Safeguards Rule requires of your AI vendor
3. What does the FTC Safeguards Rule require when your firm adopts an AI tool?
4. Does IRC 7216 require client consent before you use AI?
5. What the AICPA Code and the IRS actually say about AI
6. Injection, retrieval leakage, and shadow AI
7. Whose clock is running after a vendor breach
8. The vendor diligence script
9. What to do Monday morning

The four rule sets that fire when client data reaches an AI tool

Each rule covers a different slice of your data, and confusing them is the most common error we see.

IRC 7216 reaches tax return information only, so audit workpapers sit outside it while staying inside the AICPA Code. Under 16 CFR 313.3 a "consumer" obtains a service for personal or household purposes, so a purely commercial book is arguably outside the Safeguards Rule, and no FTC guidance resolves that line. Massachusetts 201 CMR 17.03 then imposes a written security program duty on anyone holding personal information about a Massachusetts resident, with no financial institution predicate.

What the FTC Safeguards Rule requires of your AI vendor

If your firm prepares returns, it is in scope by name. 16 CFR 314.1(b) lists "tax preparation firms" among the financial institutions under FTC enforcement, and IR-2026-92 (IRS, 18 August 2026) says tax and accounting professionals are financial institutions under the Gramm-Leach-Bliley Act. 314.1(b) also covers customer information another financial institution, such as a client's lender, sent you.

"Service provider" means any entity that receives, maintains, processes, or is otherwise permitted access to customer information through its provision of services to a financial institution. An AI vendor that receives client data fits, which triggers all three duties in 314.4(f).

Note the word "directly" in 16 CFR 314.2(r). The definition does not turn on whether the vendor keeps a copy, what the contract calls it or who owns the deployment, so a model provider you contract with is inside it, as is an implementation partner with access to production data. Gaper is the AI-native implementation partner that deploys supervised AI agents you own. That ownership moves the logs, keys and access controls into your environment; it moves neither Gaper nor that model provider out of 314.4(f) while either is permitted access to customer information.

IRS Publication 4557 restates that duty for tax preparers: select providers that can maintain appropriate safeguards, make sure your contract requires them, and oversee their handling of customer information. Adopting an AI vendor should therefore change at least five WISP sections: risk assessment, access controls, the service provider inventory, incident response, and training. That mapping is synthesis, not a quotation from IRS guidance.

What does the FTC Safeguards Rule require when your firm adopts an AI tool?

Treat the adoption as a change to your information security program. 314.4(g) requires you to evaluate and adjust the program for material changes to your operations or business arrangements, and 314.4(c)(7) requires change management procedures. Neither sits in the 314.6 small firm exception.

Whether a deployment is "material" is a judgment, and 314.4(g) sets no threshold. On the face of the text, routing client data through a new vendor changes your business arrangements, so never asking is the indefensible position. For the four duties 314.6 removes, see the small firm exception.

Change management is the duty easiest to miss, because an agent drifts from what you approved: prompts get edited, scopes widen, and providers retire models. On 30 September 2026 Anthropic notified developers that Claude Sonnet 4.5 retires from its API on 30 November 2026.

Before client data reaches the tool, put six things on file:

1. The service providers and your selection diligence under 314.4(f)(1), including the model providers they rely on.
2. A contract requiring safeguards under (f)(2), ideally signed rather than clickthrough.
3. Encryption in transit over external networks and at rest under (c)(3), or, where that is infeasible, compensating controls your Qualified Individual reviewed and approved.
4. Multi factor authentication under (c)(5) for everyone accessing the systems involved, unless your Qualified Individual approves equivalent controls in writing.
5. A change record under (c)(7), carried into your WISP.
6. A reassessment date for the provider, under (f)(3).

Two points remain open: no FTC action or court decision we have found applies the rule to a generative AI vendor, and the rule sets no schedule for "periodically assessing" a provider and says nothing about one that refuses your questionnaire.

Does IRC 7216 require client consent before you use AI?

Nobody knows, and anyone claiming it is settled either way is overstating US law as of August 2026. Because the statute is criminal and consent is cheap, obtain consent where practical.

"Disclosure" under 26 CFR 301.7216-1 is making tax return information known to any person in any manner whatever, which covers a chat box, an API call, a file upload, or an agent with tool access to a document store. It also covers what the preparer derives from that data, so an AI generated summary of a return is itself tax return information.

The escape hatch would be auxiliary services. 26 CFR 301.7216-2(d)(2) permits disclosure to a contractor for programming, maintenance, testing, or procurement of software used in return preparation, if that contractor receives written notice of sections 6713 and 7216. But the definition is circular: a person provides auxiliary services if he holds himself out as performing them. In The Tax Adviser (February 2024), Edward R. Jenkins concluded hosted generative AI will likely fall within it, while declining to categorise general purpose chatbots. Others disagree, and the IRS said nothing about consent in OPR Alert 2026-19.

If consent is your answer, the format is not optional. 26 CFR 301.7216-3 requires it to be knowing, voluntary, and obtained before disclosure, naming the specific recipient and the information covered, with a one year default duration. For Form 1040 clients, Rev. Proc. 2013-14 adds a separate document, 8.5 by 11 inch paper or larger, 12 point type, and no opt out consents.

Where is inference physically performed, and why does it decide your consent language?

26 CFR 301.7216-2(c)(2) requires consent whenever the recipient is outside the United States, even your own employee abroad. Rev. Proc. 2013-14 supplies verbatim offshore language, plus an "adequate data protection safeguard" at both ends where an unmasked SSN travels. That test has decayed: the first framework it names is the Commerce Department safe harbor, invalidated in 2015, whose Privacy Shield successor fell in 2020.

Cloud geography is opaque. OpenAI distinguishes storage residency from processing residency, and Azure OpenAI Data Zones are reported to cover the EU and US while global deployments may process worldwide. If you cannot establish US only processing, assume you need the offshore language. Masking SSNs first lowers that bar, which makes redaction at the boundary architectural, not optional.

What the AICPA Code and the IRS actually say about AI

ET 1.700.001 prohibits disclosing confidential client information without specific consent. ET 1.700.040 then offers a choice commentary routinely gets wrong: before disclosing to a third party service provider you either enter a contractual confidentiality agreement with reasonable assurance of appropriate procedures, or obtain specific client consent. It is an OR, not an AND.

ET 1.150.040 adds advance notice and a client veto: tell the client, preferably in writing, that you may use a third party service provider, and if the client objects, either do not use it or decline the engagement. A carve out covers administrative support such as software application hosting, but whether a hosted model qualifies is unaddressed. ET 1.300.040 is mandatory: plan and supervise the provider.

OPR Alert 2026-19, dated 24 June 2026, is the first formal IRS guidance on AI in tax practice. Practitioners cannot rely solely on AI, human scrutiny and editing are essential, and blind reliance where the logic is unclear may be unreasonable under Circular 230 section 10.22. Third party tools must be vetted under section 10.36 firm procedures.

Injection, retrieval leakage, and shadow AI

Prompt injection. OWASP ranks prompt injection as the top LLM risk and says it is unclear whether fool proof prevention exists. The dangerous variant is indirect: the model reads an external file carrying hidden instructions that need not be visible to a human. Unit 42's March 2026 analysis catalogued 22 payload techniques. Now picture an agent reading client PDFs.

Retrieval leakage. OWASP's LLM08 names cross tenant context leakage in shared vector databases, plus embedding inversion, so classify a vector store at the sensitivity of its source documents. Reported analysis adds that retrieval metadata leaks more often than chunk text: titles, file paths, and client identifiers returned in citations without the same filtering rigor, and the existence of an engagement is itself confidential. See AI agent security.

Shadow AI. In May 2026, CB Financial Services filed a Form 8-K disclosing an internal incident involving non-public customer information handled through an unauthorized AI application, including names, social security numbers, and dates of birth. It is reported to be the first Item 1.05 filing triggered by unauthorized AI use rather than an attack. IBM data cited secondhand puts shadow AI breaches at roughly $670,000 above sanctioned ones.

Whose clock is running after a vendor breach

State duties turn on the residency of the affected individual, reported at roughly 30 to 60 days where numeric. And because customer information includes records maintained on behalf of your firm, a vendor breach appears to trigger your own FTC notification, reported publicly under your name, though no FTC guidance states that explicitly. The encryption carve out is narrow: a notification event is acquisition of unencrypted customer information, and inference generally requires plaintext.

Discovery can also come early. Under 314.4(j)(2) you are deemed to know of an event once any employee, officer or other agent of yours knows of it, other than the person who committed the breach. Neither the rule nor the 2023 final rule's preamble says whether a vendor is an "other agent", so do not assume your 30 days waits for the vendor's email.

The vendor diligence script

Put these to the vendor verbatim. Each maps to an obligation you can cite. Disqualifiers, per CPA.com's diligence guide: vague no training claims, "only trusted people can access it," audit logs that are "coming soon."

"Will you sign a contract that expressly requires you to implement and maintain safeguards for our customer information, as 16 CFR 314.4(f)(2) obliges us to demand? A clickthrough ToS does not satisfy this."

Lead with this one. The regulation says "requiring your service providers by contract," and the regulation requires safeguards "by contract." Whether a clickthrough terms of service satisfies that is untested, so the defensible posture is a signed agreement that names the safeguard obligation.

"Do you train models on our inputs or outputs? Will you commit contractually to zero training, and does that commitment survive to every sub-processor and model provider in your chain?"

An FAQ page is not a commitment, so press further: "Is our data used to train or fine-tune any model, by default or through any user-triggered mechanism such as feedback buttons, and is that exclusion written into the contract or DPA rather than only an FAQ page?"

"How fast will you notify us of a security incident, in calendar days, contractually? Our FTC clock is 30 days from discovery and California's AG clock is 15 days, and neither can safely be assumed to wait for your notice."

Timing belongs in the contract. Pair it with: "Is client data encrypted at rest and in transit with keys we control? The 314.4(j) notification duty only bites on unencrypted customer information, so this materially changes our breach exposure."

"Which sub-processors and which underlying model providers touch our data, where are they located, and what is the notification term when that list changes?"

A change to that list can invalidate a 7216 consent that named a specific recipient. Also ask: "Do you hold yourself out to tax return preparers as providing auxiliary services in connection with tax return preparation? That framing is what the 7216 auxiliary-services exception turns on, and your answer affects whether we need signed client consents."

"Is tenant isolation implemented as a separate index per client, a namespace per client, or a metadata filter on a shared index? Show us where in the stack the tenant predicate is bound."

Then press on failure behaviour: "What happens to a retrieval query if the tenant filter is missing or malformed? Does it fail closed and reject, or does it fall back to a default scope?" And on citations: "Are document titles, file paths, client names and citation metadata filtered with the same tenant predicate as chunk body text?"

"Do you have a current SOC 2 Type II report or equivalent we can put on file as evidence of our pre-selection diligence under 314.4(f)(1), and will you support our periodic reassessment under 314.4(f)(3)?"

Add to the same file: "What is your data retention period for prompts, outputs, and logs, and can we set it to zero?" And: "Do you offer role-based access controls and audit logs sufficient for us to evidence who prompted with what client data, for our WISP and for Circular 230 section 10.36 firm procedures?"

Three more: "Can we segregate or exclude SSNs and other identifiers before data reaches you, through masking or tokenisation?" "Can we deploy in a private tenant or VPC so the data never reaches a shared multi-tenant environment?" "Will you indemnify us for regulatory penalties and breach-notification costs arising from your security failures?"

What to do Monday morning

1. Inventory every AI tool in use, including personal accounts. Reported data puts weekly AI use among professionals at 74% and shadow use at 33%.
2. Update your WISP in the five places named above. Without a WISP, IRS Publication 5708 is a template for smaller practices.
3. Classify each tool by data path: third party with training, third party without training, firm controlled environment, or local on device. That split comes from the CalCPA and CAMICO checklist.
4. Decide your 7216 position in writing, and paper consents in Rev. Proc. 2013-14 format for 1040 clients. Generic language such as "AI tools we may use from time to time" fails the specific recipient test.
5. Get the vendor answers into a contract or DPA, not an email.
6. Confirm your liability policy still covers AI claims. Carriers are reported to have introduced broad AI exclusions.

Reported data shows 84% of accountants agree strong AI data security is becoming a competitive advantage, while only 33% proactively explain their AI use to clients. That gap is the opportunity. The architectural answer is usually to stop renting a general purpose chat window and run purpose built agents inside your own boundary, with permission aware retrieval, redaction at the edge, and exportable audit trails. That is the model behind AccountsGPT and our AI automation for accounting firms work. To scope a first build, see top AI projects for accounting and finance.

Book a free AI assessment

Thirty minutes, no commitment. We map one workflow, make the build or buy call, and scope the smallest thing worth shipping.