QuestionLegal ServicesAI Governanceclient confidentiality

Which AI tools can touch client-confidential data?

5 May 2026
Answered by Rohit Parmar-Mistry

Short answer

Only use an AI tool with client-confidential data after approving that tool, task and account tier against the matter's restrictions, vendor terms, security and review process.

Detailed answer

Why this question matters for client-confidential data

Only use an AI tool with client-confidential data after approving that tool, task and account tier against the matter's restrictions, vendor terms, security and review process.

Start with the data the task needs. A tool that is suitable for public research may still be unsuitable for a client file, even when both tasks use the same account.

The safest answer is a tiered approval model

Approve client-confidential use for a specific service and account tier, with the matter's restrictions recorded. Check the applicable data processing terms, how the provider may reuse inputs, retention, access and logging. An enterprise label or a no-training setting alone does not establish that the arrangement is suitable.

Consumer-grade tools, browser extensions and unmanaged plug-ins should be treated as unsuitable for client matter data unless they have passed the same vendor, legal and security review as any other system that handles confidential information.

Map which AI tools can safely handle sensitive data

Use four data tiers before approving any tool

A useful approval model starts with data categories, not tool names:

  • Public data: website copy, public reports, published policies and already public case material.
  • Internal business data: non-public operating information, internal templates, meeting notes and draft strategy.
  • Client-confidential data: matter details, client files, advice, negotiations, evidence, due diligence material and privileged context.
  • Restricted data: special category personal data, highly sensitive litigation material, credentials, financial crime information or data subject to strict contractual limits.

Use the tiers to set different review requirements. Public inputs still need an approved task and output check; client-confidential and restricted inputs need a decision that takes the actual service terms and matter restrictions into account.

The proof you need before approving client data use

Approval should be evidence-based. For each proposed client-confidential use, select proportionate approval evidence. Keep controlled source references or limited extracts where appropriate, apply confidentiality, minimisation, access and retention controls, and do not retain complete prompts or client files by default. Assess these categories:

  • Contractual proof: data processing agreement, confidentiality terms, subprocessors, jurisdiction, audit rights and termination/deletion terms.
  • Training and reuse proof: confirmation that prompts, files and outputs are not used to train public or shared models unless expressly agreed.
  • Retention proof: how long inputs, outputs, logs and uploaded files are kept, plus whether retention can be configured.
  • Security proof: authentication, single sign-on, role-based access, encryption, audit logs and incident notification commitments.
  • Operational proof: acceptable-use rules, user training, human review, matter-level restrictions and escalation routes.
  • Client proof: any engagement-letter, outside counsel guideline or client-specific restriction that affects AI use.

If the proof is missing, the tool may still be useful for public or synthetic data, but it should not be approved for client-confidential material.

How to decide which tools belong in each tier

A simple matrix is enough for most firms:

  • Green: approved for specific data classes and use cases, with named controls and owner.
  • Amber: approved only for public, anonymised or synthetic data, or only for a named pilot.
  • Red: not approved for business use, client data, file uploads or browser access.
  • Exception: requires matter partner, risk or governance sign-off before use.

The matrix should let a user check the data and task before pasting or uploading anything. Record any conditions beside the approval so that a green label cannot be mistaken for permission to use every feature.

Put an AI approval model under ongoing governance

Common failure points to avoid

  • Approving the brand instead of the product: enterprise and consumer versions of the same AI product can have different data terms.
  • Ignoring plug-ins and connectors: a low-risk chat tool can become high-risk when connected to email, documents, CRM or matter systems.
  • Relying on user judgement alone: people need default settings, examples and blocked categories, not a vague instruction to be careful.
  • Skipping output review: confidentiality controls reduce data risk, but they do not remove hallucination, accuracy or professional judgement risk.

A practical implementation checklist

  1. Create a live register of AI tools, owners, approved use cases and approved data classes.
  2. Define public, internal, client-confidential and restricted data tiers.
  3. Run vendor review for any tool that may touch client-confidential or restricted data.
  4. Record the decision and proportionate supporting references, with confidentiality, minimisation, access and retention controls. Do not copy complete prompts or client files into the register by default.
  5. Before rollout, configure access, sharing and retention. Define which material events need logging and why; use controlled references where appropriate and avoid full prompt or client-file capture by default.
  6. Train users with examples of what they can and cannot paste, upload or connect.
  7. Set a review interval based on the use case and risk, and reassess when terms, models, retention or integrations change materially.

Keep the approval record short enough for staff to use, but include the conditions that matter for the client file. Where a safeguard is missing, record what must change before that use can be approved.

Build the approval workflow and tool register

Conclusion

Client-confidential data should only touch AI tools that have been approved for that exact risk tier. The approval should be backed by contractual, technical and operational proof, then translated into clear user rules.

If the team cannot justify client-data use, restrict the tool to separately approved inputs. Removing names is not enough if the remaining facts still identify the client or reveal confidential matter information.

Need a safer AI route for your firm?

If your practice is deciding whether a tool can handle a client file, start by mapping the data it would receive, the supplier's terms and the matter restrictions. That gives the approval owner a specific decision to work through.

Frequently asked questions

Can staff use free AI tools for client questions?

Not with client-confidential data. Free or unmanaged tools should normally be limited to public, anonymised or synthetic examples unless they have passed formal review.

Is anonymisation enough to use a non-approved tool?

Sometimes, but only if the information is genuinely stripped of client identity, matter context and indirect identifiers. Pseudonymised matter facts can still be confidential.

What is the minimum proof before approving an AI tool?

You need evidence on data use, model training, retention, subprocessors, security, access control, logging and deletion. For legal work, add confidentiality and client-specific restrictions.

Who should own the approval decision?

Ownership should sit with a named business owner, supported by risk, legal, security and data protection input. No tool should be approved by enthusiasm alone.

How often should approvals be reviewed?

Set the interval to match the use case, matter restrictions and risk. Reassess after a material change to terms, integrations, model behaviour, retention or the data being used; do not wait for the scheduled review.

Discuss your next step

Talk through your situation with Rohit, or take the assessment if you need a first read.