Why client-service work needs its own rules
In a consulting, advisory or accounting practice, the product is a document that carries the firm’s name: a research memo, a diagnostic report, a recommendation. AI is good at the parts that eat consultant time: summarising source material, structuring a first draft, comparing options, turning interview notes into findings. Most firms have already approved at least one assistant.
Two risks are specific to this kind of work. The first is client mixing: material, insight or confidential detail from one engagement appearing in work for another, because it was in the same workspace or conversation. The second is unsupported advice: a confident statement in a client deliverable that nobody checked, which the partner signs because it reads well. Both are professional risks, not just quality issues.
What the work involves
Client-separated research. Each engagement gets its own workspace in the approved tool, with its own document set and history. Firm knowledge used across engagements is limited to approved, non-client material: methods, templates and public research. We record which engagements may use which tools, because some client contracts restrict AI use.
The evidence ledger. As a consultant researches and drafts, each substantive assertion is logged with its source: a client document, an interview note, a public source or a firm method. Generated text stays marked as unverified until someone checks it against a source. The ledger travels with the draft.
The partner review checklist. Before anything reaches a client, the reviewing partner works through a short checklist: separation confirmed, every assertion in the ledger, no unverified generated text, advice clearly the firm’s judgement, client restrictions respected.
This follows two things I have published: the Substrate Pattern, about fixing what an AI system can touch before it runs, and a tiered governance model in which the level of review rises with the consequence of the output.
The signature deliverable
You end with a client-separated research workflow, an evidence ledger and a partner review checklist. Illustrative example of an evidence ledger extract:
| Assertion in draft | Source | Type | Verified by | Status |
|---|---|---|---|---|
| Client’s order volume grew year on year | Client management accounts (data room ref.) | Client document | Consultant | Verified |
| Three of five interviewees cited onboarding delays | Interview notes, engagement workspace | Primary research | Manager | Verified |
| Sector peers typically outsource this function | — | Generated | — | Unverified: remove or source |
Illustrative example. Rows show the format, not client work.
How acceptance is judged
Before the pilot, we sample recent deliverables in the practice for time to first reviewed draft, the number of partner corrections and unsupported assertions found in review. During the pilot we measure the same things on live engagements. Separation incidents are counted separately; the target is none. The practice director accepts the pilot. The adoption measure is whether consultants use the workflow on new engagements without being reminded, and whether partners rely on the ledger.
Ownership and handover
The practice operations owner holds the workflow, the ledger template and the checklist. Partners keep review authority. The risk or quality function keeps approval over tools and separation rules. The handover note explains how to onboard a new engagement and a new consultant.
Boundaries
This page is about one practice team’s workflow. For firm-level decisions (which practices go first, how engagement letters treat AI, partner sponsorship) see AI adoption for professional-services firms. If you are an in-house finance team rather than a firm serving clients, see AI enablement for finance teams. For document-heavy extraction work, see document processing and reviewed reporting workflows.