Using AI on Client Data Without Creating a Confidentiality Problem

Nearly every accountant I talk to is using AI for client work. Almost none of them are comfortable describing exactly how, and the discomfort is well founded — the common workflow is genuinely the risky one.

That workflow is: export a client’s transactions to CSV, open a chat window, paste it in, ask a question. It works. It is also the version where you have the least control over what happens to the data afterward, and the version hardest to describe to a client who asks.

This post is about what actually happens to data in each pattern, and why connected access is a materially different risk profile from pasting.

What your engagement letter probably already says

Start here, because it determines everything else. Most standard engagement letters include a confidentiality clause and, increasingly, a subcontractor or third-party disclosure clause. AICPA guidance treats disclosure of client information to a third-party service provider as something requiring either client consent or a confidentiality agreement with that provider.

An AI vendor processing client financial data is a third-party service provider. That is true whether you pasted the data in or connected a tool to it. The mechanism does not change the classification.

What changes is how well you can answer four questions:

• What data went to the provider?
• How long do they keep it?
• Is it used to train models?
• Can you revoke access?

With a paste, the honest answer to the first question is “whatever was in that CSV, and I would have to go back and look.” That is the part that should bother you.

The three patterns, ranked

Pattern 1: Paste the data in

You export and paste. The data goes into the conversation and stays there for the life of that conversation, in an account that is probably yours personally rather than the firm’s.

The specific problems are practical rather than theoretical. Exports are over-broad — you pasted the full transaction register because filtering it first was work, so the provider now has twelve months of a client’s activity when the question concerned one month. There is no audit trail; six months later you cannot reconstruct which clients’ data went into which conversations. And on a consumer tier, the default retention and training settings are frequently not the ones you would choose.

If you do only one thing after reading this: check whether the account you are using has training turned off. On business and enterprise tiers this is typically the default. On free and personal tiers it frequently is not.

Pattern 2: Connect the tool, read-only

Instead of moving data to the assistant, you grant the assistant scoped access to read the data where it lives. Claude and ChatGPT both support this through MCP, which is the mechanism our own integration uses.

The difference that matters: the assistant retrieves only what the question requires. Ask about one client’s Q2 materials spend and the query returns that client’s Q2 materials receipts. The other eleven months and the other twenty clients are never transmitted, because nothing asked for them.

You also get properties a paste cannot have:

• Revocation. Access is a token you can destroy. Ours is revocable from account settings and takes effect within seconds. A pasted CSV cannot be unpasted.
• Scope limits. Read-only means read-only. The assistant cannot alter a client’s books, because the tools to do so are not exposed to it.
• A boundary you can describe. “It can read receipt data for clients who have authorized me, and nothing else” is a sentence you can put in front of a client. “I paste things in as needed” is not.

Pattern 3: Do not use AI on client data at all

Entirely defensible, and the right answer for some firms and some clients. Worth stating plainly rather than treating as a failure of nerve. The cost is real but bounded: you keep doing the assembly work by hand.

The middle path some firms take is to allow connected read access for their own book of clients while prohibiting any use on clients who have declined. That requires knowing which clients declined, which requires having asked.

Why we made write access opt-in

Our integration is read-only by default. Claude can query receipts, books, and reconciliation status. It cannot upload, edit, or delete anything.

That was deliberate, and the reason is not caution for its own sake. Language models produce confident, plausible output that is sometimes wrong. A wrong answer to a question is a thing you notice and correct. A wrong write to a client’s books is a thing that sits there looking correct until someone reconciles against a bank statement three months later.

Write tools are coming, and they will be opt-in per account rather than on by default, because the failure mode deserves a deliberate decision rather than an inherited setting.

Client consent, concretely

On our Professional plan an advisor cannot simply attach themselves to a client’s books. The client receives an approval request and has to accept it; until they do, the advisor sees only that an invitation is outstanding, not any of the client’s data. The link is revocable from either side.

We built it that way because the alternative — an advisor silently gaining access to someone’s financial records — is not a thing a client should discover after the fact. It also means the consent conversation has already happened before AI enters the picture at all.

For the AI question specifically, the disclosure that seems to land best with clients is short and specific:

Two things make that work. It offers a real opt-out rather than a notification dressed as a choice. And it is specific about the mechanism, which is what distinguishes it from the vague reassurance clients have learned to discount.

The practical checklist

• Confirm training is disabled on whatever AI account touches client work
• Use a firm account, not a personal one, so access leaves with the seat rather than with the person
• Prefer connected read access over pasting exports — less data moves, and you can revoke it
• Keep write access off until you have a specific reason to turn it on
• Ask clients rather than assuming, and record who declined
• Review your engagement letter’s third-party provider language with whoever advises you on it

None of this is exotic. It is the same reasoning firms already apply to cloud document storage and outsourced bookkeeping, applied to a tool that arrived faster than the policies did. The firms that will be comfortable in two years are the ones writing the policy now, while the stakes of getting it slightly wrong are still low.