What data governance terms should you check before using an AI tool on client work?

Why the governance terms matter before client data touches an AI tool

If an AI tool may handle client work, the first question is not whether the feature is impressive. It is whether the firm can prove what happens to the data, who can access it, how long it is retained and what evidence would be available if a client, partner, insurer or regulator asks later.

For professional-services teams, the contract and control pack should be reviewed before any live use. That means procurement, information security, practice leadership and the responsible client team need a shared view of the permitted use case, the data classes involved and the human review step before outputs reach a client file.

The safest answer is a terms checklist backed by operational controls

Before using a specific AI tool on client work, verify the data processing role, training rights, retention period, data location, sub-processors, access controls, audit logs, deletion rights, incident duties and exit process. Then match those terms to an internal policy that says what the tool may and may not touch.

Do not rely on a general privacy page alone. Ask for the product-tier terms that apply to the exact workspace, plan, region and feature your team will use. Consumer settings, API terms and enterprise controls can differ materially, even when the product name is the same.

Check where AI risk sits in your current workflows

The core data terms to verify

Start with the processing role. The supplier should state whether it acts as processor, controller or independent controller for each part of the service. If the answer changes between prompts, uploaded files, telemetry, support access and model-improvement data, record the difference rather than treating the tool as one simple bucket.

Next, confirm whether prompts, files, outputs, metadata or feedback are used for model training, fine-tuning, evaluation or service improvement. A strong position is not only that confidential client material is excluded, but that the exclusion is written into the contract, visible in admin settings and testable by an account owner.

Check retention and deletion by data type. Meeting transcripts, uploaded documents, chat history, logs and generated outputs may each have different retention periods. The firm should know what is deleted, when it is deleted, whether backups are included and what happens when a user leaves or a matter closes.

Security, access and audit evidence

For client work, access control is as important as model quality. Confirm single sign-on, multi-factor authentication, role-based permissions, workspace separation and admin controls for sharing, exports and public links. If the firm uses matter-level information barriers, check whether the tool can support them or whether the use case must be narrowed.

Auditability should be explicit. The team should be able to see who used the tool, when, with which data class, for which matter or workflow, and who reviewed the output before it influenced advice, reporting or client communication. If a tool cannot provide enough logs, compensate with a manual usage register or keep it away from higher-risk work.

Security certifications can help, but they are not enough on their own. Check whether SOC 2, ISO 27001 or similar evidence covers the actual product, region and hosting model you intend to use. Also review sub-processors, support access and breach notification timelines.

How to turn the review into a usable policy

The practical output should be a short permitted-use decision, not a long document nobody follows. Classify the tool by approved use cases, blocked data types, required review steps, record-keeping requirements and named owner. Make it clear when staff can use the tool, when they need approval and when a client-specific instruction overrides the default policy.

For regulated or sensitive work, connect the tool review to existing obligations: confidentiality, privilege where relevant, UK GDPR, professional conduct, Consumer Duty, SM&CR accountability or insurer notification requirements. The aim is to make AI use governable inside the operating model the firm already has.

Keep AI governance current as tools and terms change

Implementation discipline after approval

Once the terms are acceptable, roll the tool out in stages. Start with low-risk workflows, approved templates and a review checklist. Capture exceptions, failed outputs, user questions and any client objections. This evidence tells you whether the policy works in practice and whether the tool should be expanded, restricted or retired.

Recheck terms when the supplier changes model providers, launches new default-on features, changes retention settings or introduces new integrations. AI governance is not a one-off procurement gate. It is an operating control that needs version history, ownership and a clear route for staff to raise uncertainty.

Build a controlled AI implementation plan

Conclusion

The right test is whether the firm can explain and evidence what happened to client data throughout the tool lifecycle. If the contract, settings, logs and internal policy do not line up, keep the use case out of client work until the control gap is closed.