How should a firm decide which AI tools are approved, supervised, restricted, or prohibited for client work?

Why AI tool approval needs a risk-tiered decision

Professional services firms should decide tool approval before client work begins, not after someone has pasted a document into a public AI tool. The practical question is not whether AI is allowed in the abstract. It is which tool, for which task, using which data, under which supervision, with which record of the decision.

The LexisNexis professional-services checklist frames AI governance around scope, policies for generative AI, AI contracts, UK regulation, client trust, regulatory obligations and professional standards. That is the right starting point. A firm needs a visible register that separates low-risk internal support from work that touches client data, legal privilege, regulated advice, financial promotion, audit evidence or final deliverables.

The safest approach is to classify tools into four approval tiers

Use four tiers: approved, supervised, restricted and prohibited. An approved tool is allowed for defined tasks because the firm has checked the vendor, data settings, retention terms, access controls, audit logs and review process. A supervised tool may be used only with named controls, such as redacted inputs, human review, manager sign-off or a separate quality check before anything reaches a client.

A restricted tool is allowed only for narrow internal use, or only by trained users, because the vendor terms or task risk are not strong enough for broader deployment. A prohibited tool is blocked for client work because it creates unacceptable confidentiality, privilege, data protection, accuracy, regulatory or security risk.

Map your AI tool risks before approval

What evidence should sit behind each approval decision?

Each tool record should answer six questions. First, what does the tool do and what type of AI is in scope? Second, what data will users put into it, including client files, personal data, trade secrets, regulated advice or privileged material? Third, what does the vendor contract say about storage, training, deletion, subprocessors, security controls, audit rights and incident reporting?

Fourth, what human review is required before outputs are used? Fifth, what logs will prove who used the tool, for what task, with which input class, which output, which checks and which final decision? Sixth, who owns the risk: practice lead, compliance, data protection, IT, matter partner, ML owner or operations lead?

Without that evidence, the approval is only a preference. With it, the firm can show a client, regulator or insurer that tool use was controlled, reviewed and documented.

How to set the approved, supervised, restricted and prohibited rules

Approved tools should be limited to use cases where the vendor terms, security posture and operating controls match the task. Examples might include summarising public information, drafting an internal first version from non-confidential material, or using a Copilot-style assistant inside an environment where tenant controls, access permissions and retention settings have been reviewed.

Supervised tools fit work where AI can assist but cannot be trusted as the final decision-maker. For legal, accountancy, insurance and financial services teams, that means named human review, recordable checks and a clear line between assistant output and professional judgement. The reviewer should check facts, citations, assumptions, missing context, tone, regulatory claims and whether client disclosure is needed.

Restricted tools are useful but risky. A public AI tool might be acceptable for brainstorming a generic meeting agenda, but blocked for client documents, advice, negotiations, claim files, underwriting notes, payroll data or personal data. A vendor with weak deletion terms might be allowed for synthetic test data only. A tool with limited logs might be allowed for low-risk internal drafts but not for regulated decisions.

Prohibited use should be blunt. Do not upload privileged material, confidential client data, special category personal data, passwords, security keys, unpublished financials or regulated decision records into an unapproved public tool. Do not use AI output as legal, financial, insurance or tax advice without qualified review. Do not allow hidden AI features in client workflows unless they have passed the same approval route.

Make the governance process usable enough that people follow it

Tool approval fails when the policy is too abstract. Give staff a short intake form, a risk-tier decision table, examples of permitted and prohibited data, and a named route for exceptions. Include ChatGPT, Claude, Gemini, Microsoft Copilot and embedded AI features only where the use case requires that level of specificity. For most policies, vendor-neutral categories are clearer: public AI tools, firm-approved assistants, embedded AI features and third-party AI vendors.

The governance owner should review the register on a set cadence and when a vendor changes model, terms, data location, logging, retention or subprocessors. The firm should also keep an incident path for accidental uploads, inaccurate outputs, client complaints, suspected data exposure and unapproved tool use.

Put a practical AI governance cadence in place

What this means for client work

For client work, the decision should be conservative where the downside is high. If the task touches confidentiality, privilege, regulated advice, Consumer Duty outcomes, SM&CR accountability, personal data, audit evidence or final deliverables, the tool should usually be approved or supervised, not informal. If the firm cannot show the vendor terms, data pathway, review record and accountable owner, it should pause the use case or move it into a controlled pilot.

The aim is not to slow useful automation. The aim is to make approved use faster than shadow use. A clear register gives teams permission to use safe tools, tells them where review is needed, and gives compliance a defensible record when clients ask how AI is governed.

Conclusion

A professional services firm should approve AI tools by evidence, not enthusiasm. Define the tool scope, classify the task risk, check the vendor terms, set the human review rule, log the decision and revisit it when the tool or use case changes. The end product is a living approval register that people can understand and compliance can defend.

Build the approval workflow around real client use cases

FAQ

Should every AI tool need formal approval?

Every tool used for client work, confidential data, regulated activity or final deliverables should be recorded and tiered. Low-risk internal tools can use a lighter approval route, but they still need usage boundaries.

Can staff use public AI tools for client work?

Usually not unless the firm has expressly approved the use case and controls. Public tools should be treated as external recipients unless the contract, settings and data pathway prove otherwise.

Who should own the AI tool register?

Ownership should sit with a named governance lead, supported by compliance, IT, data protection and the relevant practice or business owner. The accountable owner must be clear for each use case.

How often should approval decisions be reviewed?

Review them at least quarterly for active tools and immediately after material vendor changes, new data types, incidents, client concerns or expansion into higher-risk work.