The decision to deploy an AI tool in a tax practice or financial institution that processes client tax return data is not primarily a technology decision. It is a compliance decision that simultaneously engages the Federal Trade Commission’s Safeguards Rule under the Gramm-Leach-Bliley Act, the criminal prohibition in Internal Revenue Code Section 7216, and the civil penalty structure in IRC Section 6713. Each framework operates independently, with different enforcement agencies, different penalty structures, and different standards of liability. Each can be violated by a single AI deployment decision made without adequate compliance architecture.

This article maps the three frameworks, explains where they intersect, and describes how the NIST AI Risk Management Framework provides a governance structure capable of producing defensible deployment decisions across all three simultaneously.

Framework One: The FTC Safeguards Rule Under GLBA

Who It Covers

The Gramm-Leach-Bliley Act requires that financial institutions — broadly defined — protect nonpublic personal information about customers. Tax preparation is classified as a financial activity under GLBA. This means that professional tax preparers, CPA firms offering tax services, accounting practices, and financial institutions providing tax assistance all qualify as “financial institutions” subject to FTC jurisdiction and the Safeguards Rule.

The breadth of this classification surprises many practitioners. A two-person CPA firm that prepares individual returns is a financial institution under GLBA. A law firm offering estate and gift tax preparation services is a financial institution under GLBA. Any entity that for compensation prepares returns — and that collects names, Social Security numbers, income data, or financial account information in doing so — falls under the Rule.

What the 2021 and 2023 Amendments Require

The Safeguards Rule was substantially amended in December 2021, with phased compliance deadlines extending through 2023. The 2023 amendment added a mandatory breach notification requirement, effective May 13, 2024.

Written Information Security Program (WISP). The Rule requires covered financial institutions to develop, implement, and maintain a comprehensive Written Information Security Program. The WISP must be calibrated to the institution’s size, complexity, and the nature of the customer information it holds. For AI deployment purposes, the WISP must specifically address the systems and processes through which customer nonpublic personal information flows — including AI systems that access, process, or analyze that information.

The WISP must include:

  • Designation of a qualified individual responsible for overseeing and implementing the information security program
  • A written risk assessment identifying reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information
  • Access controls limiting access to customer information to those who need it to perform their job functions
  • Encryption of customer information in transit and at rest
  • Multi-factor authentication for any individual accessing customer information systems (with limited exceptions for documented alternative compensating controls)
  • Secure development practices for applications that access or transmit customer information
  • Vendor oversight provisions for any service providers that access, maintain, or process customer information on the institution’s behalf
  • An incident response plan
  • Annual reporting to the board or senior officer on the information security program’s status

Breach notification. As of May 13, 2024, the Rule requires covered financial institutions to notify the FTC within 30 days of discovering a notification event — defined as unauthorized acquisition of unencrypted customer information involving at least 500 customers. This notification obligation operates on a parallel but distinct timeline from HIPAA (where applicable) and state breach notification laws.

Penalties. The FTC can impose civil penalties of up to $50,120 per violation under current inflation adjustments. Each day of noncompliance with a final order constitutes a separate violation. More consequentially, a failure to implement a required Safeguards Rule element — an absent WISP, an absent risk assessment, or an absent vendor oversight program — can constitute a separate per-element violation.

What the Safeguards Rule Requires for AI Systems

The Rule does not enumerate AI systems specifically, but its requirements apply to any system that processes customer nonpublic personal information. When a covered financial institution deploys an AI tool that accesses or processes tax client data, the following Safeguards Rule elements are activated:

The WISP must address the AI system. The written security program must identify the AI system as a component of the institution’s information security infrastructure, describe the controls governing its access to customer information, and document the risk assessment supporting its deployment.

The risk assessment must evaluate AI-specific risks. The required written risk assessment must evaluate the likelihood and potential impact of threats specific to the AI system — including model behavior that results in unauthorized disclosure, training data that incorporates customer information without consent, prompt injection attacks that cause the model to exfiltrate information, and vendor-side risks from cloud-hosted AI infrastructure.

