← Back to blog
TaxJune 17, 2026

How I think about §7216 and AI on tax work

I went down this rabbit hole after a string of conversations with other CPAs and accountants, and I want to share how I have come to think about it. Not as a definitive answer, there is not one yet, but as one practitioner's working view.

This is general educational commentary, not legal or tax advice, and it creates no client or advisory relationship. There is no AI-specific §7216 guidance from Treasury or the IRS, so everything here applies existing rules that reasonable people can read differently. §7216 is a criminal statute. Confirm anything you rely on with your own attorney and malpractice carrier.

With that said: most firms adopting AI skip the one rule that carries criminal exposure for a preparer, and the engagement letter they think covers them usually does not.

What §7216 is

§7216 is a federal criminal statute: a misdemeanor (up to a year and a $1,000 fine per violation) for a preparer to knowingly or recklessly disclose, or use for anything other than preparing the return, information furnished in connection with preparing it. §6713 is the parallel civil penalty, $250 per disclosure or use up to $10,000 a year, with no intent requirement. (The $100,000 figure that floats around is identity-theft-specific, not the general penalty.)

Two definitions are broader than people expect. Tax return information includes what the client gives you and what you derive or generate from it, so prompts, extracted fields, summaries, and AI output built from return data are all still protected. Tax return preparer includes software developers and auxiliary-service vendors, so a vendor that receives return data in a covered role is itself treated as a preparer.

The real question is the data flow, not "is it AI"

For any AI use, I ask four things:

  1. Does the return information leave my environment?
  2. Who receives it?
  3. Where are they located?
  4. What do they do with it?

There is no "AI exception." The exceptions are role-based and purpose-based.

How the tool is set up decides almost everything

The way I read it, tools fall into three tiers:

  • Internal / self-hosted. The model runs entirely inside your environment and no return information goes to an outside party. That is not a disclosure at all, just internal use for preparation. Cleanest case. (One watch-out: training or tuning a shared internal model on client data can become a separate "use" problem.)
  • Enterprise with zero data retention, a DPA, and no training. This moves you out of the public-AI risk bucket, but it is still a third-party disclosure. Transmitting return information to the vendor is the disclosure; zero retention and no-training make it defensible, they do not make §7216 disappear. You still need a §301.7216-2 basis: the vendor doing auxiliary, prep-support work (extraction, OCR, classification, formatting, e-file, software support), not substantive tax determinations, in the U.S., with no reuse.
  • Public / consumer AI. Personal accounts, no firm DPA, default retention, possible training or staff review. Putting client return information here is hard to defend as a permitted disclosure. An IRS Office of Professional Responsibility ethics webinar called uploading client information into public AI a disclosure. Presume not allowed without consent.

The line that governs the middle tier: auxiliary, ministerial work is defensible without consent. The moment the tool makes substantive determinations, analyzing or applying tax law to decide the liability, the no-consent theory weakens or disappears, and you need consent or a human-only step.

"No training" is not "zero retention" is not "no disclosure"

These get conflated constantly and solve different problems. No training limits the vendor reusing your data. Zero data retention limits stored logs, and often applies only to specific endpoints (files, threads, assistants, vector stores, batch jobs can still retain state, so verify it for the features you actually use). A DPA gives contractual confidentiality. U.S. residency avoids the offshore trigger. Only fully internal or self-hosted avoids "disclosure" altogether.

Disclosure to clients vs §7216 consent

Do not conflate these. §7216 consent is legally required only if the use falls outside a §301.7216-2 exception. A "we use AI" line in the engagement letter is not, by itself, required by §7216 when the use is permitted, and it does not function as consent. Disclosing your AI use to clients is good risk management regardless.

When consent is required (Reg. 301.7216-3, Rev. Proc. 2013-14), the format is exacting: obtained before the disclosure, affirmative, signed, and dated (opt-out is invalid); use and disclosure consents on separate documents; for 1040 clients a separate signed document in the mandated format, not buried in the engagement letter; for business entities it can sit in the engagement letter with the required elements. If you use legacy "§7216 consent" templates, confirm the language is current (Rev. Proc. 2013-19 transitioned the 2013-14 language).

