Regulatory Foundation, Our Actual Obligations When Using AI on Client Work

This is the project's bedrock reference, Guardrails is the plain-English layer on top of it. It states what each governing rule is, what it actually requires, and the specific obligation it creates when you put client data into, or rely on output from, an AI tool.

Every claim below was researched against primary sources (IRS, FTC, eCFR, Federal Register, AICPA) and adversarially fact-checked. Confidence levels and "not-yet-final" flags are marked honestly, per this project's own rule, we cite accurately or we flag the uncertainty.

Scope and disclaimer. This is an internal educational summary for AI Lab members, not legal advice. It reflects research current to 2026 and the law changes. Verify against the primary source and your own counsel/state board before relying on any point for a specific situation.

The short version (the stack you're standing on)

When you feed client data to an AI tool, four binding obligations can attach at once:

1. IRC §7216 / §6713, you may need the client's written, knowing-and-voluntary consent before taxpayer return information goes to a third-party AI service. (Criminal + civil. Settled law.)

2. FTC Safeguards Rule / IRS WISP, the AI vendor is a service provider you must vet, bind by contract, and monitor; client data must be encrypted; the tool must be assessed under your written information security plan. (Settled law, in full effect.)

3. Revised SSTS (effective 1/1/2024), you remain fully responsible for the work product whether or not you used AI, and you must protect data and exercise judgment when relying on tools. (Enforceable for AICPA members.)

4. Circular 230, competence and due diligence today; a proposed amendment would add explicit technological-competence and data-security duties. (Proposed, not yet final.)

Plus two more that can attach: the AICPA Confidentiality Rule (ET §1.700.001), consent or a confidentiality agreement with the AI vendor, independent of §7216; and, for a Georgia CPA, state law, Rule 20-12-.11 (confidentiality) and 20-12-.19 (which pulls AICPA standards into your license). Attest work adds SSARS/GAAS (AI is evidence under AU-C 500, you stay responsible).

Bottom line: before AI touches real client data, get §7216 consent where required, vet and contractually bind the vendor under your WISP (and the Confidentiality Rule), encrypt, and never stop being the reviewer of record.

1. IRC §7216 & §6713, disclosure/use of taxpayer return information

What it is. §7216 is a 1971 criminal statute; §6713 is its companion civil penalty. Together they prohibit a tax return preparer from knowingly or recklessly disclosing or using taxpayer "return information" without authorization. Final Treasury Regulations took effect Dec. 28, 2012 (temporary regs Jan. 4, 2010). (Confidence: high, 3-0 verified.)

Penalties, the precise 2×2 (verified against primary statutory text).

• ⚠️ Two precision points, both verified to source: 1. The $100,000 is the §7216 criminal fine in identity-theft cases, the statute reads "fined not more than $1,000 ($100,000 in the case of a disclosure or use to which section 6713(b) applies)." It is not a §6713(b) penalty amount (§6713(b)'s own civil enhancement is $1,000/$50,000) and not the ordinary exposure. Don't quote $100k as your everyday risk.

2. §6713 civil liability requires no mental state. §6713(a) imposes the penalty on the act of disclosure/use itself, unlike §7216's criminal charge, which needs "knowingly or recklessly." Practical upshot: an accidental paste of TRI into a consumer tool can carry the civil penalty even with zero intent.

• Sources (operative text quoted): 26 U.S.C. §7216 · 26 U.S.C. §6713. Confidence: high, primary text pulled.

What it requires with AI, the clean rule. §7216 treats tax return information (TRI) broadly: information furnished for return preparation and anything the preparer derives or generates from it. "Use" = relying on TRI to take or permit an action; "disclosure" = making TRI known to another person in any manner. Consent is the baseline unless §7216 or a specific 26 CFR §301.7216-2 exception authorizes the use/disclosure; consent must be knowing and voluntary and meet the format/content rules of Rev. Proc. 2013-14.

AI is not a special case, it is analyzed under the existing use/disclosure rules. The answer is a qualified no: AI use is not automatically a permitted §7216 use, but it is not categorically prohibited or always consent-triggering either.

The operative test: If the AI use fits a specific §301.7216-2 exception, no separate §7216 consent is required. If it does not, the firm needs valid written taxpayer consent, or must not put TRI into the tool.

Generally SAFE without separate consent (the use is functionally just preparing that client's return, or auxiliary services):

• Internal AI inside the same U.S. firm, firm personnel use an approved tool to summarize source docs, classify expenses, review workpapers, or draft prep questions for that taxpayer's return. Same-firm U.S. personnel may use/disclose TRI internally for preparation/auxiliary services without consent.

• Approved U.S. software / processor / auxiliary vendor, a U.S.-located, contractually-bound vendor that processes, extracts, computes, or e-files in support of prep and is not making substantive tax determinations (§301.7216-2 preparer-to-preparer and contractor provisions, subject to contract/notice conditions).

• No TRI is entered at all, generic tax research, proofreading a non-client-specific email, drafting a generic checklist or workflow template. No TRI used or disclosed → §7216 not implicated.

Generally REQUIRES consent, or should be PROHIBITED (outside the prep/auxiliary lane):

• Public / general-purpose AI tools with client information, uploading client facts, docs, PII, workpapers, or return data into a public tool is hard to defend as a permitted disclosure. An IRS OPR webinar expressly distinguished harmless proofreading from uploading client information into AI research/drafting tools, calling the latter a disclosure of client info.

• Vendor may train on / improve models from / reuse prompts / share data across subscribers, this is no longer merely preparing that taxpayer's return; it becomes a separate "use" of TRI. (Anonymous statistical-compilation rules are narrow and don't rescue this.)

• Offshore access, disclosing TRI to personnel outside the U.S. triggers consent; the examples treat even foreign remote access to data on a U.S. server as an offshore disclosure. Special SSN rule (§301.7216-3(b)(4)): a U.S. preparer generally may not consent to send a 1040 SSN to a preparer outside the U.S. unless an "adequate data protection safeguard" is maintained.

• Substantive tax determinations by the vendor/tool, if it analyzes, interprets, or applies tax law to determine the taxpayer's liability, the no-consent auxiliary-service exception weakens or disappears.

Defensible firm-policy standard: Client TRI may be used with AI only through firm-approved systems. Approved systems must be covered by a firm-level contract/DPA, prohibit model training and product-improvement use of client data, provide zero or minimal retention for the specific features used, restrict human access, identify subprocessors, maintain appropriate security controls, avoid unauthorized offshore access, and be used solely for preparing/assisting the client's return or related auxiliary services. Public or personal AI accounts may not be used with client-identifiable or return-derived information. Uses outside those limits require §7216 review and, where applicable, valid written taxpayer consent.

Note also a distinction: a separate §7216-format consent is only legally required when the use isn't already permitted, but disclosing your gen-AI use to clients (and getting consent) is often good risk management regardless, per AICPA/CNA guidance. (This is why the auxiliary- services exception is not a green light to skip the conversation.)

Enterprise / zero-data-retention (ZDR) AI: better, but NOT automatically exempt

A common and dangerous oversimplification is "enterprise tool with a data agreement = compliant." The truth is more precise. "Public/general-purpose AI" is practitioner shorthand, not a statutory category, §7216 doesn't care whether a tool is "public." It cares whether TRI was used or disclosed. So tools sit on a spectrum:

The key insight: ZDR makes the disclosure more defensible; it does not make §7216 disappear. The disclosure happens the moment the firm transmits TRI to the vendor. Enterprise/ZDR terms help show the vendor isn't making an independent prohibited use of the data, but the firm still needs a §301.7216-2 basis for the disclosure itself (same-firm U.S. internal use, U.S. auxiliary/contractor service for prep, etc.). Unless the model is fully self-hosted, it's still a third-party disclosure.

The self-hosted argument, and its honest limit. The reason a fully local model escapes the disclosure analysis is textual, and the chain is worth spelling out because each link is verified: (1) §7216(a) prohibits a preparer's disclosure of TRI; (2) "disclosure" is defined as "making tax return information known to any person in any manner whatever" (26 CFR §301.7216-1(b)(5)); (3) §301.7216-1(b) does not independently define "person", it defines seven terms (tax return, preparer, TRI, use, disclosure, hyperlink, request for consent) and "person" is not one, so the IRC-wide default applies; (4) IRC §7701(a)(1) defines "person" for the whole title as "an individual, a trust, estate, partnership, association, company or corporation", software is none of those; (5) therefore inference on firm-controlled hardware makes TRI known to no person, and the §301.7216-3 / Rev. Proc. 2013-14 consent regime is not triggered for the AI step.

The one attack surface (and why "genuinely local" closes it). The only real counterargument is that the vendor who shipped the model or distributed the weights is somehow "implicitly receiving" the information when you run their software. That argument is weak: "disclosure" requires making TRI known to a person, and a vendor that cannot observe your prompts (no telemetry, no cloud fallback, no remote access) is made aware of nothing. But it is exactly the surface the position turns on, which is why "genuinely local" is load-bearing: kill telemetry, crash reporting that includes content, cloud fallback, auto-update channels that phone home with data, and vendor support access. If any of those carries TRI off the box, that transmission is the disclosure, and the whole analysis flips. This is a strong reading of the plain text, but it is not blessed authority for AI. As of June 2026 there is no IRS guidance, ruling, or case addressing AI under §7216, the most recent §7216 guidance predates the technology (Rev. Rul. 2010-4, newsletter/bulletin service providers; Rev. Rul. 2010-5, professional-liability insurers; plus the 2012 final regs). The gap cuts both ways: the IRS has not confirmed the local-model path and has not asserted local inference is a disclosure. Use this reasoning internally with confidence; do not represent it as IRS-blessed, and run any client-facing "no consent needed because it's local" language past counsel and your carrier first. The conservative posture (consent where you'd otherwise get it, de-identification, reviewer-of-record) does not depend on this conclusion being right. (Two notes: this answers the disclosure prong only, §7216 still governs use, so fine-tuning a local model on client data is a separate, unguided "use" question; and the §301.7216-2(d) service-provider exception that a cloud vendor might invoke is itself narrow and conditional, (d)(2) covers contractors for "programming, maintenance, repair, testing, or procurement of equipment or software used for tax return preparation" and requires written §6713/§7216 penalty notice, which is why local is the cleaner lane.)

These are four separate concepts, don't let one stand in for another:

• No model training → limits vendor reuse; does not mean no disclosure occurred.

• Zero data retention → limits stored logs/state; does not mean no disclosure occurred, and may apply only to specific endpoints/modes (files, threads, assistants, vector stores, batch jobs, custom-GPT knowledge, project memory can retain state even when "ZDR" is on).

• Enterprise DPA → establishes confidentiality/use-limitation; does not automatically satisfy §7216.

• U.S. data residency → avoids the offshore-disclosure trigger; does not solve training, retention, or substantive-advice issues.

Use-level matters more than tool brand:

• Low-level prep support, OCR, summarization, extraction, classification, formatting, workpaper cleanup, on enterprise ZDR AI can often be treated like a controlled auxiliary-service technology (defensible without separate consent).

• Client-specific tax advice / substantive position analysis (filing positions, deduction treatment, §199A, nexus), offshore access, retained files, training, or product improvement → back in consent-or-prohibit territory, regardless of "enterprise" labeling.

Minimum diligence before approving an enterprise AI tool for client TRI, get written confirmation of: (1) no training/model-improvement on prompts, files, outputs, embeddings, or feedback; (2) true ZDR for the specific endpoints/features used (not a marketing line); (3) no persistent application state unless necessary and approved; (4) U.S.-only processing/access (absent §7216 consent); (5) no third-party/downstream tool calls with TRI unless each is separately vetted; (6) confidentiality + subprocessor terms appropriate to TRI; (7) vendor human-access restrictions; (8) §7216/§6713 contractor-notice mechanics where access is possible; (9) use limitation (data used only to provide the service to the firm); (10) CPA final review, AI output is never the final substantive tax determination. (CNA/AICPA risk-control guidance aligns: ask how data is stored, whether it trains models, who can access it, retention, and de-ID.)

Sources: 26 CFR §301.7216-1 (definitions/penalty) · §301.7216-2 (permissible uses without consent) · §301.7216-3 (consent) · IRS OPR webinar transcript, ethical tax practice & AI · IRS §7216 Information Center · Rev. Proc. 2013-14 · AICPA §7216 guidance & sample consents · AICPA/CNA, disclosing gen-AI use to clients · OpenAI Enterprise Privacy, illustrates retention/ZDR varying by endpoint

2. FTC Safeguards Rule (GLBA) & the IRS WISP

What it is. Under the Gramm-Leach-Bliley Act, tax/accounting professionals are legally classified as "financial institutions." The FTC Safeguards Rule (16 CFR Part 314) expressly lists "tax preparation firms" (§314.2(h)) as covered. The Rule took full effect June 9, 2023 and is current through 2026. The IRS WISP (Pub 4557 / Pub 5708, attested to on Form W-12 at PTIN renewal) is the functional equivalent of the required program. (Confidence: high, 3-0.)

What it requires. A comprehensive, written information security program with administrative, technical, and physical safeguards appropriate to your firm's size and complexity, including:

• (a) designate a Qualified Individual/coordinator;
• (b) identify and assess risks to customer information;

• (c) implement, monitor, and test safeguards (the 2021/2023 amendments add MFA, written risk assessment, incident response);

• (d) encrypt customer information at rest and in transit (§314.4(c)(3));

• (e) §314.4(c)(4): procedures to evaluate/assess/test the security of externally developed applications you use to transmit, access, or store customer info, a third-party AI tool fed client data is exactly such an application;

• (f) §314.4(f) service-provider oversight: (1) reasonably select/retain capable providers, (2) contractually require them to implement and maintain safeguards, (3) periodically reassess them on a risk basis (FTC adds: monitor their work).

What it requires with AI. An AI/cloud vendor that receives, processes, or can access customer information is a "service provider." So before routing client data to it you must: vet its security, get a contract/DPA that requires it to maintain safeguards (and, practically, address data retention, no-training-on-inputs, and sub-processor disclosure), confirm encryption, and reassess periodically. A consumer free-tier tool with no such terms generally cannot satisfy this, which is the legal backbone of "anonymize or use an enterprise tool with a data agreement."

Sources: IRS Security Summit, WISP requirement · FTC Safeguards Rule guidance · 16 CFR Part 314 (eCFR)

3. AICPA Code of Professional Conduct & revised SSTS (effective 1/1/2024)

What it is. The Statements on Standards for Tax Services (SSTS) are enforceable tax practice standards binding on AICPA members (enforced under ET §§1.300/1.310 of the Code), not advisory, but they bind members, not every state-licensed CPA per se. The revision was adopted May 18, 2023 and is effective Jan. 1, 2024, adding three new standards, two of which bear directly on AI. (Confidence: high, 3-0.)

What it requires with AI. (Standard- and section-level summaries below; we don't quote granular sub-paragraph numbers verbatim, verify exact wording against the published revised SSTS before relying on a specific clause.)

• SSTS No. 1, §1.3 (Data Protection) ties the member's data-security duty to the FTC Safeguards Rule and the WISP requirement, pulling data protection into the ethics standard.

• SSTS No. 1, §1.4 (Reliance on Tools) requires the member to exercise appropriate professional judgment and care when relying on tools, provides that the member retains all professional obligations whether or not a generative-AI system or any other tool is used, and that the member remains responsible for the completed work product.

• §1.4.2 expressly names "artificial intelligence" in the definition of a tool, alongside tax-prep software, research publications, calculation aids, data analytics, and statistical models. So AI is unambiguously inside the SSTS "reliance on tools" standard; there's no "it's just AI, the rules don't reach it" argument. §1.4.8: tools should "enhance or improve the member's understanding… not… supplant the member's professional judgment." (§1.4.2/§1.4.8 verified via The Tax Adviser, Sep 2025, multi-source; confirm exact wording against the published SSTS.)

AICPA Confidentiality Rule (ET §1.700.001), a consent duty separate from §7216. The Code's Confidential Client Information Rule prohibits a member from disclosing confidential client information without specific client consent. Long-standing AICPA guidance on using a third-party service provider (the outsourcing interpretation) is that, before disclosing confidential client information to an outside provider, a member should either obtain client consent or enter into a contractual confidentiality agreement with that provider. Applied to AI: an AI vendor that can access client information is exactly such a third-party provider, so the confidentiality rule points to the same control set as the §314.4(f) Safeguards duty (a confidentiality/DPA contract) and §7216 (consent). This is a separate, independent obligation: even where a §7216 exception means no tax-consent form is required, the Confidentiality Rule still requires either client consent or a confidentiality agreement with the AI vendor.

The specific interpretations. Key structural point that resolves a common citation confusion: the third-party-service-provider rules are codified in parallel under three different ethics rules, so all three numbers are correct and address different facets:

• ET §1.150.040 (under the Integrity and Objectivity Rule), notify. The member should inform the client, preferably in writing (e.g., an engagement-letter provision), that a provider may be used, except where the provider is used only for administrative support (record storage, software-application hosting, or authorized e-file transmittal). → This carve-out tracks the clerical/auxiliary-vs-substantive line: a tool used purely for storage/hosting/e-file mechanics needs no separate client notice; a tool doing more does.

• ET §1.300.040 (under the General Standards Rule), evaluate & supervise. Evaluate the provider's qualifications, skills, and resources, and plan/supervise so the work meets competence/due-care.

• ET §1.700.040 (under the Confidential Client Information Rule), protect. Before disclosing confidential client information to a provider, the member should either enter a contractual agreement requiring the provider to maintain confidentiality (with reasonable assurance of controls against unauthorized release) or obtain specific client consent.

Verification status: the three section numbers and the contract-or-consent / notify / supervise substance are corroborated across multiple independent authoritative sources (JofA, AICPA- authored, which quotes §1.700.040 verbatim; The Tax Adviser; CPA Journal), and one source expressly ties all three together ("…under ET Sections 1.150.040, 1.300.040, and 1.700.040"). ⚠️ The canonical AICPA Code is published as a non-machine-readable PDF, so this is authoritative-secondary verified, not a verbatim primary pull, open the live Code PDF to confirm exact wording before quoting it in a client-facing document.

This is the cleanest statement of the reviewer-of-record principle anywhere in the stack: AI is a tool; the professional owns the result.

Sources: Revised SSTS No. 1-4 (AICPA) · The Tax Adviser, Tax ethics & generative AI (Feb 2024) · The Tax Adviser, New SSTS §1.4 Reliance on Tools (Sep 2025) · JofA, the AICPA confidentiality rule · JofA, outsourcing & professional liability (Sep 2024)

4. Treasury Circular 230, competence & due diligence

What it is. Circular 230 governs practice before the IRS. Today, §10.35 imposes a general competence duty and the rules require due diligence. A proposed rule (REG-116610-20, 89 FR 105234, published Dec. 26, 2024) would amend it. (Confidence: medium, the existence and content of the proposal are verified, but it is PROPOSED, not final.)

What's BINDING NOW (verified to live text, these already reach AI use, no amendment needed).

• §10.22 (Diligence as to accuracy). Due diligence in preparing/assisting/approving/filing returns and papers, and in the correctness of representations to Treasury and to clients. Critically, a practitioner may rely on another person's work product and is presumed to have exercised due diligence only if the practitioner used "reasonable care in engaging, supervising, training, and evaluating the person, taking proper account of the nature of the relationship." → Direct analogy for relying on AI output: the reliance presumption depends on you having vetted and supervised the source, which AI cannot self-supply.

• §10.35 (Competence), already in effect since June 12, 2014. "Competent practice requires the appropriate level of knowledge, skill, thoroughness, and preparation necessary for the matter"; competence may be obtained by "consulting with experts… or studying the relevant law." So AI competence (knowing what the tool can/can't do, how current its law is, whether it cites, how to verify) is already a duty, the proposed amendment just makes the technology piece explicit.

• §10.37 (Written advice). Advice must rest on reasonable factual and legal assumptions, reasonably consider known facts, relate applicable law and authorities to facts, not rely unreasonably on representations/findings, and not factor in audit-lottery odds. → AI-drafted written advice can't go out until the CPA verifies authorities, validates assumptions, and adopts it as their own conclusion.

• §10.36 (Procedures to ensure compliance), verified to primary text. The individual with "principal authority and responsibility for overseeing a firm's practice" must take "reasonable steps to ensure that the firm has adequate procedures… for all members, associates, and employees" to comply with Subparts A, B, and C. If the firm names no one, "the IRS may identify one or more individuals." Discipline attaches under §10.36(b) when, through willfulness, recklessness, or gross incompetence, the responsible person (1) fails to establish adequate procedures, (2) fails to ensure procedures are followed, or (3) knows or should know of a "pattern or practice" of noncompliance and fails to take prompt corrective action.

• Solo-practice collapse: you are both the principal authority and the only practitioner, so there's no designation gap, §10.36 reduces to a single point of accountability. Mapped to AI: no written AI-use policy or unvetted vendor tools outside the WISP = failure to establish procedures; a contractor/seasonal hire using unapproved AI = failure to establish + enforce; discovering unvetted AI use and not fixing it = §10.36(b)(3) failure to correct; AI output into returns without review = combined §10.22 + §10.36 failure.

• ⚠️ Precision point (don't overstate): §10.36's text contains no mention of technology, cybersecurity, email security, or PII, verified, the terms aren't there. The tech/cyber/ data-security duties come from IRS guidance (Pub 4557/5708 WISP, Security Summit materials) and the proposed Circular 230 amendment (§10.33/§10.35), not from §10.36 itself. The correct framing is by inference: §10.36's general "adequate procedures" duty encompasses an AI-tool policy, so lacking one is a §10.36 exposure, but the reg was not "extended to technology." [INFERENCE, flagged]

• Sources (text pulled): §10.22 · §10.35 · §10.36 · §10.37. Confidence: high, all four pulled from primary text.

What the proposal would add.

• §10.35 (Competence), technological competence: competency would include "understanding the benefits and risks associated with relevant technology used to provide services to clients or to store and transmit tax return and other confidential information" (modeled on ABA Model Rule 1.1 cmt. 8).

• §10.33 (Best Practices), data security: practitioners should maintain a data-security safeguards policy and should consider a breach incident-response plan. ⚠️ §10.33 best practices are aspirational ("should"), not directly sanctionable.

• The preamble expressly references the FTC Safeguards Rule and the WISP requirement.

Status / caveat. Comment period ran through Feb. 24, 2025. As of this research it is not final and not enforceable. Treat technological-competence and incident-response language as the direction of travel, not yet binding, track finalization. The existing general competence duty under §10.35 still applies now.

Source: Federal Register, REG-116610-20 (proposed Circular 230 amendments)

5. SSARS (AR-C) & GAAS (AU-C), AI in attest work

(Relevant only if you perform compilations, reviews, or audits. For tax/bookkeeping-only practices this is background.)

What it is. The accounting/auditing standards that apply when AI assists attest work.

What's settled.

• SAS 142, Audit Evidence (now AU-C 500), ASB July 2020, effective Dec. 15, 2022. Expressly names AI, machine learning, audit data analytics (ADA), and robotic process automation as "automated tools and techniques," and applies the same evidence-reliability attributes, accuracy, completeness, authenticity, and susceptibility to management bias, to evidence produced with those tools. Using AI does not lower the evidence bar. (high, 3-0)

• SAS 145 / AU-C 315 (risk assessment) + the AICPA ASB Technology Working Group practice aid (2023). The practice aid is non-authoritative (an "other auditing publication" under AU-C 200), scoped to risk assessment, and preserves the existing AU-C 500 audit-evidence and AU-C 315 documentation duties for tech-assisted work. When ADA/AI output is used as audit evidence, AU-C 500 governs; documentation duties still apply. (high, 3-0)

• No final AI-specific standard yet. As of early 2026 the ASB has issued NO final AI-specific auditing standard, it is only considering forthcoming guidance on generative AI, agentic AI, and data analytics, with a draft possible by end of 2026. (high, 3-0)

• PCAOB (public-company audits only, likely N/A here). A July 2024 PCAOB staff Spotlight found generative AI used mostly for admin/research, concluded existing responsibility and review standards apply unchanged, and the Board is still assessing whether changes are needed. These are staff views, not a Board rule; the GenAI user stays responsible. (high, 3-0)

Bottom line for attest work: AI is treated as an automated tool inside the existing GAAS framework, same evidence, documentation, and professional-skepticism duties. The CPA remains responsible; AI output is evidence to be evaluated, never accepted on faith. Watch for ASB guidance landing around end of 2026.

Sources: SAS 142 (AICPA) · AICPA practice aid, automated tools in risk assessment · Accounting Today, ASB future projects roadmap · PCAOB, GenAI staff Spotlight (Jul 2024)

6. Georgia State Board of Accountancy, your licensing jurisdiction

What it is. Charlie is Georgia-licensed. The GA Board (rules in Ga. Comp. R. & Regs. Chapter 20-12, under O.C.G.A. Title 43, Chapter 3) sets binding conduct and CPE rules on top of federal and AICPA standards.

What's settled.

• No Georgia-specific AI or technology-competence rule, and no AI/tech/data-security CPE mandate. Rule 20-12-.07 (Competence) is generic. (high, 3-0)

• CPE: 80 hours per two-year renewal (20-hour annual minimum), including 4 ethics credits, 1 of which must cover Georgia Board laws/rules (effective Jan. 1, 2024). (Verified against the GA Board CPE rule; the claim that Georgia requires no ethics CPE was specifically refuted, Georgia does require ethics CPE.)

• Rule 20-12-.11 independently bars disclosing confidential client information without consent, separate from IRC §7216 and the AICPA Code, with no AI/vendor carve-out (narrow exceptions: subpoenas, peer review, Board inquiries). So a Georgia CPA carries a state-law confidentiality duty that can attach to feeding client info to an AI vendor. (high, 3-0, though whether a given AI-vendor transfer is a "disclosure" under the rule is an inference the rule text doesn't spell out.)

• Rule 20-12-.19 incorporates AICPA-established professional standards, meaning SSARS, GAAS, and the AICPA Code become enforceable by the Georgia Board. (high, 3-0. This closes a gap: even though SSTS technically bind "AICPA members," Georgia's incorporation of AICPA standards pulls much of that framework into your state license.)

Bottom line for a GA CPA: No extra AI-specific rule to follow in Georgia, but you carry a state confidentiality duty (20-12-.11), and Georgia enforces AICPA standards via 20-12-.19, so the AICPA Code + SSTS effectively bind you through your license. Keep current on the 4 ethics CPE credits.

Sources: Ga. Comp. R. & Regs. Chapter 20-12 · Georgia Board CPE requirements

6A. Other states, for non-Georgia AI Lab members (check your own jurisdiction)

This doc is anchored to a Georgia license, but AI Lab members practice nationwide. Two layers reach AI use in most states regardless of where you sit, on top of the federal stack above:

1. State board confidentiality + AICPA-incorporation rules. Most state boards (like GA 20-12-.11/-.19) impose a confidentiality duty and incorporate AICPA standards into the license, so the AICPA Code + SSTS effectively bind you through your state board even though SSTS technically bind "AICPA members." Check your board's confidentiality and standards rules.

2. State data-security & breach-notification laws can attach when client data is mishandled in an AI workflow. Examples, each now verified against an authoritative/primary source (members still confirm current thresholds for their own state):

• Georgia: breach-notification duties (O.C.G.A. §§10-1-911/912) require an information broker/data collector to notify residents of a breach of unencrypted personal information "in the most expedient time possible and without unreasonable delay" (plus a 24-hour processor→collector rule and CRA notice when >10,000 residents are affected). ✅ Justia, 2024 GA Code.

• California: Business & Professions Code §22253(a)(8) makes it a disciplinary violation for a tax preparer to "Violate Section 7216 of Title 26 of the United States Code", i.e., a §7216 breach is itself a CA state violation (CTEC-enforced). CCPA has revenue/volume thresholds a solo firm often won't hit, but CA client data still carries breach/contractual exposure. ✅ CA leginfo (official).

• New York: the SHIELD Act requires reasonable administrative, technical, and physical safeguards, including selecting capable service providers and requiring safeguards by contract. ✅ NY Attorney General.

• Massachusetts: 201 CMR 17.03 prescribes a comprehensive written information security program and requires contracts obligating third-party providers to implement and maintain appropriate safeguards, map AI vendors into it directly. ✅ Cornell LII.

Takeaway for the library (national audience): state the federal stack as the floor, then say "check your state board's confidentiality/standards rules and your state's data-security and breach-notification law" rather than asserting any one state's specifics. The four above are verified; other states have parallel regimes, members confirm their own.

What this means in practice, the pre-flight checklist

Before any client data goes into an AI tool, or any AI output goes into a deliverable:

• [ ] §7216, which lane? (1) Safe: internal U.S. firm tool, or approved U.S./contract-bound auxiliary vendor doing prep only, or no TRI entered → no separate consent. (2) Consent or don't: public/general-purpose AI with client info, vendor that trains on/reuses your data, offshore access, or vendor making substantive tax determinations → get written §7216 consent (Rev. Proc. 2013-14) or keep TRI out. When unsure, anonymize or get consent.

• [ ] Safeguards/WISP: Is the AI vendor vetted, under contract/DPA, encrypting data, and logged in your WISP as an assessed third-party app? If not, don't feed it client data, anonymize.

• [ ] Contract terms to confirm: data retention, no training on your inputs, sub-processor disclosure, breach notification.

• [ ] AICPA Confidentiality Rule (ET §1.700.001): Separate from §7216, have you either got client consent or a confidentiality agreement/DPA with the AI vendor before any confidential client info reaches it? (For GA CPAs this duty is also state law, Rule 20-12-.11.)

• [ ] SSTS / reviewer of record: Have you reviewed and taken responsibility for the output? AI never carries the professional judgment, you do.

• [ ] Circular 230 (competence): Do you understand the benefits and risks of the tool well enough to use it competently? (Binding general duty now; explicit tech-competence proposed.)

• [ ] Attest work only (SSARS/GAAS): AI output is audit evidence to be evaluated under AU-C 500, same reliability and documentation duties; the CPA stays responsible.

• [ ] Verify authority: Any tax citation from general AI is unverified until checked against primary source (see Guardrails).

Watch items & remaining nuances

The original open questions on SSARS/GAAS (§5), Georgia (§6), the AICPA Confidentiality Rule (§3), dedicated gen-AI guidance, and vendor contract terms are now answered above. What remains is forward-looking or fact-specific:

1. ASB AI guidance (expected ~end of 2026). No final AI-specific auditing standard exists yet, the ASB is considering generative-AI/agentic-AI/data-analytics guidance. Track for a draft.

2. Final Circular 230 amendment. The technological-competence (§10.35) and data-security (§10.33) provisions remain PROPOSED, not final. Track finalization.

3. Exact ET subsection numbering for the AICPA third-party-service-provider interpretation should be confirmed against the live Code (this pass relied on AICPA/JofA coverage).

4. "Is an AI-vendor transfer a 'disclosure'?" Under both §7216 and GA Rule 20-12-.11, applying the confidentiality duty to a specific AI data-flow is a reasonable inference, not spelled out in the rule text, a fact-specific judgment, so favor the conservative reading (consent or DPA).

5. Precise §314.4(f) Safeguards contract language / whether a specific DPA form is expected.

Honesty notes on this document (per our own standard)

• The Circular 230 tech-competence / incident-response provisions are PROPOSED, not final.
• The $100,000 §6713 figure is a myth for general violations, it's identity-theft-specific.

• SSTS bind AICPA members, but for a Georgia CPA, Rule 20-12-.19 incorporates AICPA standards into the state license, so the framework effectively binds you anyway.

• Georgia DOES require ethics CPE (4 credits, 1 on Board rules), a contrary claim was refuted 0-3 in research. The "ASB singles out generative AI as distinct" claim was also refuted (1-2); the ASB currently treats AI within the general automated-tools framing.

• The AICPA Technology Working Group practice aid and the PCAOB GenAI Spotlight are non-authoritative (guidance/staff views), not binding standards.

• Several primary URLs (eCFR, Federal Register, IRS Rev. Proc. PDF, some GA rule pages) blocked automated fetch and were confirmed through mirrors (Cornell LII, GA SOS rules portal) plus corroborating professional sources; regulatory text was matched verbatim, so confidence on the statutory/regulatory claims remains high.