Is AI safe for client tax data?

The question gets asked as though it were new. It is not. The rules that govern who may touch a client’s return information, for what purpose, and on what terms were written for photocopiers and mailrooms and offshore data entry, and they apply to a language model without needing a word changed. What is new is that most firms have never had to read them closely, because the answer used to be obvious.

So the useful version of the question is narrower: what do the rules actually require, and what should a firm make a vendor prove? Below is the first part, with every authority linked, and then six questions worth asking, with the answers that should satisfy you and the ones that should not.

What section 7216 actually says

IRC section 7216 is a criminal statute. A person in the business of preparing returns who knowingly or recklessly discloses information furnished for the preparation of a return, or uses that information for any purpose other than preparing the return, is guilty of a misdemeanor: up to $1,000 and up to a year.

Two things about that sentence are usually missed. The first is that it has two halves. Disclosure is one offence and use is a separate one, and the use half does not require the information to leave the building. The second is that the criminal statute has a civil twin with no intent requirement at all: section 6713 imposes $250 per disclosure or use, to a cap of $10,000 a year, whether or not anyone meant to do it.

The subprocessor question, which is the one that matters

Most firms assume that putting return information into any outside system requires a signed consent. Usually it does not. Treasury regulation section 301.7216-2 lists eighteen categories of disclosure permitted without consent, and subsection (d) is the one that covers service providers: a preparer may disclose return information to another preparer located in the United States for services that do not involve substantive determinations affecting tax liability.

Read that twice, because both conditions do real work. Non-substantive assistance from a United States provider is permitted without consent. The same assistance from a provider outside the United States is not: it requires a consent under section 301.7216-3, and for the 1040 series that consent has a prescribed form and specific content requirements it must satisfy to be valid.

Which means the single most consequential fact about any vendor in this category is where the processing physically happens, and it is the fact vendors are least likely to state on a pricing page. “Cloud” is not an answer. Neither is the location of the company’s headquarters.

Training is a use, not a disclosure

This is where AI genuinely differs from the fax machine the rule was written around. If a vendor trains models on the returns your firm puts through it, that is a use of return information for a purpose other than preparing that return. The location exception does not reach it, because the location exception is about disclosure for permitted services. It needs consent, obtained in the prescribed form, before the fact.

A vendor that trains on customer data by default and mentions it in clause fourteen has not obtained anything. A firm that signs that contract has made a section 7216 problem for itself, not for the vendor, because the preparer is the one the statute binds.

Circular 230, which binds the firm rather than the software

Section 10.35 is titled Competence, and it requires that a practitioner have the knowledge and skill necessary for the matter. Nothing in it prohibits using a tool. It does mean that signing a return you cannot account for is a problem regardless of what produced it, and that a tool whose output you cannot check is a tool you cannot competently rely on.

Section 10.36 is the one firms overlook, and it is the more demanding of the two. It is titled Procedures to ensure compliance, and it puts the obligation on whoever has principal authority over the firm’s tax practice to take reasonable steps to ensure adequate procedures are in place across all members, associates and employees, and to correct promptly on discovering a pattern of noncompliance.

In plain terms: a partner cannot discharge this by trusting that staff are using the software sensibly. There has to be a procedure, it has to be real, and someone has to be watching whether it is followed. Software that produces no record of who accepted what makes that obligation impossible to satisfy and impossible to demonstrate afterwards.

The AICPA rule, which wants something in writing

The Confidential Client Information Rule at ET 1.700.001 bars disclosing confidential client information without consent. The interpretation that deals with vendors, ET 1.700.040, gives a member two routes when using a third-party service provider: obtain the client’s specific consent before disclosing, or enter into a contractual agreement with the provider requiring confidentiality and giving reasonable assurance the provider has procedures preventing unauthorized release.

Note that the second route is a contract, not a feeling. Reasonable assurance means you looked. Many firms handle the first route with a clause in the engagement letter, and the Journal of Accountancy’s treatment of the revised rule recommends doing both rather than choosing.

None of this prohibits AI

That is worth stating plainly, because the compliance literature in this category tends to imply otherwise and then sell a solution. Section 7216 permits disclosure to a United States provider for non-substantive assistance without any consent at all. Circular 230 asks for competence and procedure. The AICPA asks for consent or a contract. All three are satisfiable. They are conditions, not a prohibition, and a firm that meets them is on solid ground.

What none of them tolerate is a system nobody can account for. Every one of these rules, read together, points at the same requirement: you have to be able to say where a number came from and who accepted it.

Six questions to put to a vendor

With the answer that should satisfy you, and the one that should not.

1. Where is our data processed, physically?

Good: a named country, and named subprocessors, in writing. Not good: “the cloud”, “we use enterprise providers”, or an answer about where the company is incorporated. This determines whether you need a section 7216 consent at all, so a vendor who cannot answer it precisely has told you they have not thought about the statute.

2. Do you train models on our clients’ data?

Good: no, stated in the contract rather than the marketing site, including for the underlying model provider. Not good: “we use it to improve the service”, or an opt-out you have to find. Training is a use under section 7216 and the consent has to come first.

3. Show me where this number came from.

Ask them to demonstrate it on a real document, not describe it. Good: a click that lands on the page and the box the figure was read out of. Not good: a confidence score, a list of documents the system consulted, or an explanation of the model. A score is the software grading its own work.

4. What happens when it is not sure?

Good: it stops and asks, and the stopping is visible in the record. Not good: it picks the most likely answer and flags it for later. Ask specifically what happens when a new document contradicts something already on file, because that is the case where confidence is irrelevant and a system that resolves it silently will do so on the facts you most needed to see.

5. Who inside our firm can see which clients?

Good: the boundary is enforced in the database, and the same boundary applies to the automated work. Not good: permissions are checked in the application. The distinction is not pedantic: an application-layer check is one bug away from being bypassed, and it does not constrain an agent whose instructions can be influenced by the contents of a document it reads.

6. What is in writing, and what has been audited?

Good: a data processing agreement with confidentiality obligations, plus a straight answer about certifications, including the ones they do not hold. Not good: a SOC 2 badge on the marketing site with no report available, or a Type I described as though it were a Type II. ET 1.700.040 wants a contract and reasonable assurance, and a badge is neither.

How we answer them

It would be dishonest to publish that list without answering it, so: processing is in the United States; we do not train on client data and the contract says so; every figure traces to the region of the page it was read from and to the person who accepted it; the system stops rather than guessing, and a value that contradicts what is on file is never applied without a human deciding which one wins; the boundary between clients is row-level security in the database rather than checks in our code, and the agents run under a person’s identity rather than above it, so an agent cannot reach what its operator cannot.

On the sixth: we hold no SOC 2 Type II report. We are not audited yet. That is the honest answer to our own question, and a firm that decides that disqualifies us for now is applying the checklist correctly. Our privacy page states the rest of the arrangement, and the about page lists what else does not exist yet.

This is not legal advice.It is a reading of published authority, linked so you can check it, and the regulations change. A firm’s own counsel and its professional liability carrier are the people to clear a specific arrangement with, and the section 7216 consent requirements in particular have formal content rules this page does not reproduce.