Best practice guide · For accounting firms

What client data should never go into a public AI tool

Part of the FirmSteward educational series for accounting firms using Microsoft 365.

A public AI tool, in practice, is any AI chatbot that anyone can open on the web or on their phone and start typing into, usually free or on a cheap monthly plan — think of the general-purpose assistants staff open in a browser tab. For an accounting firm, the useful question is not whether AI is good or bad. It is smaller and more practical: when a staff member reaches for one of these tools, which client information should never be pasted in?

What we mean by "public AI tool"

A definition worth holding onto: a public AI tool is one that runs outside your firm's control — on someone else's servers, governed by someone else's terms, with the text you enter feeding whatever that vendor does with it. That is different from an AI feature embedded in your own Microsoft 365 tenant under your firm's own license and administrator controls, where you can see and set the data-handling settings yourself.

This article is about the first kind: the free and general-purpose tools staff already have open. It is an educational guide, not legal, tax, compliance, or cybersecurity advice — and it describes risks in general terms rather than making claims about any specific vendor's behavior.

The client data that carries the most risk

Some information is so sensitive that it should effectively never be typed into a public AI tool, no matter how convenient it looks. For an accounting firm, the highest-risk categories are:

• Tax returns and tax documents — full returns, schedules, and the underlying records, because they combine income, dependents, and personal detail in one place.
• Payroll data — pay rates, bank details, wage totals, and the list of who works where.
• Banking and account information — statements, account numbers, routing numbers, and transaction detail.
• W-9s and tax identification numbers — including full Social Security numbers, EINs, and vendor identity records.
• Identity information generally — Social Security numbers, individual taxpayer identification numbers, date of birth and address combinations, driver's license numbers, and anything that can be used to impersonate or defraud a client.
• Passwords or access information — login credentials for client portals, banking, or any system, which should never be shared with any AI tool regardless of settings.

The common thread is that each of these is identity data: information that identifies a specific person or business and could be misused if it left your control. SSNs are the clearest example, but a full tax return is nearly as sensitive because it bundles so many identifying facts together.

Why it is risky even when nothing seems to go wrong

It is worth being precise about the risk, because the honest picture is not quite the one that makes headlines. When a staff member pastes a client's tax return into a free chatbot, the main danger is usually not a dramatic hack. The more realistic problem is that you have handed the information over:

• The data leaves your control. It now sits outside your firm's systems, on infrastructure you do not own and cannot fully audit. Your control over who sees it and what happens to it ends at the moment you paste it.
• It may be used for training. Many free and public tools reserve the right to use the conversations you enter to improve their models. That is a general and accurate statement about how untested public chat tools are often designed — and it is one good reason to treat the platform as one you do not control.
• There is no reliable way to take it back. Unlike a file you can delete from your own system, a conversation you have submitted is typically outside your ability to retrieve or remove. You simply lose track of it.
• It can be relayed onward. A chat log is not a private, sealed record. Someone with access to that tool account, or to a support process for it, can read or copy a conversation. You cannot count on a promise of privacy from a tool whose terms and safeguards you have not reviewed.

Notice that none of this requires a data breach. The point is not that a hacker steals the file — it is that you transferred the data somewhere you do not control, and you cannot get it back. That alone is the risk. It is a control and confidentiality problem, not necessarily a security one, and it is exactly the kind of issue an accounting firm does not want to explain to a client.

What is lower-risk to paste in

The goal is not to ban AI — it is to be deliberate about what goes in. Much of what you might want to use a tool for does not require sensitive client data. Lower-risk uses include:

• Boilerplate and templates. Standard engagement letters, generic email phrasing, common policy language, or accounting-process descriptions that contain no client names or identifiers.
• Summaries without identifiers. A rough, non-confidential summary of a situation rewritten so it contains no names, SSNs, account numbers, or figures that could identify the client.
• Drafts scrubbed of PII. A draft you have deliberately stripped of personally identifiable information before you paste it — for example, replacing a client name with "Client A" and removing all numbers that identify them.
• General professional questions. Asking how to word a note, organize an email, or explain a common concept, framed in a way that does not expose client detail.

The pattern is simple: if someone else could use what you paste to identify or harm a client, do not paste it. If no identifiable client information is in the text, the exposure is far smaller.

A practical rule staff can actually follow

Policies that list every exception fail because staff cannot remember them. A rule that staff can actually follow is one that fits on a single line. For an accounting firm, this one works:

Make it concrete. "Client's name, SSN, tax ID, pay, bank, or account detail" covers nearly all of the highest-risk data without asking staff to memorize a list of document types. The second half tells them what they can do, so the rule feels like guidance rather than a ban. If a tool is embedded in your Microsoft 365 tenant under firm controls and staff are not sure of its settings, treat it differently from a public chatbot — and, as with anything here, have someone with responsibility for the firm's data practices confirm the specifics rather than guessing.

This is not legal advice

Where does your firm stand?

See your AI-readiness starting point.

FirmSteward's free 10-question scorecard helps accounting firms using Microsoft 365 see where they may need a written AI-use boundary, staff guidance, and a named owner. It is an educational starting point — not a security assessment, legal review, or compliance certification.

Take the free scorecard