AI data security for an accounting firm is the set of legal, contractual and technical controls that determine whether client data stays protected when it passes through an AI system, plus the documentation that proves it did. 

Four rulebooks apply at the same time. The FTC Safeguards Rule, which names accounting and tax preparation businesses as financial institutions, requires least-privilege access, encryption, activity logging, secure disposal and contractual safeguards from every service provider. 

Internal Revenue Code section 7216 makes some disclosures of tax return information a criminal matter without written client consent. Treasury Circular 230, as the IRS applied it in June 2026, obliges firm leaders to vet third-party AI tools, establish secure data-handling protocols, and treat opaque system logic as a limit on reasonable reliance. The AICPA Code requires that you either contract with the provider for confidentiality or obtain specific client consent.

A vendor's SOC 2 report does not answer these questions. SOC 2 is an attestation against criteria that doesn’t say anything about training-data use, tenant isolation or model behaviour, and the examination can exclude the foundation-model provider entirely.

The answers come from four design decisions: where inference happens, whether the system makes determinations or prepares them for a person, what gets retained and where, and whether every action is attributable in a log.

What AI Data Security Means For an Accounting Firm

For an accounting firm, AI data security means controlling the full path client information takes through an AI system: what data enters, where it is sent, who can access it, how long it remains there, and whether it can be used for anything beyond the engagement.

In this case, AI creates new places for existing sensitive data to go.

A tax document that once moved from a client portal into tax software and a workpaper may now pass through a document-extraction service, a model endpoint, an orchestration layer, application logs, an embeddings database, and a final workpaper. 

For this reason, a firm cannot evaluate security only by asking whether the AI vendor encrypts data. It needs to understand the entire data path.

Five questions should come before deployment:

1. What information enters the system? Tax returns, bank statements, payroll records, invoices, Social Security numbers, contracts, advisory documents, or other client information.
2. Where does that information go? The model provider may be only one component. Data can also pass through cloud infrastructure, document processors, databases, logs, backups, and subprocessors.
3. Who can access it? That includes firm personnel, vendor personnel, connected applications, automated agents, and any service involved in the workflow.
4. What happens to it afterward? The firm needs to know the retention period, deletion process, backup policy, logging behavior, and whether the information may be used for model training, analytics, or product improvement.
5. Who remains responsible? Sending information to a third-party AI provider does not transfer the firm's responsibility for protecting it.

Accounting firms can hold several overlapping categories of protected information, and which rules apply depends on the information itself and on why the firm received or uses it.

These categories can overlap. A document used in tax preparation may simultaneously contain customer information and confidential client information. Information received only for bookkeeping or advisory work may fall outside the tax-preparer rules while remaining protected under other obligations.

For a COO, the consequence is that a secure AI is not a sufficient purchasing criterion, and before approving an AI tool or workflow, the firm should be able to map the complete data path:

client source → firm system → AI service → supporting infrastructure → stored outputs → logs and backups → deletion

How to Assess AI Data Security Before You Deploy

When we work on our client’s projects, to assess AI data security, we use five steps in this order. The sequence in this process is important, as steps one and two determine which rules apply, and most firms begin at step three, which allows the vendor's paperwork to set the firm's compliance posture.

1. Map the data flow before you read any vendor material. Client document, intake, storage, retrieval, model call, output, review, archive, log. Draw it on one page. Every hop is a place where one of the four rulebooks attaches, and you cannot evaluate a control you have not located.

2. Fix the determination boundary in writing. Decide what the system prepares and what it decides. This one decision changes the legal character of the whole deployment, for reasons the next section explains.

3. Read the vendor's SOC 2 report for what it excludes. Subservice carve-outs, the controls the report assigns back to you, and the period it covers. The exclusions carry more information than the opinion.

4. Specify the controls, then contract for them. Under 16 CFR 314.4(f)(2) you must require your service providers by contract to implement and maintain appropriate safeguards. Your control list is a contract exhibit, not a wish list.