Vendor oversight applies to AI providers. If the AI tool is provided by a third-party vendor — an LLM API, a tax software provider with embedded AI features, or a cloud AI platform — the vendor oversight provisions require the institution to assess the vendor’s security posture, impose contractual security obligations, and periodically review vendor compliance. An AI vendor that processes customer tax data on behalf of the institution is a service provider under the Safeguards Rule, and the institution’s security obligations extend to that relationship.

MFA governs access to AI systems touching customer data. Any AI system that accesses or processes nonpublic personal information must be protected by multi-factor authentication for individuals accessing it. This applies to the interface through which employees interact with the AI tool, not just the underlying data systems.

Framework Two: IRC § 7216 — The Criminal Prohibition

What Section 7216 Prohibits

Internal Revenue Code Section 7216 is a federal criminal statute. It prohibits any person engaged in the business of preparing tax returns, or providing services in connection with the preparation of tax returns, from knowingly or recklessly disclosing any information furnished to them for, or in connection with, the preparation of a return. It also prohibits knowingly or recklessly using any such information for any purpose other than to prepare, or assist in preparing, a tax return.

The penalty for a Section 7216 violation is a fine of up to $1,000 and/or imprisonment of up to one year. If the disclosure or use is made in connection with a crime involving identity theft, the maximum fine increases to $100,000.

These are criminal penalties. A tax preparer who violates Section 7216 is subject to criminal prosecution, not merely civil enforcement. The “knowing or reckless” standard means that a preparer who carelessly handles client information — without intending to disclose it — can still face criminal liability if the carelessness rises to recklessness.

The Permitted Use and Disclosure Framework

Section 7216 does not prohibit all uses of tax return information. The statute delegates to Treasury the authority to publish regulations specifying permitted disclosures and uses — those that may occur without taxpayer consent — and those that require consent. The governing regulations are at 26 CFR §§ 301.7216-1 through 301.7216-3, substantially revised in 2008 and further updated since.

Uses permitted without taxpayer consent include: use within the same firm for purposes of tax return preparation; disclosures required by law; disclosures to the IRS; use for quality or peer review; and limited use for administrative purposes directly related to preparing the return.

Uses and disclosures requiring taxpayer consent include: disclosure to third parties not involved in the preparation; use for marketing, advertising, or solicitation; disclosure to other professionals for purposes unrelated to tax preparation; and — critically for AI deployment purposes — use by any system or service provider that processes return information for purposes beyond direct return preparation.

The consent requirement for third-party processing is the critical provision for AI deployment decisions. A cloud-based AI tool that receives tax return data as input is, in most configurations, a third-party processor operating outside the narrow permitted-use categories. Unless the taxpayer has provided valid consent under the Section 7216 regulations, routing their return data to that system constitutes a potential criminal violation.

AI and the Section 7216 Risk

The Section 7216 risk in AI deployment is not theoretical. It arises from operational patterns that tax firms adopt without adequate legal review:

Copy-pasting client data into public AI tools. An employee who copies a client’s financial information, income data, or prior-year return information into ChatGPT, Claude, Gemini, or any publicly accessible LLM interface is disclosing that information to a third party — the AI provider — without taxpayer consent. The regulations do not recognize “employee convenience” as a permitted use. The recklessness standard is easily met when a firm lacks any policy governing AI tool use.

Using AI-assisted tax software that sends data to cloud infrastructure. Tax software providers increasingly embed AI features — automated return drafting, anomaly detection, intelligent document extraction — that involve sending client data to cloud-hosted models operated by the software vendor or its subprocessors. If the software vendor is not operating as a “limited purpose processor” under a documented arrangement that restricts use solely to return preparation, and if the taxpayer has not consented to that processing, the data routing may violate Section 7216.

Training or fine-tuning models on client return data. Using historical client return data to train, fine-tune, or improve an AI model — even internally — is a use of tax return information for a purpose other than preparing a return. Without explicit taxpayer consent, this use is prohibited under Section 7216.

Storing prompts that include client information in logged systems accessible to the AI vendor. Prompt logs, conversation histories, and model inputs retained by an AI provider constitute disclosure of that information to the provider. If the provider’s data handling terms do not restrict use to return preparation purposes, the logging constitutes an impermissible disclosure.

