Confidentiality and client data · AI for Accountants

A junior in a four-partner firm in Naxal has a TDS reconciliation due by 5 p.m. The client is a mid-size hotel; the source is a 47-page bank statement with every guest deposit, every supplier transfer, and the proprietor’s personal account number on the header of every sheet. The junior opens the free ChatGPT account on her personal phone, uploads the PDF, and asks the model to categorise the transactions. Twenty minutes later she has a clean schedule. She is also, depending on how you read the ICAN code and the engagement letter, in breach of professional duty — and the firm has no idea it happened. This is the most common AI mistake in Nepali practice today, and it is the one this chapter starts with because everything else in safe AI use rests on getting confidentiality right.

The duty has not moved

Three documents already govern what you can do with a client’s information, and all three were written before generative AI existed. The ICAN Code of Ethics binds you, as a member, to confidentiality over information acquired in the course of professional work — and the duty does not lift the moment the engagement ends. The engagement letter usually adds explicit terms about how client data is stored, who may see it, and what happens at termination. Statute and sectoral regulation sometimes pile on: banks have their own confidentiality and data residency rules; tax practitioners handling third-party data have their own exposures.

None of these documents say “you may paste this into a chatbot if you find it convenient.” When a free-tier consumer LLM ingests a client document, several things happen that may breach all three: the data leaves your firm’s control, it crosses a border, it may be used to train a future model, and you have no contract with the provider that gives the client any recourse. The fact that the model gave you a useful answer in twenty minutes does not undo any of those four things.

Three safe defaults — pick one, every time

Once you accept that the default is unsafe, the practical question becomes which alternative you reach for. There are three that work in a Nepali small-firm setting, and a serious firm picks at least one and writes it down.

1. Redact before you upload. For most analytical work — categorising transactions, drafting commentary, summarising patterns — the model does not actually need the account numbers or the names. Strip them. Replace “Hotel Shangri-La account 0123-4567” with “Client A account [REDACTED]” and “Ram Bahadur Thapa, PAN 301234567” with “Customer 7.” The model’s output is the same; your exposure collapses. This is the cheapest defence and the one solo practitioners and tiny firms should default to.

2. Use an enterprise-tier tool with a no-training contract. ChatGPT Team, ChatGPT Enterprise, Claude for Work, Microsoft Copilot for business, Google Workspace’s Gemini tier — each of these is sold with an explicit contractual term that your inputs are not used to train future models, and with stronger access controls than the consumer product. The cost in 2026 sits roughly in the range a mid-size Kathmandu firm can afford for the partners and senior staff who handle sensitive work. The free-tier account remains for non-client tasks: drafting blog posts, summarising public circulars, learning the tools.

3. Run a local or on-premise model for the most sensitive work. For a firm with one or two clients in regulated sectors — a bank, a finance company, a hospital — a local model running on a firm-owned workstation, with the data never leaving the office network, removes the cross-border and third-party-processor problems entirely. The trade-off is that local models in 2026 are noticeably weaker than the frontier hosted models, and someone in the firm has to maintain them. It is the right answer for the narrow band of work where the regulatory cost of any leak is higher than the productivity cost of a weaker tool.

Calibrate by category of risk

Not every piece of client data carries the same weight, and a sensible policy treats them differently rather than imposing one rule on everything.

Highest risk is anything that combines identity with a financial or legal position: full bank statements with account numbers and balances, KYC documents with citizenship details and national IDs, payroll registers with salary against name, audit working papers with management representations, tax notices with assessment details. Nothing in this category should go into a consumer chatbot under any circumstances. The default for this tier is redaction or an enterprise tool, and the engagement file should record which.

Moderate risk is information that reveals something specific about the client but does not by itself enable identity theft or regulatory exposure: a categorised P&L without supplier names, a depreciation schedule by asset class, a VAT working with vendor codes rather than vendor names. Here the calculus is finer. An enterprise tool is comfortable; a consumer tool with strong redaction may be acceptable; a free-tier consumer tool with the raw data is still wrong.