5. Write the deployment into the WISP and the engagement letter, and document the decision. Circular 230 section 10.36 requires adequate firm procedures, and the OPR has said what that covers for AI: staff training, internal protocols for secure data handling and accuracy monitoring, and vetting of third-party AI tools, all documented.

The Four Rulebooks That Govern Client Data in an AI System

The FTC Safeguards Rule

You are covered. The regulation lists an accountant or other tax preparation service as an example of a financial institution at 16 CFR 314.2(h)(2)(viii), so coverage is not a matter of interpretation.

Five elements bear directly on an AI deployment. 

1. Under 314.4(c)(1)(ii) you must limit authorised users' access to only the customer information they need to perform their duties. 
2. Under 314.4(c)(3) you must encrypt customer information in transit over external networks and at rest, and if you judge encryption infeasible your Qualified Individual must approve compensating controls in writing. 
3. Under 314.4(c)(4) you must adopt secure development practices for applications you build and procedures for evaluating, assessing or testing the security of applications developed externally. An AI system is one or the other, and there is no third category.
4. Under 314.4(c)(6) you must dispose of customer information no later than two years after its last use unless you have a legitimate reason to keep it, and you must periodically review that retention policy.
5. Under 314.4(c)(8) you must monitor and log the activity of authorised users and detect unauthorised access, use or tampering.

One narrower point. Section 314.6 exempts firms holding customer information on fewer than 5,000 consumers from four provisions, and none of them is a control listed above. Whether your firm sits under that threshold is a question for your counsel, since "consumer" carries a specific meaning at 314.2(b)(1).

Sources: FTC Safeguards Rule

IRC sections 7216 and 6713

This is the layer that turns a software decision into a legal one.

Section 7216 is criminal. A preparer who knowingly or recklessly discloses or uses tax return information without authority faces a fine of up to $1,000 and up to a year, rising to $100,000 where the disclosure connects to a crime involving identity theft. Section 6713 is the civil parallel at $250 per disclosure, capped at $10,000 in a calendar year, and it carries no knowing-or-reckless threshold, so inadvertent disclosure counts. Circular 230 section 10.51(a)(15) makes willful unauthorised disclosure separately sanctionable. Disclosure, under Reg. 301.7216-1(b)(5), means making the information known to any person in any manner.

Three rules decide whether you need consent, and each one maps onto a design decision.

Disclosure to a third-party service provider engaged to assist with preparation, processing or electronic filing does not require consent. Disclosure to a provider making substantive determinations affecting the tax liability reported does require consent, under Reg. 301.7216-2(d)(1). The Tax Adviser gives the standard examples: which filing status is elected, how income is reported, which deductions and credits are claimed, how income is allocated. Disclosure outside the United States almost certainly requires consent under Reg. 301.7216-3(a)(3)(i)(D), and where the offshore provider receives an unredacted Social Security number, both you and that provider must have adequate data protection safeguards in place under Reg. 301.7216-3(b)(4).

So two questions about your AI system carry legal consequences. Where is inference performed, and where does the data rest? A model endpoint in a non-US region converts a routine extraction workflow into a consent-required offshore disclosure. And does the system make substantive determinations, or does it extract, classify, route and draft for a person to determine? That boundary is the difference between no consent requirement and a per-client consent regime.

Use is regulated separately and broadly. Under Reg. 301.7216-1(b)(4)(i), use includes any circumstance in which you refer to or rely upon tax return information as the basis to take or permit an action. Mining client data to identify advisory or wealth-management opportunities falls outside the narrow list exception and requires consent.

One honest note on where the guidance stands. The last formal IRS guidance under section 7216 dates to 2013. In its 2026 submission to the IRS on tax priorities, the AICPA asked for additional guidance on the use of technology, including AI, in tax preparation. The profession is waiting on the same clarity you are, which raises rather than lowers the value of a documented decision you can defend.

Sources:  IRC Sections 7216, IRC Section 6713