Offshore is broader than "where is the server"

Offshore disclosures trigger consent and special SSN rules, and the regs read offshore broadly: foreign remote access to data sitting on a U.S. server counts as an offshore disclosure. A U.S.-hosted tool with offshore support or engineering staff who can reach the data can still trip it. For a 1040 filer's SSN going offshore, the conditions are heavily restrictive.

Redaction and prompt hygiene

Stripping names, SSNs, and account numbers is genuinely valuable, central to the FTC Safeguards Rule, big for breach exposure, and near-mandatory if SSNs would otherwise go offshore. But it is risk-reduction, not a §7216 escape hatch: because tax return information includes derived data, de-identified inputs from the engagement can still be protected. Make it a default, not a one-off. "Prompt hygiene" means leading with sanitized fact patterns instead of identifiers: prompt with "taxpayer has W-2 wages of $X and a K-1 showing $Y," not the client's name, SSN, or the source document itself.

§7216 is not the only rule

When you put client data into an AI tool, several obligations can attach at once. §7216 is just the one with criminal teeth.

  • FTC Safeguards Rule / IRS WISP. You are a GLBA "financial institution," so the AI vendor is a service provider you must vet, bind by contract, encrypt data with, and assess inside your written information security program (IRS Pubs 4557 and 5708). A consumer free-tier tool with no such terms generally cannot satisfy this.
  • AICPA Confidentiality Rule (ET §1.700.001). Separate from §7216: before confidential client information reaches a third-party AI vendor, you need either the client's consent or a confidentiality agreement (DPA) with the vendor. So even where a §7216 exception applies, this rule still calls for consent or a DPA.
  • Revised SSTS (effective Jan 1, 2024). Binding on AICPA members. §1.4 (Reliance on Tools) says you retain all professional obligations and remain responsible for the completed work product whether or not you used AI; §1.3 (Data Protection) pulls the Safeguards and WISP duty into the ethics standard. You are always the reviewer of record.
  • Circular 230. A general competence duty (§10.35) and due diligence apply now. A proposed amendment (REG-116610-20) would add explicit technological-competence and data-security duties, but it is proposed, not final.
  • State law. California treats a §7216 violation as a state Tax Preparers Act violation; New York's SHIELD Act and Massachusetts 201 CMR 17.00 add safeguarding duties. And your state board may pull the AICPA Code and SSTS into your license (Georgia's Rule 20-12-.19 does exactly that) and impose its own confidentiality duty (Georgia Rule 20-12-.11).
  • Attest work (SSARS / GAAS). If you do compilations, reviews, or audits, AI output is audit evidence under AU-C 500, with the same reliability and documentation duties, and the CPA stays responsible.

Before I would approve an enterprise AI tool for client data

I want written confirmation of: no training or model improvement on prompts, files, outputs, or embeddings; true zero (or minimal, approved) retention for the specific features used; U.S.-only processing and access; no client data passed to un-vetted downstream tools; confidentiality and subprocessor terms fit for return information; vendor-personnel access restrictions and §7216/§6713 notice where contractors can see data; use limited to serving the firm; and a human CPA, not the AI, making the final substantive call.

The one question

AI is not a blanket permitted use, and it is not categorically banned. The question is always: who got the data, for what function, where were they located, what did they do with it, and was it limited to preparing the return? Self-hosted is cleanest. Enterprise with zero retention, a DPA, U.S. processing, non-substantive use, and no reuse is often defensible without consent, but it is still a disclosure, so the exception has to actually fit. Public AI with client data is consent-or-don't. Get a separate signed consent for 1040s when you step outside the lanes. And when it is genuinely unclear whether an exception applies, the conservative default is to treat the transmission as requiring consent rather than arguing your way into the exception.

Sources

Disclaimer: general educational commentary from one practitioner, not legal or tax advice, and reading it creates no client or advisory relationship. §7216 is a criminal statute, its consent requirements are prescribed by regulation, and there is no AI-specific guidance, so this applies existing rules that reasonable people may read differently. Confirm any approach against current authority and with your own attorney and malpractice carrier before relying on it.