Approving AI tools for client work starts with the work type
Approve a tool for a named client task and data class, not for all work. Record the product tier, terms, allowed inputs, reviewer and evidence needed before client use.
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.
For each tier, name the tool, permitted and banned tasks, allowed inputs, reviewer, retained evidence and owner. Staff should be able to check a proposed client task against those fields without guessing what an approved product label means.
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.
A tool might be approved for internal knowledge management but not for client deliverables. Removing client names does not by itself justify first-draft analysis: the remaining facts may still be identifying or confidential. A tenant-based assistant also needs checks against the agreed task, permissions, retention and supplier terms before client use.
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.
Keep data safeguards and output review distinct. Acceptable supplier terms and configured access address where information can go; they do not show that an answer is accurate or suitable for the client. Record who checked the sources and final work before it reached the 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
Make the approved list usable at the point of work: name the task, permitted inputs and reviewer. If staff cannot tell whether a client task is covered, keep that use restricted until the owner has checked the data flow and review requirements.
Turn the approved-tool list into working controls