For AI deployments that require taxpayer consent under the Section 7216 regulations, the consent must meet specific requirements: it must be a separate written document or electronic equivalent; it must be signed and dated by the taxpayer; it must identify the intended recipients or class of recipients of the information; it must identify the specific information to be disclosed or used; it must state the purpose for which the information will be used; and it must include a disclosure that the taxpayer is not required to provide consent.

Consent buried in a general engagement letter, included as a checkbox in onboarding flow alongside other disclosures, or obtained through a blanket “data processing” authorization does not satisfy the Section 7216 requirement. The consent must be specific, standalone, and informed.

Framework Three: IRC § 6713 — The Civil Penalty Companion

The Structure of Section 6713

IRC Section 6713 is the civil penalty counterpart to Section 7216’s criminal prohibition. Where Section 7216 requires knowing or reckless conduct for criminal liability, Section 6713 imposes civil penalties for unauthorized disclosures or uses of tax return information without any mens rea requirement — there is no knowledge or recklessness standard. The violation is established by the disclosure or use itself, regardless of intent.

The penalty structure is:

  • Standard violations: $250 per unauthorized disclosure or use, with a maximum of $10,000 per calendar year per person
  • Identity theft-related violations: $1,000 per unauthorized disclosure or use, with a maximum of $50,000 per calendar year per person

The $10,000 annual cap is misleading as a risk management figure. In an AI deployment context — where a single misconfigured integration could route every client file through an unauthorized channel — the number of discrete disclosures can be enormous. A firm with 2,000 clients whose data flows through a non-compliant AI system has potentially committed 2,000 separate violations, each at $250, subject only to the calendar year cap. In successive calendar years, the cap resets.

More practically: the Section 6713 framework applies to operational failures that do not rise to criminal recklessness but that nonetheless represent routine noncompliance. The employee who consistently uses an unauthorized AI tool for client work may not be criminally reckless under Section 7216 but is almost certainly generating Section 6713 violations with each use.

The Parallel Exposure

A single AI deployment failure can simultaneously expose the institution to:

  • FTC enforcement under the Safeguards Rule for failure to implement adequate vendor oversight or risk assessment controls
  • Section 7216 criminal exposure for knowing or reckless disclosure
  • Section 6713 civil penalties for each unauthorized disclosure regardless of intent

These enforcement pathways are independent. The IRS enforces Sections 7216 and 6713; the FTC enforces the Safeguards Rule. A settlement with one agency does not resolve obligations to the other. An institution that remediates its Safeguards Rule compliance program in response to an FTC inquiry still faces Section 7216 and 6713 exposure for the period of noncompliance — and vice versa.

Framework Four: The NIST AI Risk Management Framework as the Governance Architecture

Why the NIST AI RMF Is the Right Tool

The NIST AI Risk Management Framework, published in January 2023 with a Generative AI Profile supplement (NIST-AI-600-1) released in July 2024, provides a voluntary but increasingly operationally necessary governance architecture for organizations making AI deployment decisions. The U.S. Treasury’s adaptation of the NIST AI RMF for financial services — developed with more than 100 financial institutions — translates the framework’s four core functions into 230 specific control objectives applicable to financial sector AI deployments.

For institutions navigating the Safeguards Rule, Section 7216, and Section 6713 simultaneously, the NIST AI RMF provides the governance structure to:

  • Document the risk assessment required by the Safeguards Rule before deploying any AI system touching customer data
  • Identify whether a proposed AI deployment falls within Section 7216’s permitted use categories or requires taxpayer consent
  • Establish vendor oversight controls that satisfy both the Safeguards Rule’s service provider requirements and Section 7216’s third-party processing standards
  • Create the contemporaneous documentation necessary to demonstrate compliance with all three frameworks if regulators inquire

The Four Core Functions and Their Compliance Mapping

GOVERN. The AI RMF’s Govern function establishes the organizational structures, policies, and accountability mechanisms that make AI deployment decisions consistent and defensible. In the context of tax firm or financial institution AI deployment, Govern maps directly to the Safeguards Rule’s requirement for a designated qualified individual responsible for the information security program. This person — or their delegate — must own AI governance decisions, including the determination of which AI deployments are permissible under Section 7216 without consent and which require consent architecture to be built.

