Why AI tool approval needs a risk-tiered decision
Keep a register of approved AI tools and the tasks and data each may handle. Mark uses that need supervision or are out of bounds, and give each decision an owner and review trigger.
A register can distinguish internal support from uses involving client data, legal privilege, regulated advice, financial promotion, audit evidence or final deliverables. Assess scope, policies, contracts and applicable professional duties for the proposed use. Use any external checklist as a decision aid only after checking its scope and relevance to the firm; a register entry does not establish compliance or suitability.
An example: four approval tiers for defined uses
One internal scheme uses four tiers: approved, supervised, restricted and prohibited. Apply the tier to a defined tool, task, data scope and configuration, not to every possible use of a product. Approved uses have assessed vendor terms, data settings, retention, access and review requirements. Supervised uses need specified checks, such as input minimisation, human review, manager sign-off or a separate quality check before client delivery; redaction alone does not establish suitability.
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, which records are proportionate to the use: user or owner, task, input category, controlled output reference, checks and decision? Set access, retention and confidentiality rules rather than collecting complete prompts and outputs by default. Sixth, who owns the risk: practice lead, compliance, data protection, IT, matter partner, ML owner or operations lead?
Record the evidence considered and any unmet condition. A register entry documents the approval decision; it does not prove that every later use followed its conditions.
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.
Treat a restricted approval as specific to the task, data and account. Document permitted test material, blocked client uses, review steps and unresolved supplier terms. Check synthetic examples for disclosure before using them; a restricted label alone does not approve the use.
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, identify the consequences of error or disclosure before approving the task. Check the applicable confidentiality, professional, privacy and customer-outcome requirements with the responsible reviewer. If terms, data routes, supervision or ownership are unresolved, pause that use while the gaps are assessed.
Give staff a route to identify permitted tasks, required review and unresolved conditions. Escalate new data or expanded uses rather than relying on an approved product name. Keep the decision evidence available to the responsible reviewer without treating the register as a guarantee of safety.
Conclusion
Test the register against one proposed client task. Check that its data, configuration, vendor terms and reviewer match the recorded approval, then assign any missing evidence. Revisit the decision when those conditions change.
Build the approval workflow around real client use cases
Need a safer AI route for your firm?
If this article reflects a live decision in your practice, the useful next step is to map the workflows, confidentiality risks, supplier controls and governance gaps before tools spread informally.
