What About Security?

The honest answer to the question every firm asks before it touches AI

By Charlie Barmore, CPA, CFE · The AI Lab for Accountants

Without fail, every time I start talking about AI to an accountant, the same question comes up: "But what about security?"

It's a fair question. In fact, it's often the single biggest reason most accountants aren't using AI at all, or are barely touching it: nobody seems able to answer it in a clear, cohesive way. The answers on offer are either breathless hype ("just use it, everyone is!") or vague dread ("you'll get sued"), and neither one tells you what to actually do on Monday morning.

My goal with this article is simple: answer that question and give you the clarity to use AI in your work confidently, securely, and defensibly. And the good news is that the answer is more reassuring than you'd think. AI isn't a new category of legal risk. It's the same client-confidentiality and competence duties you already carry, applied to a new kind of vendor. The firms that get into trouble won't be the ones that used AI. They'll be the ones that used it without controls, the same way a firm gets in trouble for emailing a return to the wrong address, not for using email.

So the real question isn't "is AI safe?" It's "what controls make my use of it defensible?" That has a concrete answer, and it's what I want to walk you through here.

Three real risks (and not the ones the hype focuses on)

When you really dig into it, the use of AI in our profession primarily creates three types of risk worth managing:

1. Confidentiality. Protecting client information is the gold standard of what we do, and a big part of why clients trust us with their most sensitive details in the first place. Put that data into a tool that may store it, train on it, or hand access to someone who shouldn't have it, and you've broken that trust, and potentially the law. The good news is this is the most controllable of the three: use approved tools under the right agreements, or strip the client data out before it ever goes in.
2. Wrong answers. These models work by predicting the next "token" (essentially the next word, or piece of a word) based on patterns in their training data. That makes them remarkably fluent, but it also means they can confidently produce information that is simply wrong, what's often called a "hallucination." They'll cite a Treasury reg that doesn't say what it claims, or invent a Tax Court case that was never decided, in the same calm tone they use for true things. We're paid to solve hard problems with accurate information, so we can't afford that, but there are concrete ways to cut the risk down dramatically.
3. Over-reliance. AI is convincing. It is genuinely good at producing supporting documentation and rationale for whatever it generates, and the sheer volume of it makes the output easy to accept on faith. It isn't always easy to check its sources or trace how it reached a conclusion, and even when you do catch an error, making sure that correction reaches everywhere it needs to, so stale or wrong information doesn't keep flowing into other workpapers and deliverables, is a challenge of its own. The good news is that this is squarely our wheelhouse: we are natural skeptics and trained reviewers. We just need the right output and processes in place so that reviewing AI's work is as easy as doing what we already do best.

Notice what's not on that list: "AI is inherently dangerous." It isn't. Each of these is really just a controls problem, and controls are something we excel at, something we've been implementing our whole careers.

The obligations that actually attach

But we'd be remiss not to acknowledge, and adhere to, the rules and regulations we're held to, not just with AI, but with any tool, vendor, or process we bring into our work. When you feed client data to an AI tool, or rely on its output, several important binding obligations come into play, and none of them is new: they already govern your cloud software, your outsourcing, and your workpapers.

1. IRC §7216 / §6713: taxpayer return information

This is the big one. §7216 is a 1971 criminal statute, and §6713 is its civil companion. Together they prohibit a return preparer from disclosing or using a client's tax return information (TRI) without authorization. What makes it confusing is that TRI is read broadly: not just the W-2s and 1099s the client hands you, but anything you derive from them. The good news is that the operative test is cleaner than the anxiety around it:

If your AI use fits a specific Treas. Reg. §301.7216-2 exception, no separate §7216 consent is required. If it doesn't, you need the client's valid written consent, or you keep TRI out of the tool.

So what are those exceptions? Treas. Reg. §301.7216-2 lays out the uses and disclosures you can make without separate consent, and a few of them matter for AI. You can use TRI inside your own U.S. firm to prepare that client's return (§301.7216-2(c)). And you can disclose it to a U.S.-based contractor or auxiliary service provider that helps prepare the return under contract (the preparer-to-preparer and contractor provisions).

