Plainstart Back to the kit

Article

AI and Client Confidentiality: What Professional Services Firms Need to Decide

The Real Problem Is Not the AI Tool

When a member of staff opens ChatGPT, copies a client's financial summary into the prompt box, and asks for a draft commentary, they have probably not thought hard about what they just did. They wanted a faster first draft. That is a reasonable thing to want.

The problem is not the staff member's intent. The problem is that the firm has not decided whether that action is acceptable, and if it is acceptable, under what conditions and with which tools. Without that decision, every individual makes their own call, and the calls will be inconsistent.

This article works through what professional services firms, specifically accountants, solicitors, consultants, and agency owners, need to think about and decide before those calls are made for them.


What Changes When the Data Is Not Yours

Most guidance on AI data risks treats the question as a privacy or security question. For professional services firms, there is a prior question: you hold a lot of data that belongs, in a meaningful sense, to your clients. You are not the data subject in the privacy sense, and you are not the beneficial owner of the information in the commercial sense. You are a custodian.

That custodian relationship creates obligations that go beyond data protection law. A client tells their accountant about a planned transaction. A solicitor is told about a dispute that has not yet become public. A consultant is given access to internal margin data. In each case, the client disclosed that information in a relationship of confidence, for a specific purpose. They did not consent to it being shared with anyone outside that relationship, including the processing infrastructure of a third-party AI product.

This matters for one practical reason: consent is the mechanism that normally governs whether you can pass information on. You have your client's implied or express consent to use their information to provide the service they hired you to provide. You almost certainly do not have their consent to pass it to a system operated by a third party, even if that third party has good security practices.

Whether that passing-on constitutes a breach depends on jurisdiction, the specific professional duty, and the tool in question. But the default assumption should be: without consent, do not do it. That is a conservative position, and it is the right starting point.


Engagement Letters and Whether Existing Wording Covers This

Most professional services firms have standard confidentiality clauses in their engagement letters. A typical clause says something like: the firm will hold information provided by the client in confidence and will not disclose it to third parties except as required by law or with the client's consent.

The question is whether using an AI tool counts as a disclosure to a third party.

In most cases, the answer depends on how the tool processes the data. If an employee pastes client data into a consumer AI product that uses inputs for model training, a credible argument exists that this is a disclosure to a third party. The data leaves the firm's control. The provider can use it. The client did not agree to that.

If the firm uses an enterprise version of a tool where the provider contractually commits not to train on the data, not to store it beyond the session, and to process it only on the firm's behalf, the situation is closer to using any other processing sub-contractor. Whether existing wording covers it depends on whether the engagement letter contemplated sub-processors, whether there is a data processing agreement in place, and what the professional body's view is.

The honest answer for most firms is that their existing engagement letter wording was written before AI tools were common. It probably does not address this specifically. Firms that want to use AI tools on client work should take advice on whether their standard engagement letters need updating. This is a legal question and outside the scope of this article. A qualified solicitor with experience in professional services can give a view.

What a firm can do without legal advice is audit what their letters currently say, identify the gap, and flag it as something to resolve.


The Difference Between a Tool That Trains on Inputs and One That Does Not

This is the most important technical distinction a non-technical principal needs to understand.

Some AI tools use the text you type into them to improve the underlying model. Your inputs become training data. The information goes into a process that, in aggregate, shapes how the model responds to future users. This is how many consumer products work, or have worked, at various points in their development. Whether any given tool does this today depends on the provider's current terms of service, which change.

Other tools, typically paid enterprise tiers or API-based deployments, contractually commit that your inputs are not used for training. Your data is processed to generate a response and then discarded. The provider acts as a processor, not a beneficiary of the data.

The firm's obligation is to know which category any tool in use falls into, and to have a clear policy about which category is acceptable for client work.

A tool that does not train on inputs and has strong contractual data protection terms is not automatically safe to use on client data, because other questions remain: where is the data processed, who has access to it, how is it secured in transit. But it is in a meaningfully different position from a consumer product with no such commitments.

Practically, this means the firm should read the terms of service for any tool being used, or have someone do that reading, and record what those terms say at the point of assessment. Terms change. The assessment needs to be reviewed periodically.