Govern also requires establishing an AI use policy that specifies approved tools, prohibited configurations, and the review process for new AI deployment decisions. Absent this policy, individual employees make ad hoc decisions — including the decision to paste client data into a public LLM — that generate Section 6713 liability the firm has no visibility into.

MAP. The Map function identifies the contexts in which AI is deployed, the data the AI system uses, and the potential harms that could result. For tax firm AI deployments, Map is the risk assessment function required by the Safeguards Rule. It should produce a documented inventory of:

  • Which AI systems the firm uses or is evaluating
  • What categories of tax return information each system accesses
  • Whether each system operates within Section 7216’s permitted use categories or requires taxpayer consent
  • What the firm’s AI vendor processes data for, under what contractual terms, and whether those terms restrict use to return preparation purposes
  • What the potential harm is if a given AI system discloses or misuses client return data — including the Section 7216 criminal exposure, Section 6713 civil penalty exposure, and Safeguards Rule enforcement exposure

MEASURE. The Measure function assesses AI risks against defined criteria and tracks compliance with established controls. For the three-framework intersection, Measure should include:

  • Regular testing of AI systems to confirm that client data does not leave the firm’s environment through unauthorized channels
  • Monitoring of AI vendor data handling practices, including review of vendor terms of service, data processing agreements, and subprocessor lists for changes that affect Section 7216 compliance
  • Logging of AI system access and activity sufficient to support a Section 6713 per-disclosure analysis if a violation is alleged
  • Annual review of the firm’s AI deployments against the current version of the WISP to confirm alignment

MANAGE. The Manage function implements risk treatments — accept, mitigate, transfer, or avoid — for identified AI risks. For the three-framework intersection, Manage defines the decision architecture for each identified AI deployment:

Deployments within Section 7216 permitted uses: If the AI system is operated solely within the firm, accesses client data only for the purpose of preparing returns, and does not transmit data to third-party infrastructure, it may operate within the statutory permitted use framework without taxpayer consent. Manage documents this determination and the controls that keep the deployment within those boundaries.

Deployments requiring Section 7216 consent: If the AI deployment routes client data to a third-party vendor or uses it for purposes beyond return preparation, Manage establishes the consent collection process — standalone written consent documents, specific to the data and purpose, satisfying the regulatory requirements — before the deployment goes live.

Deployments that cannot be made compliant: If an AI tool routes client data to a model provider that retains inputs for training, uses data for product improvement, or otherwise processes it for purposes inconsistent with Section 7216 permitted uses — and if the consent architecture cannot be practically implemented for all affected clients — the appropriate Manage outcome is to not deploy the tool. The NIST AI RMF explicitly encompasses avoidance as a legitimate risk treatment.

The Generative AI Profile and Tax Return Data

NIST-AI-600-1, the Generative AI Profile, identifies twelve unique risks associated with generative AI systems that the base RMF did not specifically address. Several are particularly relevant to tax return data:

Data privacy. The GenAI Profile specifically addresses the risk that training data, fine-tuning data, or inference inputs — data provided to the model at runtime — may be retained, used for model improvement, or disclosed in model outputs. For tax return data, this risk maps directly to the Section 7216 prohibition on use for purposes other than return preparation. An AI system that retains inference inputs containing client SSNs, income figures, or account numbers is potentially using that data for model training purposes — a prohibited use without consent.

Information integrity. The Profile addresses risks of AI outputs that misrepresent facts or generate plausible but inaccurate information. In a tax preparation context, AI output that misrepresents a client’s tax position — if relied upon — creates professional liability alongside the information integrity risk. The Manage function must include human review requirements for AI-generated tax advice or return preparation output before it is provided to clients or used in filings.

Third-party risks. The Profile specifically calls out risks arising from AI systems that rely on third-party models, APIs, or infrastructure. For firms using commercially available AI tax tools or general-purpose LLMs via API, the vendor’s data handling practices — including where inference data is processed, whether it is retained, and what subprocessors have access — must be assessed against Section 7216’s third-party disclosure standards.

Building the Compliant AI Deployment Architecture

