AI in Tax Practice: What the IRS Guidance Gets Right and Where the Real Gap Is

The IRS Office of Professional Responsibility has issued guidance on artificial intelligence in tax practice, and it confirms that the core obligations under Circular 230 remain intact: due diligence, competence, confidentiality, and fee fairness still apply. That framing is correct. The problem is that the compliance credentials most firms are currently relying on to meet those obligations were designed for a different generation of software, and they do not actually answer the legal question that generative AI raises the moment a practitioner pastes a client's return into a chat window.

Why Generative AI Is Different in Kind, Not Just Degree

Accounting firms have been using machine learning for years without needing to think carefully about data governance in this specific way. Categorization engines, fraud detection flags, and research-ranking algorithms all work by comparing new inputs against patterns learned at scale. The practitioner's data goes in, a classification or ranked result comes out, and the system's author of judgment remains the practitioner. The output is anchored to something the system already learned before the client file arrived.

How the mechanics shift with generative models

Generative AI does not classify. It predicts the next word, then the next, based on training data, producing original content with no internal mechanism for checking accuracy. That is not a flaw engineers will eventually fix. It is how the technology works. The high-profile incident involving a government report that cited invented judicial quotes and nonexistent books was a direct and predictable output of this mechanic being misunderstood by the people relying on it. Under Circular 230, treating generative AI output as a first draft requiring practitioner review is not optional best practice. It is the competence standard.

What changes the data governance picture is not the quality of the output. It is that producing the output requires the model to receive the content itself, and that content includes tax return information the law treats with particular seriousness.

What §7216 Actually Asks and Why Current Credentials Miss It

Treasury Regulation §301.7216-1(b)(3) defines tax return information broadly: names, addresses, identifying numbers, income figures, deductions, and anything else furnished in connection with preparing a specific taxpayer's return. Congress wrote the definition to be intentionally wide, and it establishes the strictest possible scope for data governance. The statute's threshold question is whether the sharing of that information was authorized. That question comes first, before anything else.

The credentials firms reach for and what they actually prove

When a firm evaluates whether an AI tool is safe to use with client data, the instinct is to check for familiar markers. Does the vendor hold a SOC 2 report? What does their privacy policy say? Do they commit to not training on customer data? These are reasonable starting points for vendor selection. They are not answers to what §7216 asks.

A SOC 2 report is an audit of a vendor's internal security controls and access management practices. It tells you the vendor runs a disciplined operation. It says nothing about whether your firm had legal authority to send the information there in the first place. A privacy policy describes what the vendor will do with data after receiving it. A no-training commitment is worth having, and it addresses one specific concern. But training is only one of several things that can happen to information once it leaves the firm: it can be retained in system logs, reviewed by human teams for quality assurance, or accessed in response to legal process. The commitment closes one door and leaves the others open.

Critically, none of these credentials reach the threshold question. The statute asks whether sharing was authorized. A vendor can have exemplary security practices, a rigorous privacy policy, and a genuine no-training policy, and none of it changes what happened at the moment client tax return information left the firm. The disclosure is the event. Every credential and commitment describes what the recipient chose to do afterward.

When the disclosure event actually occurs

The distinction becomes concrete in practice. When a practitioner searched a client's name in a browser to verify an address, the search engine received a query, not a tax return. When a practitioner pulled up a client's prior-year adjusted gross income in their own practice management software, that information never left the building. But when a practitioner pastes a client's return into an external AI tool to draft a cover letter, or drops a K-1 into a chat interface to ask a question about basis, the content itself has crossed the firm's boundary. The authorization question under §7216 attaches at that moment, not when the vendor decides what to do with the data and not when the privacy policy takes effect. By then, the event has already occurred.

Where the Consent Framework Starts to Strain

The legal soundness of existing tools, client portals, document collection software, and practice management platforms, rests on clients knowingly participating in a process the firm designed, in service of the work they hired the firm to do. That framework holds when the scope of what the system does is what the client agreed to. It starts to break down when platforms add generative AI features their clients never specifically agreed to.

Engagement letters written before generative AI existed

A client who consented to uploading their records to a firm portal did not necessarily consent to those records being analyzed by a generative capability the platform added afterward. Most engagement letters in active use today were not drafted with that use case in mind. Firms relying on existing consent language to cover AI-assisted processing of client data are assuming a scope of authorization that the documents may not actually grant.

For firms reviewing their engagement letter templates, the relevant question is not whether the letter mentions technology. It is whether the consent language is specific enough to cover the actual processing that will now occur. Broad language authorizing the firm to use its professional tools to complete the engagement was written when those tools did not include externally hosted generative models receiving the full text of a client's return. The IRS data governance challenges highlighted in recent oversight reporting, including IRS federal tax information governance gaps flagged by TIGTA, underscore how seriously regulators treat the handling of taxpayer data even within authorized systems. The bar for external sharing is higher still.

Designing Around the Disclosure Question

The most defensible path for firms is to design workflows so the §7216 disclosure question answers itself, rather than managing it after the fact with vendor credentials. There are two ways that architecture can work.

Keeping AI processing inside the firm boundary

Running AI on hardware the firm controls means taxpayer information never leaves. The §7216 question does not arise because there is no disclosure event. This is not hypothetical. The assumption that sending data to a large externally hosted model is the only way to access capable AI is becoming outdated. Firms that recognize this now, and begin evaluating on-premise or private-cloud alternatives, will have cleaner compliance answers than firms waiting for their current vendors to develop better privacy commitments.

Obtaining specific, informed client consent

Where a firm intends to use external AI tools with client data, the consent framework needs to be specific and current. That means updating engagement letters to describe the actual processing being authorized, naming or describing the category of tool, and giving clients a genuine opportunity to understand what they are agreeing to. Generic technology language drafted years ago is not a substitute for informed consent to a materially new kind of data processing. Practitioners already navigating IRS notice errors and client communication challenges, such as those arising from IRS CP53E notice issues, know how quickly inadequate documentation creates downstream exposure. The same logic applies here.

What the OPR Guidance Gets Right and Where the Work Remains

The OPR's Circular 230 framing is correct: the core obligations have not changed. Practitioners still owe clients competent, diligent, confidential service. What the guidance does not fully address is whether the compliance infrastructure the profession has been using to meet those obligations was built for what is now sitting on every practitioner's desktop.

Privacy policies, SOC 2 reports, no-training commitments, and engagement letters written before generative AI existed are not wrong answers. They are answers to questions the statute does not ask first. The question the statute asks first is whether the disclosure was authorized. Closing the gap between that question and the credentials the profession currently accepts starts with recognizing they are not the same thing.

What is the IRS OPR's position on AI in tax practice?

Does a SOC 2 report satisfy §7216 requirements?

What counts as a disclosure under §7216 when using AI tools?

Do no-training commitments from AI vendors satisfy confidentiality obligations?

How should firms update engagement letters to address AI use?

Source: Accounting Today