Published July 01, 2026, 9:00 a.m. EDT
6 Min Read
Recent guidance from the IRS Office of Professional Responsibility on artificial intelligence in tax practice arrives at a useful moment, even if it captures only part of the picture. The obligations it describes—due diligence, competence, confidentiality, and fee fairness—are real and enduring. What it does not fully address is how the frameworks practitioners are currently using to meet those obligations were built for a different generation of software, and whether they are adequate for what is sitting on every practitioner’s desktop today.
Processing Content
The stakes of getting this wrong are not abstract. The information flowing through these systems is among the most sensitive financial detail that exists about another person, furnished in confidence under a professional relationship the law takes seriously. The profession has always been deliberate about which people it allows near a client file. It has not yet developed the same instinct about which systems it allows near one, partly because it has been treating AI as a single category of tool when the systems now entering practice are different in kind from anything that came before.
For years, machine learning has been embedded in the software accounting professionals use every day. QuickBooks has suggested transaction categories based on patterns learned from millions of users’ historical choices. Fraud detection systems have flagged anomalies by comparing new transactions against what normal looks like at scale. Research platforms have ranked results by learning which sources practitioners actually relied on. None of this required practitioners to think carefully about what they were handing the system, because the system was classifying and retrieving based on patterns it already learned. The output was anchored to something real, and the practitioner remained the author of every judgment call.
Generative AI works differently. Rather than classifying inputs against learned patterns, it produces original content by predicting what words and sentences are most likely to come next, based on the text it was trained on. It has no internal mechanism for checking whether what it produces is accurate, and this is not a flaw that better versions will eliminate. It is how the technology works. The Deloitte Australia situation, where a government report contained invented judicial quotes and references to nonexistent books, was a predictable output of a tool whose mechanics weren’t understood by the people relying on it. Treating generative AI output the way you would treat a first draft from a capable but occasionally unreliable associate is not just good practice. Under Circular 230, it is the standard.
The confidentiality question is where the profession’s current conversation is most incomplete, and it starts with understanding what the law actually covers. 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 the preparation of a specific taxpayer’s return. Congress wrote the definition to be intentionally broad, establishing the strictest possible scope for data governance.
With the advent of AI usage, the data governance policies we instinctively reach for are proving insufficient. When practitioners evaluate whether an AI tool is safe to use with client data, the instinct is to reach for credentials. Does the vendor have a SOC 2 report? What does their privacy policy say? Do they train on customer data? These are reasonable starting points. They are also answers to questions the statute does not ask.
A SOC 2 report is an audit of a vendor’s internal security controls, access management, and operational practices. It tells you the vendor runs a disciplined shop. It does not speak to whether your firm had legal authority to send client information there in the first place. A privacy policy describes what the vendor will do with information after receiving it.
The most common reassurance practitioners encounter is that the AI provider does not train its models on customer data. This commitment is worth having, but training is 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 and safety purposes, or accessed in response to legal process. A no-training commitment addresses one possibility but leaves the others open.
More fundamentally, none of these credentials reach the threshold question §7216 imposes. The statute asks whether sharing the information was authorized at all. That question precedes everything else. A vendor can have exemplary security practices, a rigorous privacy policy, and a sincere commitment to never training on customer data, and none of it changes what happened at the moment a client’s tax return information left the firm. The disclosure is the event. Every credential and commitment describes what the recipient chose to do afterward.
Consider what that means in practice. When a practitioner searched a client’s name to verify an address, the search engine received a query. It did not receive a tax return. When a practitioner looked up a client’s prior year AGI in their own software, that information never left the building. But when a practitioner pastes a client’s return into an AI tool to draft a cover letter, or drops a K-1 into a chat window to ask a question about basis, the content itself has left the firm. The authorization question attaches at that moment — not when the vendor decides what to do with it, and not when the privacy policy kicks in. By then, the event has already occurred.
The consent framework that makes existing tools legally sound — client portals, document collection software, 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 starts to strain as those same platforms embed generative AI features their clients never agreed to. A client who consented to uploading their records did not necessarily consent to those records being analyzed by a capability the platform added afterward. Most engagement letters were not written with that in mind.
For firms thinking ahead, the most defensible path is designing around the disclosure question rather than managing it after the fact. One direction worth understanding is keeping certain AI processing inside the firm entirely — running AI on hardware the firm controls means taxpayer information never leaves, and the §7216 question answers itself not because of what a vendor promised but because there was nothing to disclose. The assumption that sending data to a large outside model is the only way to use AI is already becoming outdated, and the firms recognizing that now will have cleaner answers sooner.
The honest version of this moment is that the profession is reaching for familiar answers to questions it has not yet learned to ask correctly. The OPR’s Circular 230 guidance is right: the core obligations have not changed. But obligations are only as useful as the frameworks we use to meet them, and the frameworks the profession is currently relying on — privacy policies, SOC 2 reports, no-training commitments, engagement letters written before any of this existed — were not built for what is now sitting on every practitioner’s desktop. Closing that gap starts with understanding what these tools actually are, what the law actually asks, and whether the credentials we have been accepting actually answer it.