Lower risk is anonymised aggregate information that could not, even by reverse engineering, point back to a specific client: industry trends, public filings of listed companies, hypothetical scenarios for staff training. This tier is where you learn the tools, where you experiment freely, where a junior should be encouraged to try things. Confidentiality risk is essentially nil; the only remaining risk is the model being wrong, which we will address in the next section.

The Nepali concern most firms have not heard

There is one Nepal-specific layer that English-language AI guidance will not mention, and it deserves a paragraph on its own. Nepal Rastra Bank has been progressively tightening data residency requirements for banks, finance companies, and payment service providers — and the direction of travel is toward stricter, not looser, rules. If your client is in any of these sectors, you cannot assume their data may freely cross borders. Some categories of customer data are required to be processed and stored within Nepal; what counts as processing is being interpreted broadly. A practitioner uploading a regulated client’s transaction data to a US-hosted LLM is not just risking a confidentiality breach against the engagement letter — they may be putting the client into regulatory exposure with their own primary regulator. For these clients, a locally-deployed model or a clearly redacted analytical extract is the only safe path. The same logic is starting to creep into insurance and telecom; assume it will reach more sectors over the next two to three years.

Micro-policies that survive a busy week

A confidentiality policy that exists only in the partner’s head will not survive March, when the staff are tired and the deadlines are stacked. The policies that work are short, specific, and written into the workpaper template.

1. Never paste raw bank statements, KYC documents, or payroll registers into a consumer chatbot — ever, regardless of how anonymous it feels.

2. For client work, use the firm’s enterprise account; the free account on a personal phone is for personal use only, and the firm does not pretend otherwise.

3. When AI was used on a piece of work, the workpaper records which tool was used, what was uploaded (redacted or not), and what the human reviewer changed. This takes thirty seconds and protects the firm if a question arises later.

4. If a client asks whether AI is being used on their engagement, the answer is the truth, calibrated to what they asked. We will return to this in the disclosure discussion in Section 3.

5. Reviews of AI use are added to the partner’s annual file review, not left to drift. What is not measured is not managed.

These are not heroic measures. They are the kind of unglamorous discipline that distinguishes a firm that has thought about this from one that is hoping nothing goes wrong.

Check your understanding

Quick check

—

A junior in your firm has a tight deadline and uploads a client's full PDF bank statement — with account numbers, balances, and the proprietor's name visible — into a personal free ChatGPT account to speed up categorisation. Which of the following is the most accurate description of what went wrong and the safest workflow she should have used instead?

Nothing went wrong; the AI gives the same answer either way, so the workflow is fine as long as the output is correct.
The error is purely technical; she should have used the paid version of the same consumer tool from her own phone.
Uploading raw, identifiable client data to a consumer chatbot is a confidentiality breach by default; she should have either redacted identifiers first, used the firm's enterprise-tier account with a no-training contract, or for highly regulated clients used a local model.
The error is that she used her personal phone; the same upload from the office desktop would have been compliant.

Quick check

—

A partner argues the firm does not need a written AI confidentiality policy because, in his words, "everyone here is sensible and we all know not to do anything stupid." What is the strongest objection to this position?

Sensible people never make mistakes, so the partner is right.
Unwritten standards are not auditable, do not survive staff turnover or busy season, give the firm no defence if a breach is later questioned, and tend to drift downward when nobody is watching — none of which has anything to do with whether the current staff are sensible.
ICAN inspectors look only for written policies and ignore actual behaviour.
A written policy automatically prevents any breach from ever happening.

What comes next

Confidentiality is the first discipline, but it is not the only one. Once you have decided what data the model is allowed to see, the next question is what you are allowed to do with what it gives back. The next section turns to the default rule that every AI-produced number is unverified until you have checked it against a source you trust — and to the workflow that lets that rule survive a busy week.