A partner watches a demo of an AI research tool, gets excited, and asks the one question that actually matters: can I put a client's return into this thing? It is the right question, and it does not have a one-word answer. Using AI with client tax data is governed by two separate bodies of federal law, and neither one cares how impressive the demo was.
The first is Section 7216, which controls the disclosure and use of taxpayer information. The second is the FTC Safeguards Rule, which controls how you secure the data you hold. On top of both sits a layer of state law with its own security and breach-notification requirements.
Here is the short version before the long one. The trigger is not whether a client's name is attached. It is whether the facts you are typing were furnished or derived in connection with preparing the client's income tax return. Genuinely general or hypothetical research is clean. The moment the prompt is built from a specific client's return or return-preparation process, you are in Section 7216 territory whether or not you stripped the identifiers. From there, permissibility turns on the recipient, the service performed, where access occurs, whether an exception or valid consent applies, and the vendor's actual data practices.
Think of these as two different questions.
Section 7216 asks whether you are allowed to send the data out at all. It is about disclosure and use. The penalties are not theoretical. Under Treasury Regulation Section 301.7216-1, a preparer who knowingly or recklessly makes an unauthorized disclosure or use commits a criminal misdemeanor carrying up to one year of imprisonment, a fine of up to $1,000, or both. The civil companion at Section 6713 adds a penalty of $250 per prohibited disclosure or use, capped at $10,000 per calendar year.
The Safeguards Rule asks whether you are protecting the data you hold. It requires a written information security plan and governs the full data lifecycle, from how you store client files to how you vet the vendors who touch them.
These are not sequential, and clearing one does not clear the other. The regulation says so directly: Section 301.7216-1(c) provides that the Gramm-Leach-Bliley Act and Section 7216 each apply on their own terms, and neither overrides the other. An AI workflow can satisfy one and flunk the other. You have to clear both.
Start with what the statute actually protects, because this is where most firms guess wrong.
Tax return information is defined by origin, not by identifiability. Under Section 301.7216-1(b)(3), it means any information furnished for, or in connection with, the preparation of a taxpayer's income tax return, plus anything the preparer derives from that information in the course of preparing the return. The regulation drives the point home: tax return information includes statistical compilations "even in a form that cannot be associated with, or otherwise identify, directly or indirectly, a particular taxpayer."
Read that twice. Anonymizing does not launder client data out of Section 7216. If the facts originated in return preparation, stripping the name does not make them fair game.
There are two real off-ramps in the regulation. Information obtained "otherwise than in connection with the preparation of a tax return" is not tax return information, under Section 301.7216-1(b)(3)(C). And the regulation applies a "but for" test: information is covered if the taxpayer would not have furnished it but for engaging you to prepare the return, under Section 301.7216-1(b)(3)(D). Together those define what the clean lane really is.
The flip side is that Section 7216 is about return preparation specifically. Information from bookkeeping, audit, or standalone consulting work is not automatically tax return information, though other confidentiality duties, including the AICPA Code of Professional Conduct and state accountancy rules, still govern it.
Now the disclosure trigger. Disclosure means making that information known to any person "in any manner whatever," under Section 301.7216-1(b)(5). Email, upload, paste into a prompt, an API call, a voice transcription. If client-derived data leaves your control and lands on a third party's server, that is a disclosure, and the tool's provider is the third party.
Here is the line drawn correctly.
A genuinely general research question, one you could have written without any client in front of you, discloses no tax return information. "How does the Section 174A transition rule apply to a calendar-year software developer with domestic research costs" is legal research. You could pose it from a textbook. Run it through whatever tool you trust.
Taking a specific client's file and deleting the name before you paste it is a different act. Those facts originated in return preparation, so they remain tax return information under the regulation's broad origin-and-derivation definition, with the statistical-compilation rule above confirming that anonymity does not change the answer. Sending them to a third-party tool is still a disclosure. De-identification lowers your privacy and re-identification risk, and it is good practice, but it is not a Section 7216 safe harbor.
The working rule: if you could have asked the question without the client, it is research. If the question exists only because you are preparing this client's return, treat it as a disclosure and clear it before you send it.
Suppose the prompt is built from a client's return. Now you need either an exception or a consent.
The exception practitioners reach for is the preparer-to-preparer auxiliary-services rule at Treasury Regulation Section 301.7216-2. It lets one preparer disclose tax return information to another preparer without consent, but it comes with two hard limits. The recipient must be located in the United States, and the services provided cannot be "substantive determinations or advice affecting the tax liability reported by taxpayers." The regulation defines a substantive determination as analysis, interpretation, or application of the law.
Read that against a research tool. A platform that interprets and applies the law to your client's specific facts is arguably doing exactly the substantive analysis the exception carves out. So a research tool fed with a client's facts probably cannot lean on this exception cleanly.
If no exception applies, you need consent. Under Section 301.7216-3 the consent must be knowing, voluntary, and obtained in writing before the disclosure happens. For clients who file in the Form 1040 series, the consent has to use the mandatory language in Revenue Procedure 2013-14 and name the specific provider. Switch providers later, and you need a fresh consent.
The decision logic in one place:
Authorization to send data is only half the problem. The FTC Safeguards Rule, issued under the Gramm-Leach-Bliley Act at 16 CFR Part 314, treats tax preparers as financial institutions and requires a written information security plan that runs across the entire data lifecycle. The amended rule also added a breach-notification obligation for certain incidents.
The IRS translates this into practitioner terms in Publication 4557, Safeguarding Taxpayer Data. It is the plain-language wrapper around the harder legal obligations and the practitioner-facing roadmap for implementing them. Publication 5708 gives you a WISP template built for tax and accounting practices, and Publication 5293 rounds up the data-theft resources.
For AI specifically, the provision that matters is service-provider oversight, and it is more than a signed order form. The rule requires you to select vendors capable of protecting the data, bind them by contract to do so, and then monitor and periodically reassess them. A SOC 2 report is useful evidence, but on its own it does not discharge the duty. An AI vendor is a service provider, and a clever tool does not earn a pass on the diligence.
Here is the part that reframes the whole question. The distinction that carries weight is not "purpose-built versus general." It is what happens to the data. A few features do most of the work:
Be precise about what these do. None of them is a legal safe harbor. Whether a given use is permissible still depends on the whole picture: the information, the purpose, the recipient, the service performed, the geography, whether an exception or a consent applies, and the security controls in place. What good terms buy you is the removal of the specific failure modes that make a free chatbot dangerous, plus the evidence you will want if anyone asks. Purpose-built tax platforms tend to be built with these features, which is what lets a firm use AI within the rules rather than around them. Your firm still owns its WISP, its vendor vetting, and any consent the facts require.
None of this touches the separate duty to stand behind what the tool produces. Clean data handling does not excuse blindly trusting a machine, a point the IRS Office of Professional Responsibility made in its guidance on responsible AI use. If you are still choosing a tool, our expert vetting criteria for AI tax software walks through what to demand, and why general chatbots fall short for tax work covers the accuracy half of the same problem.
For most tax firms, the operative security regime is the federal Safeguards Rule, because you are a GLBA financial institution. That status narrows your state-law exposure more than people expect. Many comprehensive state privacy statutes contain GLBA carve-outs, though their structure and scope vary. Virginia's VCDPA exempts financial institutions and GLBA-covered data outright at the entity level, under Va. Code Section 59.1-576, and California's CCPA and CPRA exempt GLBA-covered information, under Cal. Civ. Code Section 1798.145, leaving mainly the data-breach private right of action in play. So for individual client tax data, those two statutes largely do not add to your obligations.
Separate state security and breach-notification regimes can still apply. Massachusetts 201 CMR 17.00 imposes its own written information security program and service-provider oversight requirements, and it applies to any business holding a Massachusetts resident's personal information, with no revenue or headcount threshold. New York's SHIELD Actrequires reasonable administrative, technical, and physical safeguards, and it deems a firm that is subject to and in compliance with GLBA's data security requirements to satisfy that safeguards obligation, though New York's breach-notification rules apply on their own.
One caution. GLBA generally protects information about individuals who obtain financial products or services for personal, family, or household purposes. Information a firm holds for business or commercial clients can fall outside that coverage, and whether a state statute then applies depends on that statute's own scope. Map your data before you assume an exemption.
A word on the common "you inherit the strictest regime" shorthand. That is an operational choice, not a legal rule. Each law applies according to its own scope. Firms often standardize on the most demanding applicable standard across the whole practice, because running one security baseline is simpler than sorting every client by jurisdiction. That is sound management. Just do not mistake it for a statement of what each statute actually requires.
This is the workflow purpose-built tax platforms are designed around. Marble's Intelligence agent lets you research federal and state questions in plain English and get citation-backed answers that link straight to the underlying authority, which supports ordinary research in the general-question lane, and it runs on an enterprise security footing rather than consumer chatbot terms. It does not erase your WISP or your consent obligations, but it is built to remove the failure modes this post has walked through. Sign up for Marble.
Not by itself. Section 7216 is triggered when you disclose tax return information, which the regulation defines by where the information came from, not by whether a name is attached. A genuinely general or hypothetical research question discloses nothing. The exposure begins when the prompt is built from a specific client's return or return-preparation process, even if you removed the identifiers.
No. The regulation treats tax return information as covered even in a form that cannot identify the taxpayer, so anonymizing a client-derived fact pattern does not take it outside Section 7216. De-identification is good risk practice, but the question is origin. If the facts were furnished or derived in connection with preparing this client's return, treat sending them to a third-party tool as a disclosure and clear it first.
It depends on what you put in and which tool you use. If you disclose client tax return information to a third-party tool and no exception applies, you need written consent before the disclosure, and for Form 1040 filers it must use the mandatory language in Revenue Procedure 2013-14 and name the specific provider. If you later switch providers, you need a new consent.
No. The tool category does not create a legal exemption. Features like US-based processing and access, a no-training commitment, confidentiality, and a SOC 2 report are strong evidence and remove common failure modes, but none is a safe harbor on its own. Whether a use is permissible turns on the full picture, and your firm still owns its WISP, its vendor vetting, and any required consent.
Because tax firms are GLBA financial institutions, the big consumer-privacy statutes mostly exempt individual client tax data, though the carve-outs vary in structure. Virginia's VCDPA exempts GLBA entities outright, and California's CCPA exempts GLBA-covered information. Separate state security and breach-notification regimes also remain relevant: Massachusetts 201 CMR 17.00 imposes its own written-security-program and service-provider requirements, and New York's SHIELD Act deems GLBA-compliant firms to satisfy its safeguards obligation while keeping its breach-notification duties. Data held for business clients can fall outside GLBA, so map your data before relying on an exemption.