That phrase, auxiliary services, is worth pausing on, because it's the bucket most legitimate AI prep-support falls into. It's the reg's term for the support work that surrounds preparing a return: the mechanical or electronic processing of the data (§301.7216-2(d)), things like OCR, extraction, computation, formatting, and e-filing, the kind of work a service bureau or a scan-and-populate tool has always done, as opposed to deciding the client's tax. An AI tool doing that sort of processing in support of the return fits the same lane. The dividing line running through all of it is the reg's own definition: a substantive determination is "an analysis, interpretation, or application of the law." Clerical and processing work fits the exceptions; applying tax law to the client's facts does not.

Here's how that plays out in practice.

Here is the whole §7216 decision as one picture. Before any client tax-return information goes into an AI tool, walk it:

A confidentiality agreement/DPA and a §7216 consent are two different layers: the DPA satisfies your AICPA confidentiality and FTC Safeguards duties, while an exception or written consent is what §7216 itself requires. The same logic in words:

Generally safe without separate consent:

• An internal, U.S.-only firm tool. A model running inside your own environment, used to summarize a client's source documents, code their transactions, or draft the open-items list for that client's return. Picture feeding last year's workpapers to your firm's private setup to build this year's prep questions.
• A U.S.-located, contract-bound prep-support vendor that processes or extracts in support of the return and isn't making the tax calls: a 1040 scan-and-populate tool like SurePrep or Gruntworx OCR-ing W-2s into your tax software under a firm contract, or an enterprise seat of a general assistant (Claude Team, ChatGPT Enterprise) on signed no-training terms summarizing a client's brokerage statements.
• No TRI entered at all. Generic research or a non-client-specific template: asking how the §121 home-sale exclusion works with no client names or numbers, or drafting a blank engagement letter. If no return information goes in, §7216 isn't implicated.

Consent-or-don't territory:

• A public or personal AI account with client information in it: pasting a client's actual 1099-B into the free ChatGPT app to "clean it up," or dropping their tax organizer into your personal Claude account.
• A vendor that trains on, retains, or reuses your inputs. A free tier, or any tool whose terms let it learn from your prompts, turns your client's data into its training material. That's a separate prohibited use.
• Offshore access to the data: a tool with overseas support engineers who can open your files, or an offshore review team accessing the return. Even foreign remote access to a U.S. server counts, and you generally can't consent to send a Form 1040 SSN to a preparer outside the U.S. unless you maintain an adequate data-protection safeguard.
• The tool making substantive tax determinations: asking AI "does my client qualify for the QBI deduction?" with their real numbers, or letting it decide whether an expense is deductible, set reasonable compensation, or take a nexus position. That is analyzing, interpreting, or applying law to the client's facts.

It helps to know what's actually on the table, because the two statutes work very differently. §7216 is the criminal one: a misdemeanor punishable by up to a $1,000 fine, up to a year, or both (rising to a $100,000 fine in identity-theft cases), and it applies only where the disclosure or use was knowing or reckless. §6713 is the civil one, and it's the one to really internalize, because it's effectively strict liability: $250 per disclosure or use, capped at $10,000 a year, with no intent required. That distinction matters in practice: an accidental paste of client data into a consumer chatbot can trigger the §6713 penalty even though nobody meant any harm. Which is exactly why "just be careful" isn't a control. A policy is.

And if you do land in consent territory, real consent has formalities. Under Treas. Reg. §301.7216-3, a valid §7216 consent has to be signed before the disclosure or use, has to be knowing and voluntary, and has to specifically and separately identify each use or disclosure, the recipient, and the information covered (no blanket "use my data however"). A single document can authorize multiple uses or multiple disclosures, but never both at once, so use consents and disclosure consents always live on separate documents. And it lasts for the period the taxpayer specifies, defaulting to one year from the date signed if you don't.

The fussiest part, the standalone document, the mandatory wording, the 12-point type, is specific to Form 1040 clients (Rev. Proc. 2013-14). For business returns (1120, 1065, 1120-S), the format relaxes: the consent can sit inside an engagement letter and can name a class of recipients instead of each one. The core regulation above still binds everyone, business clients included. Concretely, if you ever route 1040 data through a cloud AI tool that needs consent, that disclosure consent has to name the AI vendor as the recipient and be signed before the first prompt.

