Client Data Privacy When Using AI Tools: The DPDP Act for Indian CAs

Every time a CA pastes a client's books, PAN-linked data, or salary register into an AI tool, personal data leaves the firm's control. The Digital Personal Data Protection Act, 2023 (DPDP Act) now sits on top of the confidentiality duty CAs already owe, and it asks a sharper question: where did that data go, who processes it, and on what terms? This piece sets out what a CA firm must think about before client data touches any AI system.

Why a CA is effectively a data fiduciary

The DPDP Act is built around two roles. The data principal is the individual the personal data is about — your client, their employees, their customers. The data fiduciary is whoever decides why and how that personal data is processed. When your firm decides to run a client's payroll through a tool, or to summarise a director's KYC for a filing, your firm is making those decisions. That makes the firm a data fiduciary for a large pool of personal data it never used to think of in those terms.

This is not a replacement for the confidentiality you already owe. Under the Chartered Accountants Act and the ICAI Code of Ethics, a member is bound to keep client information confidential and not to use it for any purpose other than the engagement. The DPDP Act runs in parallel: confidentiality is your professional duty to the client; data protection is a statutory duty toward every individual whose personal data you hold. A firm can be fully compliant with client confidentiality and still mishandle personal data under the DPDP framework — for example by sending it to a tool that trains on it. The moment you choose to process personal data in an AI tool, you carry the obligations of a fiduciary — lawful basis, purpose limitation, security, and accountability — and you cannot fully delegate them to the vendor.

The real risk: pasting client data into consumer LLMs

The most common exposure in practice is the simplest one. A preparer is stuck on a notice or a reconciliation, opens a public chatbot, and pastes in the client ledger — names, GSTINs, PANs, bank details, salary figures — to get a quick answer. It feels harmless. It is the single largest data-protection risk in most small firms.

Here is what goes wrong with that move:

• The data may train the model. Many consumer-grade AI services reserve the right to use what you type to improve their systems. Identifiable client data fed into such a tool can become part of training data outside your control, and it cannot be pulled back.
• There is no contract. A free consumer login is not an engagement. There is no data processing agreement, no confidentiality clause specific to your client, and usually no enforceable commitment about retention or deletion.
• Processing is cross-border by default. Most consumer LLM infrastructure sits outside India. Your client's personal data is being processed on servers you cannot point to, under terms you did not negotiate. The DPDP Act does contemplate restrictions on transfers to certain countries; rather than tracking which list applies at any moment, the safer working rule for a CA is to know exactly where client data is processed and to be able to justify it.
• You lose the audit trail. If a client later asks how their data was used, "I pasted it into a chatbot" is not an answer you want to give a disciplinary committee or a regulator.

The fix is not to ban AI — it is to separate anonymised questions from identified data. Asking an AI to explain a provision, draft a template, or structure an argument is low-risk because no personal data needs to leave the building. The same discipline that makes prompting AI for GST notices effective also keeps it safe: redact the identifiers, ask the legal or computational question, then apply the answer to the real file inside a tool you control.

What to check in an AI vendor

Once you move from a public chatbot to a tool you actually deploy across the firm, the question shifts to whether the vendor handles data the way a fiduciary must. The terms of service are where this lives, and you should read them the way you read an engagement letter — not skim them.

Data residency and hosting

Ask where the data is physically processed and stored. India-hosted infrastructure removes the cross-border complication entirely and makes your position far easier to defend. If a vendor processes outside India, you need to know which jurisdiction and be satisfied it is permissible — and you need that in writing, not in a sales call. Tools positioned for the Indian compliance context, such as Serenvya — which pairs AI process automation with DPDPA compliance consultancy for Indian businesses — tend to take this question seriously because it is their core market.

No training on your data

This is the clause that separates an enterprise tool from a consumer toy. The vendor should commit, in writing, that your inputs and outputs are not used to train their models and are not shared with the underlying model provider for training. Enterprise and business tiers of most serious tools say this; free consumer tiers usually do not. If you cannot find the clause, assume the worst.

Security safeguards

The DPDP framework expects a data fiduciary to apply reasonable security safeguards. Pushed down to your vendor, that means encryption in transit and at rest, access controls inside the vendor's organisation, and a credible security posture you can ask about. A vendor built for regulated finance workflows — Finnect, for instance, positions its autonomous AI finance agents around secure, compliant enterprise workflows — should be able to answer security questions without flinching.

Deletion and retention

You need to know how long the vendor keeps your data and whether you can have it deleted on demand. Purpose limitation means data should not be retained beyond the purpose it was collected for; a vendor that cannot delete on request makes it hard for you to honour that and to respond if a client withdraws consent.

Sub-processors

Most AI tools are themselves built on someone else's model and someone else's cloud. Ask who the sub-processors are, what they receive, and under what terms. A chain of three vendors is only as private as its weakest link, and you remain accountable for the whole chain. Research-oriented tools like Taxmann.ai, which offers AI legal and tax research and drafting backed by Taxmann content, are lower-risk for this because much of the value comes from curated content rather than from ingesting your client files — but you should still confirm what happens to anything you upload.

Consent and purpose limitation with client data

Two DPDP principles bear directly on day-to-day AI use.