What to Tell a Client Who Asks

Clients are starting to ask. Some ask before engagement. Some ask mid-project when they see AI tools mentioned in the press. Some ask after the fact.

The firm needs a short, honest answer ready. Here is a version of what that answer could contain.

First, tell the client whether the firm uses AI tools at all, and in what capacity. If the answer is yes, be specific about the type of work. Drafting, summarising internal documents, preparing templates, whatever the actual use is.

Second, explain what the firm does not do. If the policy is that client data is never pasted into any external AI tool without explicit consent, say so.

Third, if the firm does use AI tools on client work, explain which category of tool is in use, whether it trains on inputs, what the data protection terms are, and whether the client's consent is required before proceeding.

Clients generally respond better to a clear, frank answer than to a vague reassurance. If the firm does not yet have a policy, the honest answer is: we are working through this and we will confirm our position. That is better than an inaccurate commitment.


Where Professional Body Obligations Sit on Top of General Practice

Regulated professionals in the UK and most comparable jurisdictions are subject to their professional body's conduct rules, and those rules sit on top of general law. They are not a substitute for it. They are an addition.

The ICAEW, the SRA, the CIPD, the CMC, and other bodies have begun issuing guidance on AI use. Some of that guidance is cautious. Some of it sets specific expectations about confidentiality, data handling, and client disclosure. The content of that guidance changes as regulators update their positions.

This article cannot summarise what your professional body currently says, because those positions are being updated regularly and any summary here could be out of date by the time you read it. What the article can say is this: check your own body's current guidance, treat it as binding, and factor it into whatever policy the firm adopts. If the body has said nothing yet, err on the side of caution. Regulators do not generally excuse a breach on the grounds that guidance was not yet explicit.


A Worked Example: One Firm, One Use Case

A small firm of management consultants, eight staff, works with mid-market clients on operational improvement. They hold commercially sensitive internal data: headcount costs, supplier contracts, margin by product line.

The principal wants to know whether it is acceptable for consultants to use an AI tool to draft sections of the final client report, using data from the client's own documents as inputs to the prompt.

The firm works through the following questions.

What tool is in use? The team has been using a consumer version of a widely available AI assistant. The terms of service for that version include a clause permitting use of inputs for model improvement. Assessment: not acceptable for this use case without client consent, and arguably not acceptable even with consent because the firm has no ability to ensure the data is handled in line with its own confidentiality obligations.

Is there an enterprise alternative? Yes. The same provider offers an enterprise tier with a data processing agreement, no training on inputs, and data residency in an acceptable region. Cost is manageable. Assessment: this version is a candidate for approved use.

Do the engagement letters address this? No. The standard letter says the firm will not disclose client information to third parties. Using the enterprise tool with a data processing agreement is probably not a disclosure in the relevant sense, but the letter should be reviewed by the firm's solicitor.

Does the client need to be told? The principal decides to add a short paragraph to the standard engagement letter explaining that the firm may use approved, enterprise-grade AI tools for internal drafting purposes, with no client data used for model training, and that the client can ask for confirmation of which tools are in use. This is not the same as asking for consent every time, but it gives the client the information and the opportunity to raise a concern.

What about existing clients? The principal writes a short note to current clients explaining the policy. Most do not respond. Two ask follow-up questions. Those questions are answered directly.

The result: the firm has a defined, documented position on one specific use case. It is not a complete AI policy, but it is a decision that has been made and can be communicated.


The Practical Starting Point

Most firms do not need to resolve every question before they move. They need to stop the pattern of each individual making their own call, and replace it with a documented firm-level position on what is and is not acceptable.

That position starts with a usage policy: a short, clear document that says what tools are approved, what categories of work are in scope, and what staff must not do. It does not need to be long. It does need to exist.

Plainstart's free AI Usage Policy is a plain-language template built for exactly this starting point. It is available at no cost, and it gives a firm something concrete to review, adapt to its own context, and put in front of its team.

AI adoption, done properly.

[Get the free AI Usage Policy at Plainstart]

Free download

The AI Usage Policy your team can actually follow

One page, plain language, ready to put in front of staff today. No cost, no catch.

Get the free policy