2. The FTC Safeguards Rule & your WISP

Under Gramm-Leach-Bliley, tax and accounting firms are legally "financial institutions," and the FTC Safeguards Rule (16 CFR Part 314) names tax-prep firms by category. It's been in full effect since June 2023. Its functional equivalent in our world is the Written Information Security Plan (WISP) you attest to at PTIN renewal.

The Rule's logic maps onto AI with zero translation: an AI vendor that can receive or access client information is a "service provider." Before you route client data to it, you must vet its security, bind it by contract to maintain safeguards, confirm encryption, and reassess it periodically, and log it in your WISP as an assessed third-party application. A free consumer tool with none of those terms simply can't satisfy this. That's the legal backbone of the rule of thumb you've heard: anonymize, or use an enterprise tool under a data agreement. In practice: the day a staffer wants to try a new AI bookkeeping app that can see a client's ledger, it has become a service provider, so it needs a contract and a line in your WISP before the data goes in, not after the fact.

3. The revised SSTS (effective Jan. 1, 2024)

The Statements on Standards for Tax Services were revised, and two pieces speak directly to AI. §1.3 ties your data-protection duty to the Safeguards Rule and WISP. §1.4 ("Reliance on Tools") expressly names artificial intelligence as a "tool", so there is no "the rules don't reach AI" argument, and provides that you retain every professional obligation and remain responsible for the completed work product whether or not you used AI. Tools should enhance the member's judgment, the standard says, not supplant it. In plain terms: if AI drafts a depreciation schedule and it's wrong, "the software did it" is not a defense; the standard puts the finished work product on you.

4. Circular 230: competence and diligence

You don't need a new rule for AI; the existing ones already reach it. §10.35 requires competent practice, which means understanding what your tool can and can't do, how current its law is, and how to verify it. §10.22 lets you rely on another's work product only if you used reasonable care in engaging, supervising, and evaluating that source, a presumption AI can't supply for itself: you can lean on a junior's workpaper because you hired, trained, and reviewed that person, but there's no one behind the chatbot to have supervised, so the same "reliance" doesn't transfer. §10.37 says written advice must relate law to facts and rest on reasonable assumptions, so AI-drafted advice can't leave the building until you've verified the authorities and adopted the conclusion as your own.

One honesty note, because precision is the point: a proposed Circular 230 amendment would add explicit technological-competence and data-security duties, and its preamble points straight at the Safeguards Rule and WISP. As of now it is proposed, not final. Treat it as the direction of travel, not a current obligation. The general competence duty already applies regardless.

And two more that quietly attach

• The AICPA Confidentiality Rule (ET §1.700.001) is a separate duty from §7216: before confidential client information reaches a third-party provider, you need either client consent or a confidentiality agreement with that provider. So even when a §7216 exception means no tax-consent form is required, this rule still wants a DPA or consent. (It shows up in three parallel places in the Code: notify the client, evaluate/supervise the provider, protect the data.)
• Your state board. Most states impose their own confidentiality duty and incorporate AICPA standards into your license, so the framework above binds you through your license even where SSTS technically bind "AICPA members." Georgia, for example, does both (Rules 20-12-.11 and -.19). Check your own board's confidentiality and standards rules, and your state's data-security and breach-notification law.

