Using AI in a Tax Practice Without Breaking IRC §7216 (Form 7216, Rev. Proc. 2013-14, and Practical Guardrails)

Adam Tahir
April 22, 2026

Tax professionals are moving quickly to adopt AI tools, research assistants, document summarizers, data extractors, and workflow copilots. The tax law, however, has long treated taxpayer data as highly restricted in the hands of a return preparer. If your firm uses AI in any way that involves taxpayer tax return information (TRI), you need a defensible IRC §7216 compliance position.

This post explains (1) why AI tools can trigger IRC §7216, (2) when Form 7216 consents become relevant, and (3) how Rev. Proc. 2013-14 and Rev. Proc. 2013-19 fit into the consent rules for Form 1040-series clients.

Key takeaway: AI doesn’t create a special exception. If TRI is transmitted to an AI vendor, that is often a “disclosure” under the regulations unless a specific exception applies or the taxpayer has provided a compliant written consent.

Internal revenue service

What IRC §7216 regulates (and why AI workflows can implicate it)

IRC §7216 makes it a criminal offense for a tax return preparer to knowingly or recklessly disclose or use information furnished for return preparation for any purpose other than preparing (or assisting in preparing) the return, unless authorized by the Code or regulations. (IRC §7216(a).)

The Treasury Regulations make the definitions intentionally broad:

  • “Disclosure” means “the act of making tax return information known to any person in any manner whatever.” (Treas. Reg. §301.7216-1(b)(3).)
  • “Use” includes “any circumstance in which a tax return preparer refers to, or relies upon, tax return information as the basis to take or permit an action.” (Treas. Reg. §301.7216-1(b)(4).)

Why this matters for AI: If your staff paste client facts, source documents, or return data into an AI system and that system is operated by a third-party vendor your firm has typically made TRI known to another person (the vendor and potentially its subprocessors). Under the regulatory definition, that transmission is generally a disclosure. (Treas. Reg. §301.7216-1(b)(3).)

Separately, if your team relies on AI output derived from TRI to prepare the return, draft planning deliverables, or take other actions, that can also be a use of TRI under the regulations. (Treas. Reg. §301.7216-1(b)(4).)

The default rule: no disclosure/use without an exception or a compliant consent

The compliance “gate” is straightforward:

  • If a disclosure or use of TRI is specifically authorized (generally under Treas. Reg. §301.7216-2), it may be done without taxpayer consent.
  • Otherwise, a preparer generally must obtain a written consent that meets Treas. Reg. §301.7216-3. (Treas. Reg. §301.7216-3(a).)

Treas. Reg. §301.7216-3 is explicit that, unless authorized, a preparer may not disclose or use TRI prior to obtaining written consent that satisfies the regulation. (Treas. Reg. §301.7216-3(a).)

Practical implication: AI adoption should start with mapping whether you are relying on a clear regulatory authorization (exception) or whether you need a consent process.

AI use cases: the fork that drives your §7216 posture

A helpful internal framework is to classify AI usage into three buckets:

Bucket A — Return preparation / “auxiliary services”

Examples:

  • summarizing organizer responses and source documents
  • extracting values from K-1s, 1099s, brokerage statements
  • drafting workpaper narratives and technical research outlines

These use cases are closest to “prepare/assist in preparing” a return under IRC §7216(a). But that does not automatically resolve the disclosure question if TRI is being sent to a third-party AI vendor. Whether a no-consent exception applies depends on facts and the specific exception you intend to rely on (Treas. Reg. §301.7216-2).

Conservative practice approach: If exception applicability is unclear, treat the AI transmission as requiring a compliant consent under Treas. Reg. §301.7216-3.

Bucket B — Firm operations / internal productivity

Examples:

  • workflow tracking, scheduling, generic process documentation
  • internal policy drafting (without client data)

Best practice is to keep TRI out of these systems entirely. Once TRI enters the workflow, you’re back in the §7216 analysis.

Bucket C — Marketing, cross-sell, analytics, vendor product improvement

Examples:

  • using TRI to generate marketing prompts, offers, and outreach
  • feeding TRI into tools used to develop or train products/models
  • sharing TRI for non-return-prep business purposes

These are the classic “other purpose” scenarios. They typically require a specific written consent that satisfies Treas. Reg. §301.7216-3 (and, for individuals, the additional rules discussed below).

