Why the checklist matters before AI pilots become normal work
Before widening an AI pilot, list its approved tasks, permitted data, reviewer and the evidence needed to check results. Make the approval route match the effect a mistake could have on clients or staff.
Build the checklist around the firm's tasks, client information and approval process. Ask the responsible professional to identify applicable confidentiality, review and record requirements. Keep the checklist usable and link each control to an owner and evidence; its length or branding does not establish regulatory sufficiency.
The safest checklist covers scope, data, approvals, evidence, and ownership
Before teams scale beyond pilots, the checklist should answer five questions clearly: what counts as AI, which use cases are approved, what data can enter the tool, who reviews the output, and what audit trail proves the controls were followed. Record any unanswered point and assign it to an owner before approving the expanded use.
A practical checklist should include:
- Scope: a clear definition of AI for the firm, covering generative AI, machine learning, embedded vendor AI, transcription, research, drafting, analytics, and workflow automation.
- Use-case register: a list of approved, restricted, and prohibited uses, with owner, business purpose, risk tier, and review date.
- Client and personal data rules: what information can be entered, what must be redacted, and which tools are approved for confidential or regulated data.
- Human review: who checks AI-assisted work before it reaches a client, court, regulator, board pack, or management decision.
- Evidence: logs, prompts where appropriate, source checks, output review notes, vendor assurances, DPIAs, incident records, and policy exceptions.
Check whether your AI pilots are ready to scale
Define what AI means inside the firm
The first mistake is treating AI governance as a policy for ChatGPT alone. Most professional services firms already use AI in search, document review, CRM enrichment, transcription, data extraction, financial modelling, fraud checks, compliance monitoring, or marketing workflows. List the tools and uses it covers so teams can identify when approval is needed.
The definition should include standalone tools, AI embedded in existing software, vendor-managed models, internal automations, and staff use of public systems. It should also distinguish low-risk productivity support from work that affects client advice, regulated decisions, confidential information, privileged material, or professional judgement.
Classify use cases before approving tools
A tool is not safe or unsafe in the abstract. The same platform might be acceptable for summarising a public article and unacceptable for analysing an unredacted client file. The checklist should classify use cases by data sensitivity, reliance on the output, client impact, legal or regulatory exposure, and reversibility if the output is wrong.
The following bands are an illustrative internal triage model, not legal classifications or a universal approval rule. Assess the data, controls and consequences of each use:
- Low risk: internal drafting, public-source research, meeting preparation, or formatting where no confidential data is used and a human remains fully responsible.
- Medium risk: client-context work, matter summaries, diligence support, marketing claims, or operational recommendations that require documented review.
- High risk: consider heightened review for legal analysis, financial advice, underwriting, claims, regulatory submissions, employment decisions and healthcare decisions. Assess privileged or sensitive personal data against the proposed processing and controls; do not assign a band from the data label alone.
Agree an approval route for each band. For example, a firm might use policy acceptance and sample QA for lower-risk work, manager or matter-owner approval for a middle band, and partner, compliance, legal, data protection or board input for higher-risk uses. Confirm the actual decision authority and applicable duties rather than adopting these roles as a universal rule.
Set hard rules for client-confidential and personal data
State which tools and tasks the firm has approved for client material, with the evidence and owner behind each decision. Request the relevant retention, training-use, subprocessor, security, access, deletion, location, incident and contract information. Resolve gaps for the actual use rather than treating the checklist as a universal approval standard.
For legal work, the checklist should also cover privilege, confidentiality, client consent, and whether any disclosure to a client or court is needed. For accounting, insurance, financial services, or regulated advisory work, it should cover personal data, customer outcomes, record keeping, and model reliance. Make the permitted processing and exception route clear to the team.
Make review and sign-off visible
Human-in-the-loop is not a control unless the loop is defined. The checklist should say what reviewers must check: factual accuracy, source reliability, missing context, hallucinated citations, confidentiality, bias, unfair customer impact, unsupported claims, and whether the final output still reflects professional judgement.
For client-facing work, the review note can be simple: who reviewed it, what they checked, what changed, and whether any AI limitations remain. For higher-risk work, the evidence should include a stronger review record, source pack, exception log, and sign-off by the accountable owner.
Build the operating model, not just the policy
A checklist only works if ownership is clear. Firms should name the accountable sponsor, operational owner, data protection contact, security reviewer, vendor-risk owner, and escalation route for incidents or exceptions. They should also agree how often the register is reviewed, who can approve a new tool, and what happens when a pilot becomes business as usual.
Connect the assigned responsibilities to onboarding, procurement, client matter opening, delivery QA, training, incident response and board or partner reporting.
Keep the AI governance register current
Keep an audit trail that proves the checklist was followed
The audit trail does not need to capture every keystroke. It should capture the decisions that matter. For each approved use case, keep the business purpose, risk tier, approved tools, data category, reviewer, sign-off, vendor evidence, policy exceptions, and review date. For high-risk outputs, keep enough evidence to reconstruct how the work was produced and checked.
Use those records to answer partner, client, regulator, buyer, auditor or insurer questions about the approved uses and the controls actually followed. Keep gaps visible rather than presenting the existence of a log as proof of compliance.
What to do next
Start with the use cases already happening, not a blank policy document. Interview team leads, review vendor tools, look at where staff use public AI systems, and identify the work that touches client data or professional judgement. Then create a one-page checklist for new pilots and a register for approved tools and use cases.
Before approving expansion, check a sample pilot record against the checklist and assign any missing data rule, review decision or evidence record to its owner.
Turn the checklist into an implementation plan
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.