Circular 230 and OPR Alert 2026-19

On 24 June 2026, the IRS Office of Professional Responsibility issued Alert 2026-19, Introductory Guidelines for Responsible AI Use in Federal Tax Practice. It is labelled introductory, and it creates no new rules, which is the point. The duties it applies were already binding on you. Three passages matter most.

Section 10.36 places the obligation on whoever holds principal authority over the firm's federal tax practice to take reasonable steps to ensure adequate procedures. The OPR spelled out what that covers for AI: comprehensive staff training on the risks and requirements, internal protocols for secure data handling and AI accuracy monitoring, and vetting of outsourced or third-party AI tools. Every step documented. If you are the COO, this is the provision that lands on your desk.

Section 10.37 governs written advice, and the OPR's application of it is the sharpest sentence in the bulletin. Where a system's logic is opaque, the OPR states, reliance "may be unreasonable" under section 10.37. Explainability stops being a preference and becomes a condition of reasonable reliance. A model whose reasoning you cannot reconstruct is a model whose output you may not be entitled to rely on.

The third passage names the technical failure this article is about. The OPR describes client privacy being compromised when data generated for one client is repurposed by the program to answer an inquiry concerning another client, or when data compiled for one issue spills into an algorithm and combines with a related issue involving a different client. The federal regulator of tax practice has described tenant and context isolation as a professional-responsibility problem. If you needed a reason to treat isolation architecture as a compliance control rather than a technical nicety, that is it.

Two shorter points. Section 10.22 requires you to review all AI-created content before it reaches a client or the IRS, verifying facts, citations and calculations. And section 10.27(a) reaches your economics: billing manual time not spent, or double-billing AI-assisted work, may be an unconscionable fee depending on the pattern and the size of the differential, and the OPR expects cost savings passed on openly.

Sources: Circular 230, OPR Alert 2026-19

The AICPA Code and the state law layer

Three interpretations govern every third-party service provider you use, but none of them contains a geography test. A provider three miles away and a provider on another continent are treated identically.

ET 1.150.040 asks you to inform the client, preferably in writing, that you may use a third-party service provider, before you disclose confidential client information to them. ET 1.300.040 requires you to ensure the provider has the required professional qualifications, technical skills and resources, and to plan and supervise the work. ET 1.700.040 gives you an election: either enter a contractual agreement with the provider to maintain confidentiality and provide reasonable assurance it has procedures preventing unauthorised release, or obtain specific client consent. 

One question in this area has no authority resolving it, and you should decide it deliberately rather than by default. ET 1.150.040 .03 carves out providers supplying only administrative support services, such as record storage, software application hosting and authorised e-file transmittal, where no client notice is required. Is your AI tool inside that carve-out or outside it? A document-extraction tool that routes output to a preparer looks like hosted software. An agent that reconciles accounts and drafts adjusting entries looks like a provider performing professional services. The answer follows from what the system is designed to do rather than from what it is called, and it is a question for your counsel.

State law turns on the same design decision. California's privacy regulations covering automated decision-making technology took effect on 1 January 2026, with ADMT compliance required from 1 January 2027, and they define ADMT as technology used to substantially replace human decision-making, meaning the business uses the output to decide without human involvement. A deployment that keeps a person at the determination point sits outside that regime. 

Sources: AICPA Code

What SOC 2 Does and Does Not Tell You About an AI Vendor

A current SOC 2 Type II is useful evidence that an independent CPA firm tested whether specified controls operated over a period. For an accounting firm evaluating an AI vendor, that is a good starting point. It is not the end of the security review.

Four gaps matter most:

The rule is not to treat “SOC 2 compliant” as shorthand for “safe for client data.” Read the scope, exclusions, customer responsibilities, and reporting period, then separately verify the AI-specific controls that matter to your deployment.

SOC 2 tells you whether certain controls were examined, but your job is to determine whether the right controls were examined.

AI Access Control: Give the System Only What the Task Requires

