AI and client confidentiality: the practical rules

What does de-identification actually require?

More than deleting names. A document is de-identified when someone who knows the market could not work out who it concerns from what is left.

That is a higher bar than it sounds in professional services, because the identifying detail is usually structural rather than nominal. "A Sydney orthodontics group with four practices selling to a listed consolidator" identifies a client to anyone in that sector, with no names anywhere in the file.

A practical method that holds up:

1. Strip names of people, entities, brands and addresses.
2. Replace specific figures with ranges when the exact number is distinctive.
3. Generalise the sector one level, from "reformer pilates studios in inner Sydney" to "boutique fitness operators".
4. Remove dates that pin the matter to a known transaction.
5. Read it back and ask: could a competitor guess who this is. If yes, keep going.

Two cautions. De-identification protects confidentiality, but it also degrades the work, because the specifics are often the point. And it is not a licence to be careless with what remains. Where the detail genuinely matters, the answer is not a cleverer redaction, it is using a system you have contracted for.

What should you ask a vendor before anything goes in?

Ask a short, fixed set of questions and require written answers. If a vendor cannot answer these clearly, that is itself the answer.

1. Where is our data processed, and where is it stored at rest? Is there a regional option, and does it cover backups and logs?
2. Which legal entity are we contracting with, and in which country is it incorporated?
3. Do you use our content to train or improve models, on the plan we are on? Is that setting on by default?
4. How long do you retain our content, including prompts, outputs, logs and abuse-monitoring copies? Can we set a shorter period?
5. When we delete something, what actually happens, and how long does it persist in backups?
6. Who are your subprocessors, where are they, and how are we notified when the list changes?
7. Can your support staff access our content, under what circumstances, and is that logged?
8. What happens if you receive a subpoena or a law-enforcement request for our data? Do you notify us first where permitted?
9. What are your security certifications, and when were they last audited?
10. What notice do you give before changing these terms?

Save the answers as a dated PDF against the vendor's name. When the terms change in eighteen months, you want to know what you were told when you decided.

Why do data residency and subprocessors matter so much?

Because your confidentiality obligation does not stop at your supplier's front door, and most suppliers use other suppliers. Australian privacy law places obligations on organisations that disclose personal information overseas, and many client contracts and government panels impose their own location requirements independently of that.

Almost every modern software product runs on infrastructure it does not own, and uses other services for storage, logging, analytics and support tooling. The subprocessor list is where the real map of your data lives. Two things to check: whether the vendor commits to flowing the same obligations down to those parties, and whether you get notice and a right to object when the list changes.

Ask for the list in writing. A vendor that treats the question as unusual is telling you something about how many professional clients it has.

How long should data be kept?

For the shortest period that still lets the workflow do its job, and no longer, because retained data is the thing that turns a minor vendor incident into your notification problem.

Three separate clocks are usually running and firms tend to only see the first:

• Content retention. How long your prompts and outputs sit in the product, often adjustable.
• Log retention. How long operational and abuse-monitoring copies are kept, often fixed and often longer than you expect.
• Backup persistence. How long deleted material survives in backups, which is rarely zero.

Set your own side of it too. If a workflow copies matter data into a spreadsheet, a queue or an intermediate store, that store needs a retention rule as well. Automations tend to accumulate quiet caches nobody remembers creating.

What belongs in an engagement letter?

Enough that a client is not surprised, expressed generally rather than as a list of product names you will have to update. Many firms are moving toward a short clause covering four things.

• That the firm uses software and third-party service providers, which may include AI-assisted tools, in delivering services
• That confidentiality obligations extend to those providers under contract
• That a person reviews any work product before it is provided to the client
• How a client can raise a preference or an objection

Two practical notes. Some clients, particularly larger corporates and government, will have their own requirements that override your standard terms, so read inbound contracts for AI and offshoring clauses before you sign. And have the wording reviewed by someone qualified in your jurisdiction rather than copying a clause from another firm's website.

How do you keep this workable for the team?

Reduce it to one page and one default, because a policy nobody can recall at 5pm is not a control.

The version that tends to stick in a small firm is three lines. Client-identifying material only goes into the approved system. Everything else gets de-identified first. If you are not sure, ask before you paste, and nobody gets in trouble for asking.

Pair that with the practical enablers: a firm-administered account so people are not tempted to use personal logins, an approved-tools list short enough to remember, and a named person who owns the question. Rules that make the compliant path the easy path survive. Rules that add friction get quietly routed around, and you find out later.

What to do next

Work through it in this order, because each step makes the next one cheaper.

1. Write the "never leaves the firm" list on one page.
2. Choose one approved system for anything involving client information, and set it up in the firm's name.
3. Send the vendor question list to every provider already in use, and file the answers.
4. Set retention on the tools and on any intermediate stores your workflows create.
5. Review your engagement terms with someone qualified, and check inbound client contracts for their requirements.
6. Diarise a review in twelve months, or sooner if a provider changes terms.

None of this requires a project. It requires a decision about what leaves the firm, and the discipline to make that decision once rather than every time someone is in a hurry.

This article is general information only and is not legal advice. Confirm your obligations with your professional body and your own advisers before relying on any of it.