Bringing the three frameworks into operational alignment requires a structured pre-deployment review process and ongoing compliance infrastructure. The following architecture satisfies the WISP requirements of the Safeguards Rule, the third-party processing constraints of Section 7216, and the documentation standards that support a Section 6713 defense.

Pre-Deployment Review Checklist

Identify data flows. Before deploying any AI tool, map exactly what tax return information the tool will access: specific data elements, the pathway through which data reaches the model, where inference inputs are processed, and who at the vendor level has access to the data.

Apply the Section 7216 permitted use test. For each identified data flow, assess whether the use falls within the regulatory categories of permitted use without consent. The key question: is the AI system’s function direct return preparation by the same firm, or does it involve disclosure to a third party or use for a purpose beyond preparing the return? If the latter, consent is required before the deployment goes live.

Review vendor data processing terms. Obtain and review the AI vendor’s data processing agreement, privacy policy, and terms of service specifically for provisions governing:

  • Whether inference inputs are retained and for how long
  • Whether retained inputs are used for model training or improvement
  • What subprocessors receive client data
  • Whether the vendor will execute a data processing agreement restricting use to the firm’s specified return preparation purpose
  • Whether the vendor’s infrastructure is located in jurisdictions that create additional disclosure risk

Build consent documentation if required. If the deployment requires Section 7216 consent, build the consent document and collection process before the first client interaction with the AI system. The consent must be specific to the data, the recipient, and the purpose — not a general data processing consent embedded in an engagement letter.

Update the WISP. Add the AI system to the WISP as a component of the information security infrastructure. Document the risk assessment findings, the access controls governing the AI system, the vendor oversight measures, and the MFA requirements for employee access.

Establish ongoing monitoring. Define the Measure function controls: how will you verify that the vendor’s data handling practices have not changed, that the AI system’s data flows remain within documented boundaries, and that employee use patterns do not generate unauthorized disclosures?

Employee Use Policy

The pre-deployment architecture governs approved AI tools. A separate employee use policy governs what employees may and may not do with client tax return information in connection with any AI tool — approved or otherwise.

The policy must prohibit: inputting client tax return information into any AI tool not explicitly approved by the firm and reviewed under the Section 7216 framework; using AI-generated output without documented human review; copying or pasting client data into general-purpose AI assistants accessible via personal accounts; and storing AI system outputs containing client information in locations not governed by the firm’s information security program.

The policy must require: use only of approved AI tools; completion of training on Section 7216 obligations before accessing any AI system that processes client data; reporting of any AI-related security incidents or unauthorized disclosures; and annual recertification of compliance with the AI use policy.

The Compliance Intersection in Practice

A CPA firm that decides to implement an AI-powered tax document review tool — one that extracts data from client-provided documents, pre-populates return fields, and flags anomalies — is simultaneously activating all three compliance frameworks described in this article. The Safeguards Rule requires that the tool be covered by the WISP, risk-assessed, and governed by vendor oversight. Section 7216 requires that the data flow to the AI tool’s cloud infrastructure be either within a permitted use category (which requires careful review of the vendor’s data processing architecture) or covered by taxpayer-specific consent. Section 6713 creates civil exposure for every disclosure that falls outside those boundaries, regardless of whether anyone intended to violate the statute.

The NIST AI RMF provides the governance methodology to work through each of these requirements systematically before deployment. It also provides the documentation infrastructure — risk assessments, control inventories, vendor assessments, monitoring records — that allows the firm to demonstrate compliance if the FTC, IRS, or a state regulator inquires.

What the RMF does not do is answer the legal questions. The permitted use analysis under Section 7216’s regulations requires legal counsel. The adequacy of a taxpayer consent document requires legal review against the current regulatory standards. The WISP must be developed with awareness of the Safeguards Rule’s specific requirements, not merely general security best practices.

The governance architecture and the legal analysis must operate together. Firms that have one without the other — robust AI governance without legal review of Section 7216 compliance, or legal review without operational AI governance — have addressed only part of the compliance obligation. The frameworks demand both.

This article is provided for informational purposes only and does not constitute legal advice. Organizations should consult qualified legal counsel regarding their specific compliance obligations under the FTC Safeguards Rule, IRC §§ 7216 and 6713, and applicable state laws.