Which AI tools should be approved for client work?

Approving AI tools for client work starts with the work type

The approved list should not be a popularity ranking of AI products. It should be a controlled map of which tools may be used for which client tasks, with what data, under what review process, and with what evidence retained afterwards.

For a professional services firm, the same AI assistant can be low risk for summarising a public article and high risk for drafting advice from confidential matter data. Approval needs to sit at the level of use case, data sensitivity and operating control, not only at the level of product name.

The safest answer is a tiered approved-tool list

Use three tiers. First, approved tools for general, non-confidential work such as research planning, internal templates and public-domain summaries. Second, restricted tools for client work where the contract, settings and workflow controls have been checked. Third, prohibited use cases where client confidential information, privileged material, regulated advice or final judgement cannot be entered or generated without a separate approval.

That tiered list should name the tool, the permitted tasks, the banned tasks, the allowed data types, the required review step, the evidence that must be retained, and the owner who keeps the rule current. If those fields are missing, the firm has a list of apps rather than an AI control.

Map your AI tool risks before approving client use

What belongs on the approved list

An AI tool can usually be considered for approval when it has a clear business purpose, documented data handling terms, access controls, retention settings, audit logs, and a defined human review step. For client work, the firm should also check whether prompts and outputs are retained, whether data may be used for training, where processing takes place, and whether the vendor terms fit the firm's confidentiality and data protection duties.

The approval record should be specific. A tool might be approved for internal knowledge management, but not for client deliverables. Another tool might be approved for first-draft analysis only when all client identifiers are removed. A Copilot-style assistant may be appropriate inside an existing tenant if permissions, labels and retention are configured correctly, while a public chat tool may be restricted to non-confidential inputs.

What should be off limits until reviewed

Tools should stay off the approved list when the firm cannot explain where client data goes, whether prompts are retained, who can access outputs, how errors are caught, or which person remains accountable for the final work. The same applies to browser extensions, meeting bots, transcription tools and embedded AI features that staff can activate without procurement review.

For legal, accountancy, consulting, insurance and financial services teams, the risky cases are often ordinary workflow moments: uploading a client pack for summary, asking for wording for regulated advice, analysing claims data, preparing diligence notes, or using a meeting transcript that contains sensitive commercial information. Those moments need clear boundaries before staff improvise.

The operating model matters more than the product name

An approval list should be owned by a named person or committee, reviewed on a fixed cadence, and connected to onboarding, training and incident reporting. Staff need a simple way to check whether a tool is allowed, request a new tool, report shadow AI use, and understand the evidence they must keep when AI supports client work.

Good governance does not mean blocking useful automation. It means making safe use easy and unsafe use obvious. The practical control is a short policy, a live tool register, workflow-specific guidance, and enough audit trail to prove who reviewed the output before it reached a client or influenced a decision.

Keep your AI governance register current

A simple approval checklist

• Purpose: What client or internal task is this tool approved for?
• Data: What data may be entered, and what data is banned?
• Vendor terms: Are retention, training, location and access terms acceptable?
• Security: Is access controlled through SSO, roles or approved accounts?
• Review: Who checks outputs before reliance or client communication?
• Evidence: What prompt, source, output or decision record is retained?
• Exception route: How can teams request a new tool or use case?

Conclusion

The approved AI tool list should tell teams exactly what they can use, what they must never enter, and what review evidence is required before client work moves forward. If the answer is unclear, the tool should remain restricted until the firm has checked the use case, the data flow and the human accountability model.

Turn the approved-tool list into working controls