Lawful basis and consent. Personal data should be processed for a lawful purpose, and in most cases that rests on the data principal's consent or a legally recognised legitimate use. When you collected a client's data, the understood purpose was almost always the engagement — file the return, conduct the audit, run the payroll. Feeding that same data into a new AI tool is fine when it serves that original purpose. It becomes a problem when the tool itself repurposes the data, which is exactly why the no-training clause matters: it stops your client's data being used for a purpose your client never agreed to.

Purpose limitation. Data collected for one engagement should not quietly migrate into another use. Practically, this means client A's data should not end up in a shared, cross-client AI workspace where it could surface in client B's outputs. When you evaluate a tool, ask how it isolates data between clients and between your firm and the vendor's other customers.

Data of children deserves a separate flag. The Act treats the personal data of children with extra care and generally expects verifiable parental consent and a bar on processing that could harm them. Most CA work touches this only at the edges — a minor's PAN in a family trust, a guardian's filing — but if a tool will process such data, treat it as a higher-sensitivity case and confirm the vendor and the engagement can support it.

Your own firm's obligations

Vendor diligence is half the job. As a data fiduciary, the firm has duties that no tool can discharge for you.

• Access controls. Not every preparer needs every client's full data set inside the AI tool. Role-based access, individual logins rather than a shared password, and removing access when staff leave are basic and expected.
• A clear internal policy. Staff should know, in writing, what may and may not be put into which tools. The rule "no identifiable client data in any consumer chatbot" should be explicit, not assumed.
• Breach response. The DPDP framework expects a data fiduciary to act on a personal data breach, including notifying as required. You cannot notify what you cannot detect, so you need to know which tools hold client data and have a plan for who is told, and how, if one is compromised. Decide this before an incident, not during one.
• Records. Keep a simple inventory of which AI tools the firm uses, what data each one touches, and where it is processed. This is the document that lets you answer a client — or a regulator — calmly.

This is also where the free-versus-paid choice becomes a compliance decision, not just a budget one. As free vs paid AI accounting tools discusses, the paid tiers are usually where the data processing agreement, the no-training commitment, and the deletion controls actually live — the things a fiduciary needs.

A due-diligence checklist for evaluating an AI tool

Before you let any AI tool touch client personal data, work through this:

1. Where is the data processed and stored? India-hosted is simplest to defend. If not, which country, and can you justify it?
2. Does the vendor train on your data? Find the clause in writing. No clause means assume yes — and reconsider.
3. Is there a data processing agreement? A real contract with confidentiality, security, and retention terms — not just consumer terms of service.
4. What are the security safeguards? Encryption in transit and at rest, internal access controls, and a security posture you can question.
5. Can you get data deleted? On request, and on a defined retention schedule consistent with purpose limitation.
6. Who are the sub-processors? Map the full chain — model provider, cloud, any others — and confirm each link's terms.
7. How is client data isolated? Between your clients, and between your firm and the vendor's other customers.
8. Does the original engagement cover this use? If the AI use serves the purpose you collected the data for, you are on solid ground; if it repurposes the data, stop.
9. What is your breach plan? Know who would be notified, by whom, and how fast, before you onboard the tool.

Run this once per tool, write down the answers, and revisit when a vendor changes its terms.

Frequently asked questions

Is it illegal to use ChatGPT or similar tools for client work?

Not inherently. The risk is not the tool — it is putting identifiable client personal data into a consumer tier with no contract and a right to train on your inputs. Using such a tool to discuss an anonymised problem, draft a template, or explain a provision is low-risk. The line is whether client personal data leaves your control on terms you did not agree.

Does the DPDP Act apply to a small CA firm or only to big companies?

The Act applies to the processing of digital personal data regardless of firm size — the duties of a data fiduciary do not switch off because the firm is small. Some obligations scale with the volume and sensitivity of data, and certain rules under the Act were still being finalised as of mid-2026, so confirm the current position. The prudent stance for any firm is to act as a fiduciary now rather than wait.

How is this different from the confidentiality I already owe under the ICAI Code?

Client confidentiality under the Chartered Accountants Act and the ICAI Code of Ethics is your professional duty to the client. The DPDP Act is a statutory duty toward every individual whose personal data you hold, with its own requirements on lawful basis, purpose limitation, security, and breach response. They overlap but are not the same — you can keep a client's secrets and still breach data-protection duties by sending personal data to a tool that misuses it.

Can I just anonymise client data before using an AI tool?

Removing names, PANs, GSTINs, and other identifiers genuinely reduces risk and is the right default for any question that does not need the real identities — most research and drafting tasks do not. But be careful: enough indirect detail can re-identify a person, so anonymisation is a discipline, not a checkbox. For anything that must process identified data, rely on a vetted tool with the right contractual terms instead.

The takeaway

The DPDP Act does not stop a CA from using AI — it tells you how to use it without putting client personal data at risk. The firm is a data fiduciary the moment it decides to process a client's data, so the obligations of lawful basis, purpose limitation, security, and breach response come with the territory and cannot be handed entirely to a vendor. The two rules that prevent most trouble are simple: keep identifiable client data out of consumer chatbots, and only feed it to tools whose terms — India hosting, no training on your data, deletion, named sub-processors — you have actually read. Use the software directory to find tools built for the Indian compliance context, and run every one of them through the checklist above before it touches a client file.