Where Form 7216 fits (and why Rev. Proc. 2013-14 matters for 1040 clients)

The core consent rule

When consent is required, Treas. Reg. §301.7216-3 sets baseline content requirements for written consents (including identification of the taxpayer and preparer, description of the TRI, purpose/recipient or use, and signature/date). (Treas. Reg. §301.7216-3.)

Additional rules for Form 1040-series taxpayers

For taxpayers filing Form 1040-series returns, Treas. Reg. §301.7216-3 authorizes the IRS to impose additional consent requirements via published guidance.

That is where Rev. Proc. 2013-14 comes in: it provides guidance on the format and content of consents for Form 1040-series taxpayers and includes specific requirements for electronic signatures. (Rev. Proc. 2013-14, 2013-03 I.R.B. 223.)

Why this matters for AI tools: Many AI workflows use online portals, click-through consents, or e-signature processes. If you’re obtaining consent electronically for individual clients, your process should be designed to meet the Rev. Proc. 2013-14 requirements.

Rev. Proc. 2013-19: the transition rule (historical but still relevant to template hygiene)

Rev. Proc. 2013-19 modified Rev. Proc. 2013-14 by extending the effective date/transition period for the mandatory consent language. It allowed use of prior mandatory language during calendar year 2013, but required the Rev. Proc. 2013-14 language beginning January 1, 2014. (Rev. Proc. 2013-19, 2013-12 I.R.B. 556.) Practical takeaway: If your firm is using legacy “7216 consent” templates, confirm they are not frozen in older language frameworks and that they reflect the post-transition requirements.

A practical AI + §7216 compliance checklist for tax firms

Below is a defensible starting point for most firms:

1) Map your AI data flows

Document each workflow:

  • What data goes in (text prompts, PDFs, CSVs, screenshots)
  • What comes out (summaries, extracted fields, advice drafts)
  • Who receives or can access it (vendor, subprocessors, internal teams)
  • Whether the vendor retains, logs, or reuses data

2) Minimize TRI by policy

Adopt “prompt hygiene” rules:

  • Don’t input SSNs, DOBs, full addresses, or unnecessary identifiers unless you have a documented authorization/consent position.
  • Prefer sanitized fact patterns when feasible (e.g., “taxpayer has W-2 wages of $X and Schedule C income of $Y”).

3) Vendor governance: contract terms should match your tax position

For any third-party AI system that may receive TRI, the firm should seek:

  • restrictions on vendor “independent use” of inputs/outputs (including training or product improvement) unless you have specific, compliant consents
  • strict confidentiality and limits on onward disclosure/subprocessors
  • retention limits and deletion/return commitments
  • clarity on role as a service provider supporting your permitted purpose

4) Decide when consents are required—and standardize the package

When you determine a consent is required:

  • use a consent that satisfies Treas. Reg. §301.7216-3
  • for Form 1040-series clients, ensure the consent process aligns with Rev. Proc. 2013-14, including e-signature requirements (Rev. Proc. 2013-14)

5) Train staff and implement escalation triggers

Your strongest policy is often operational:

  • what counts as TRI in practice
  • what is prohibited to paste/upload
  • which tools are approved
  • when a workflow needs review for exception/consent treatment

Two questions to ask before you send TRI to any AI tool

1) Does the vendor contractually commit to not using your inputs/outputs for its own purposes (including training) and to apply retention/deletion limits consistent with your intended use?

2) What exactly are you transmitting, client identifiers and full source documents, or sanitized tax attributes needed for a narrow return-prep task?

The answers often determine whether you can support a “return-prep auxiliary service” posture or whether you should implement a formal consent process.

Bottom line

AI tools can deliver real productivity gains, but IRC §7216 and Treas. Reg. §§301.7216-1 through -3 still define the compliance boundary. Because “disclosure” and “use” are broad, sending TRI to an AI vendor is often treated as a disclosure unless a specific authorization applies or the taxpayer has provided a compliant written consent. (IRC §7216(a); Treas. Reg. §301.7216-1(b)(3), (4); Treas. Reg. §301.7216-3(a).)

For individual clients, if consent is required, ensure your process meets the additional consent requirements under Rev. Proc. 2013-14, and confirm you’re not relying on outdated transition-era language addressed in Rev. Proc. 2013-19. (Rev. Proc. 2013-14; Rev. Proc. 2013-19.)

‍