← Back to the Library
Library · Guide

Module 6, Seven Things Accountants Get Wrong About AI & §7216

The honest premise. In rooms full of smart practitioners sharing AI wins, the compliance talk is where confident, wrong answers spread fastest, because nobody wants to be the one who slows down the demo. This module takes the most common claims you'll hear about AI and client-data rules and checks each against primary source. Every correction here traces to REGULATORY-FOUNDATION.md, which cites the statute, regulation, or IRS guidance behind it. Read GUARDRAILS.md first; this is the "but I heard…" companion.

The point isn't to make you afraid of AI. It's that being the practitioner who's actually right about this is cheap insurance, and right now the bar is low.


Myth 1, "If the AI tool is hosted in the U.S., §7216 doesn't apply."

What's actually true: U.S. data residency only solves one of §7216's triggers, the offshore-disclosure trigger. The disclosure itself happens the moment your firm transmits taxpayer return information (TRI) to the vendor, U.S. server or not. Hosting location does nothing about whether the vendor trains on your data, retains it, or makes substantive tax determinations, each of which is its own §7216 problem. Unless the model is fully self-hosted inside your firm, sending TRI to it is still a third-party disclosure that needs a §301.7216-2 basis (same-firm U.S. internal prep use, or a contract-bound U.S. auxiliary vendor), or written client consent.

Do this: Treat "U.S. hosting" as necessary-but-not-sufficient. Confirm the use fits a prep/ auxiliary exception, not just the server map.

Myth 2, "It's SOC 2 Type II certified, so client data is fine."

What's actually true: SOC 2 attests that a vendor follows its own stated security controls. It is not a no-training term, not a §7216 basis for your disclosure, and not proof the tool fits inside your WISP. A tool can be fully SOC 2 compliant and still train on your prompts, retain your files, or sit outside any contract you've signed. SOC 2 is a useful input to vendor vetting, it is not the answer to "may I put a client's return data here?"

Do this: Ask for the four things that actually matter (below), in writing. SOC 2 is one checkbox among them, not the whole list.

Myth 3, "We're on the enterprise plan with a data agreement, so we're compliant."

What's actually true: Enterprise / zero-data-retention (ZDR) terms make a disclosure far more defensible, they help show the vendor isn't making a prohibited independent use of the data. But ZDR does not make §7216 disappear. The disclosure still occurs on transmission, and you still need a §301.7216-2 basis for the disclosure itself. Four concepts get blurred together and shouldn't be:

Do this: Enterprise/ZDR is the right setup for routine client context, but match the use level to it (see Myth 5). Get written confirmation of: (1) no training on your inputs/outputs, (2) true ZDR for the specific features you use, (3) U.S.-only processing/access, (4) confidentiality + subprocessor terms, and log the tool in your WISP.

Myth 4, "We scrub the PII first, so there's nothing to worry about."

What's actually true: This is the best instinct in the room, if no TRI ever enters the tool, §7216 isn't implicated and you've removed the exposure at the source. Two cautions keep it honest: (a) §7216's definition of "return information" is broad, it includes data you derive from the return, not just names and SSNs, so true de-identification is harder than masking the obvious fields; and (b) manual redaction is error-prone, and a screenshot strips metadata but not the visible numbers on the page. Scrubbing is excellent when it's genuine and verified, not when it's a quick pass that leaves identifiable financial detail behind.

Do this: Use an offline scrubber (the library's redactor tool runs with no network) and spot-check the output before it goes anywhere. Treat "I redacted it" as a process you can defend, not a vibe.

Myth 5, "AI is basically the same as e-filing, we already trust software with this data."

What's actually true: It depends entirely on what the AI is doing, not that it's "software."

Do this: Sort every AI task into "clerical assist" vs. "substantive determination." The first is e-filing-like; the second needs consent-or-prohibit analysis and stays your judgment to make.

Myth 6, "The penalty exposure is $100,000, so this is existential."

What's actually true: The $100,000 figure is a myth for general violations, it applies only to identity-theft-related enhanced penalties under §6713(b). The actual general exposure:

This matters in both directions: don't catastrophize with a wrong number, and don't dismiss it, it's a criminal statute with your license and reputation attached, which is the real stake.

Do this: Quote the right figures. Being precise here is part of being the credible voice.

What's actually true: Even where a §7216 exception means no consent form is legally required, disclosing your gen-AI use to clients is sound risk management, AICPA/CNA guidance points this way, and it heads off the "you did what with my data?" conversation. Note also that two obligations sit next to §7216 and don't care about its exceptions: the AICPA Confidentiality Rule (ET §1.700.001) still requires client consent or a confidentiality agreement with the vendor, and for a Georgia CPA, Rule 20-12-.11 is an independent state-law confidentiality duty.

Do this: Add a short, plain-English AI-use clause to your engagement letters and use the §7216 consent template and AI Acceptable-Use Policy where they apply.


The four questions that cut through all seven myths

Before any client return data touches an AI tool, get written answers:

  1. Do you train on, fine-tune, or improve models from our inputs, files, outputs, or feedback? (Need: a clear no.)

  2. Is there true zero/minimal retention for the specific features we'll use, not just a marketing line? (Need: endpoint-specific yes.)

  3. Is processing and human access U.S.-only? (Need: yes, absent §7216 consent.)

  4. Will you sign a confidentiality agreement / DPA appropriate to taxpayer information, and disclose subprocessors? (Need: yes, this is your FTC Safeguards + AICPA Confidentiality basis.)

If you can't get those four, keep client-identifiable and return-derived data out of the tool, anonymize instead.


The one-line version

U.S. hosting, SOC 2, "enterprise," and "I scrubbed it" each solve part of the problem and none of them solve all of it. The disclosure happens when the data leaves your firm, so either it fits a prep/auxiliary exception, you have written consent, or no taxpayer data goes in. And every answer the AI gives is unverified until you check it against primary source.

15-minute starter

  1. Pick the one AI tool you (or your staff) most often paste client context into.
  2. Run it against the four questions above, pull the vendor's actual terms, not your assumption.
  3. Sort your top 3 AI uses into clerical-assist vs. substantive-determination (Myth 5).
  4. If anything in steps 2–3 comes back uncertain, switch that workflow to anonymized inputs (use redactor) until you've confirmed the terms, and note the tool in your WISP.

Companion to GUARDRAILS.md and REGULATORY-FOUNDATION.md. Every correction here is sourced there. This is an educational summary for AI Lab members, not legal advice, verify against primary source and your state board before relying on any point.

The AI Lab for Accountants · An educational resource, not legal or tax advice.