Access control for AI is about what the AI system can see and what actions it can take on that employee's behalf, not only about which employee can log in. It .

The FTC Safeguards Rule requires firms to limit access to customer information to what an authorized user needs for their duties and to monitor authorized-user activity. In an AI workflow, that principle should extend through the agent and the tools it calls.

For example, a close-review agent may need permission to read one client's workpapers. It usually does not need access to every client folder, permission to delete documents, or authority to post entries without review.

Here, four controls matter:

This is important even if the model itself is strong. OWASP identifies excessive permissions and excessive autonomy as core agentic risks and recommends minimizing tool access and requiring human approval for high-impact actions.

That’s why ask yourself a question if an AI task goes wrong, how much can the system reach before a person can stop it? Good access control makes that answer as small as possible.

Do You Need Client Consent to Use AI on Client Data?

Sometimes. The answer depends on what client data the AI receives, what the provider does with it, and which professional or tax rules apply to that use.

For tax return information, Section 7216 does not mean every disclosure to an AI or service provider automatically requires client consent. Certain uses and disclosures are permitted without consent. Therefore, the first question is whether the proposed AI workflow falls within one of those permitted situations. If it does not, consent may be required.

For clients filing Form 1040-series returns, the consent process is stricter than many firms expect. Where consent is required, Revenue Procedure 2013-14 generally requires a separate written consent with prescribed content. It must be affirmative rather than opt-out, provided before the disclosure or use, and given to the taxpayer in copy. A broad sentence in an engagement letter saying that the firm may use third-party technology is not a substitute for that process.

For business entities and other taxpayers outside the Form 1040-series rules, the consent can be incorporated into an engagement letter if it contains the information required by the regulations.

That distinction matters for firms serving both individuals and businesses. One AI workflow may process similar documents across both engagement types while the consent requirements underneath them differ.

The AICPA confidentiality rules create a separate question. A firm may be able to address disclosure to a third-party service provider through appropriate confidentiality arrangements or specific client consent, depending on the circumstances. That does not automatically satisfy Section 7216 when the tax rules independently require consent.

That is why the practical review has three steps:

1. Identify the data. Does the workflow contain tax return information or other confidential client information?
2. Identify the disclosure. Which AI provider, subprocessor, or external service receives that information, and what does it do with it?
3. Determine whether consent is required. Check the applicable Section 7216 exception or consent rule separately from the firm's AICPA confidentiality obligations.

The important point is that “we use AI” is not what determines whether consent is required. The data flow does.

Before deployment, the firm should be able to show exactly what leaves its systems, who receives it, and under what authority that disclosure occurs. Where the answer depends on Section 7216, engagement-letter language, or professional confidentiality rules, confirm the approach with counsel and the firm's professional liability adviser before the workflow goes live.

How Codebridge Builds Inside These Constraints

Codebridge grew out of KPMG, and the habit that carried over is a bias toward control evidence over demonstrations. In regulated-data environments, the question that decides whether a system ships is whether you can show what it could reach and what it did, and that question gets answered in the design phase, or it does not get answered at all.

Two things shape how we work with professional services firms. We deliver AI as an engineering service rather than a subscription, and the client owns the code. That ownership matters for a reason specific to your obligations: it is what lets you satisfy 16 CFR 314.4(c)(4) on externally developed applications, produce evidence for your WISP, and answer a peer reviewer without waiting on a vendor's permission. And the determination boundary and the retention terms come out of discovery as fixed decisions, because both of them constrain the architecture rather than follow from it.

The honest tradeoff: this route carries a higher engineering commitment and a longer time to value than buying a platform. A firm that needs something running next month should buy a platform and write the WISP around it. This approach suits the firm that has decided the control evidence matters more than the calendar.

If you are working through whether a specific workflow can meet these requirements, a 30-minute call is usually enough to tell. From there, a fixed-fee three-week discovery runs a prototype on your own data and produces the control documentation alongside it.