(If you do attest work, AI output is audit evidence under AU-C 500, with the same reliability and documentation duties, and you remain responsible. For tax and bookkeeping practices, that's background.)

The standards at a glance, and how you satisfy each:

The trap: "enterprise tool with a data agreement = compliant"

This is the oversimplification I hear most, and it's wrong in a way that matters.

"Public AI" is practitioner shorthand, not a statutory category. §7216 doesn't care whether a tool is labeled "public" or "enterprise." It cares whether TRI was used or disclosed. The disclosure happens the moment your firm transmits the data to the vendor, so unless the model is fully self-hosted inside your firm, you've made a third-party disclosure, and you still need a §301.7216-2 basis for it.

What enterprise terms actually buy you is defensibility, not disappearance. And they come as four separate promises that people wrongly treat as one:

• No training on your inputs limits the vendor's reuse; it does not mean no disclosure occurred. The vendor won't improve its model on your client's 1099s, but those 1099s still left your firm.
• Zero data retention limits stored logs, and often applies only to specific endpoints (files, threads, assistants, and project memory can still retain state with "ZDR" on). Turn it on for chat and an uploaded file or a saved "project" can still hang onto the data.
• An enterprise DPA establishes confidentiality; it does not automatically satisfy §7216. It's the same kind of contract you have with your shredding vendor: necessary, not sufficient.
• U.S. data residency avoids the offshore trigger; it does nothing about training or substantive-advice issues. Your data on a Virginia server kills the offshore problem and says nothing about whether the vendor learns from it.

The way I think about it: the use-level matters more than the tool's brand. Low-level prep support (OCR, summarization, extraction, classification, formatting) on an enterprise, U.S., no-training, zero-retention tool can often be treated like controlled auxiliary technology, defensible without separate consent. Client-specific tax advice, substantive position analysis, offshore access, or any training/retention of your data lands you back in consent-or-prohibit territory no matter what the sales deck says.

Anonymizing isn't a loophole, but done right it's the cleanest path

The single move that turns most red-light tasks green: don't put TRI in at all. If you fully strip the return information (real analysis works fine on "Taxpayer A, $X over the threshold, in [STATE]"), then there's no disclosure and §7216 isn't implicated.

The caution worth stating plainly: partial scrubbing still carries exposure. "Return information" includes data you derived from the return, so a half-anonymized fact pattern can still contain TRI. Anonymization reduces risk only to the extent it's actually complete. Use a real, offline redaction step and spot-check the output. Don't eyeball it.

What to actually do (the controls, in plain English)

Here's the checklist I'd hand you. Before any client data goes into an AI tool, or any AI output goes into a deliverable:

1. Pick the §7216 lane. Internal U.S. tool, approved U.S. prep-support vendor, or no-TRI → proceed. Public tool, training/retention, offshore, or substantive determination → consent or keep TRI out. When unsure, anonymize or get consent.
2. Put the tool in your WISP. Vetted, under a contract/DPA, encrypting data, reassessed periodically. If it isn't, don't feed it client data.
3. Get the four vendor answers in writing: no training on your inputs/outputs; true zero/minimal retention for the features you use; U.S.-only processing and access; and a confidentiality agreement/DPA with subprocessors disclosed.
4. Clear the Confidentiality Rule: client consent or a confidentiality agreement with the vendor, separate from §7216.
5. Stay the reviewer of record. You review, decide, and sign. AI never carries the professional judgment.
6. Verify every citation. Any Code section, reg, or threshold from a general AI tool is unverified until you've checked it against primary source. The models invent authority, confidently. If AI hands you a "Rev. Rul." or a Code subsection, pull it up before it reaches the memo.

Quick reference, by tool type:

And by the kind of work you're doing:

Whatever the tool or the task, two moves never change: when in doubt, anonymize or get written consent, and verify every tax citation against primary source before you rely on it.

That's the whole game. None of it is exotic. It's the discipline you already apply to outsourcing and cloud software, written down and pointed at one more vendor.

The one principle under all of it

Code computes. AI drafts. The licensed human decides.

Every rule in the stack (SSTS §1.4, Circular 230 §10.22, the AICPA Code) converges on the same point: the tool is a tool, and the professional owns the result. Hold that line and "what about security?" stops being the thing that keeps you from starting. It becomes the thing you've already handled.

So here's where I land: security isn't a reason to wait. It's a reason to put controls in place and then get to work.

Do this week

• Run the Safe-Use Planner on the next real task you're tempted to hand to AI. You'll get the lane, the why, and the move in about a minute.
• Write the one-page AI-use policy (which tools are approved, for what, with what terms) and fold it into your WISP.
• Get the four vendor answers in writing for any tool that touches client data.
• Pick one low-risk, high-volume task (document summarization, OCR cleanup) and run it through the compliant path end to end.

Educational, not legal advice. Every regulatory claim here is grounded in primary-source-verified research: the actual Code, Treasury regulations, the FTC rule, and the AICPA standards, documented with citations in the AI Lab's Regulatory Foundation. The law changes, the proposed Circular 230 amendment is not yet final, and your state board may add requirements. Verify against the primary source and your own counsel before relying on any point for a specific situation.