AI in Professional Services Without Eroding Judgement

Use AI to help gather evidence and prepare drafts, with an accountable professional deciding what the evidence supports. Give peer reviewers the sources and assumptions behind the work, make client approval specific to the decision, and keep confidential material within its approved boundaries. Measure the time to an accepted deliverable, including checking and rework.

Define AI's role in the engagement

Begin with the client's question and the deliverable you have agreed to provide. A research brief, an implementation plan, and a professional opinion require different checks. State who owns the conclusion, what evidence they need, and which decisions stay with the client. AI assistance doesn't make that scope self-explanatory.

Identify where the team can use AI. You may permit summarising approved records, extracting candidate facts, or drafting a section from a checked evidence pack. Specify the tool, account, data boundary, and reviewer. A policy that only says to use AI responsibly leaves staff to guess what the firm has approved.

On 4 June 2026, ICMCI announced its responsible-AI code for management consulting. Its announcement emphasises consultant accountability, confidentiality, transparency, and professional review of AI outputs before client use. Treat that as professional guidance to apply within your engagement, rather than proof that a particular tool or workflow meets every obligation.

Review engagement terms and the firm's applicable professional requirements with the appropriate owner. Decide how to explain material AI use and obtain any permissions the work requires before sharing client information with a service. The client's agreement to receive a report does not automatically answer where you can process their underlying records.

Check the actual service configuration. Account type, access, retention, and connected tools can affect the data path. Record what the firm has verified and what remains unresolved. Don't substitute a product's general security claim for an assessment of the account and integration your team uses.

A May 2026 Reddit discussion about an unreviewed AI-generated client guide describes a handoff that left colleagues with the verification work. It reflects a reported experience, rather than a sector-wide measurement. Design the engagement so the author owns a reviewable draft and the reviewer has explicit time and authority to check it.

Build an inspectable research record

Keep a record of the sources behind material claims. For each claim, store a source reference, the relevant passage or data, its date, and the scope it supports. Note whether the source is a public publication, a client record, or an interview. Give authorised reviewers a way to inspect the underlying material.

Distinguish source facts from the team's interpretation. A ticket log may establish that a case waited two days in a queue. It may not establish why. An interview can offer an explanation, while a broader claim about the cause needs corroboration. Label the inference and the evidence required to strengthen it.

Use AI to propose research leads and organise approved evidence, then verify material references directly. Check that a cited document exists, that its content supports the claim, and that its period and population match the use. A real citation attached to an unrelated claim still fails the evidence check.

Record conflicting sources instead of allowing a summary to smooth them away. A policy document may describe an approval step that staff no longer follow. A current operating record may use a different definition from last year's report. Establish which version applies to the question and identify any unresolved difference.

Track gaps as work items. If the client has not supplied records for one business unit, state the missing coverage and the effect on the conclusion. Don't present a firm-wide finding from the units you happened to inspect. Assign the request and agree whether the deliverable can proceed with a stated limit.

Keep collection proportionate. A research pack needs enough evidence for review, not an unrestricted copy of every client folder. Control access and retention for extracts, interview notes, and model outputs. Reducing unnecessary copies makes it easier to maintain the boundary throughout drafting and review.

Draft from evidence without inventing certainty

Give the drafting task a bounded input pack and a defined section to produce. Ask for the evidence references and explicit missing facts alongside the draft. Require the system to preserve uncertainty. A fluent paragraph should not turn a tentative interview comment into an established company-wide fact.

The professional author decides the argument. They choose which evidence matters, compare alternatives, and explain the recommendation's conditions. AI can help arrange that material, but the author needs to understand and defend the reasoning. If they cannot explain a conclusion without consulting the generated text, the draft needs more work.

Make assumptions visible and testable. Separate measured figures from planning assumptions, state the units and period, and show the calculation. Recompute important totals independently. A chart or table that looks plausible can hide a wrong denominator or combine figures from incompatible periods.

Control what the draft can claim. An implementation memo may recommend a limited trial after specified dependencies are met. It should not say that the system is ready for unrestricted use when the team has not tested the relevant cases. Specify the accepted scope and the evidence the next decision requires.

Use a consistent review packet. Include the draft, source record, assumptions, unresolved items, and any significant changes since the reviewer last saw it. The author should resolve basic citation and calculation errors before the handoff. Peer review needs to examine the conclusion, not reconstruct an undocumented research process.

Limit draft volume to the work the team can review. Generating extra pages creates an obligation to check them. Prefer a concise report that answers the agreed question, with controlled supporting records. Include additional detail when it helps the client decide or lets the reviewer verify the result.

Make peer review a decision with evidence

Assign a reviewer with competence in the relevant work and enough time to examine it. Their review should address factual support, reasoning, and fit to the client's circumstances. A proofreading pass and an AI-generated critique provide different evidence from professional peer review.

ICAEW's August 2026 guidance on AI and complaints says firms keep responsibility for the work they issue and should scrutinise outputs, sources, and conclusions. Its context is accountancy practice. The operating lesson for a wider professional-services firm is to give someone explicit responsibility for reviewing the actual client deliverable.

Specify what the reviewer must check. Material facts need supporting sources; calculations need correct inputs and arithmetic; recommendations need a defensible connection to the evidence. Check omissions too. A report can contain only true statements while leaving out a constraint that changes the decision.

Let the reviewer reject the draft or restrict its scope. Record the issue, expected correction, and the evidence needed to close it. A generic approval mark leaves the next person guessing what the review covered. Keep unresolved issues visible until the accountable owner decides how to handle them.

Use automated checks for specific parts of the packet. They can flag missing references, inconsistent units, or a broken calculation. A second model can suggest questions, but agreement between models doesn't establish the truth of the underlying claim. Check the evidence and use domain judgement for the consequential conclusion.

Connect the review to the version released. Significant changes after approval need another check of the affected parts and any dependent conclusions. Keep a record of the final version, reviewer, and approval conditions. Our article on placing AI quality review with decision owners covers the responsibility boundary.

Keep client approval specific

Separate factual confirmation, acceptance of a deliverable, and authorisation to act. A client can confirm that a process description is accurate without approving a proposed system change. They can accept the report while asking for more evidence before investment or rollout. Record which decision the approval covers.

Show the client the conclusion and its limits in language they can use. State what the team observed, what it inferred, and which dependencies remain. If the work covers a subset of sites or cases, put that boundary where the client reads the recommendation. A caveat buried in an appendix may not support an informed decision.

Give the client a defined review task. Ask them to confirm a source record, resolve a rule, or approve a limited pilot, with the relevant context attached. Don't make them responsible for discovering basic errors in the firm's work. The firm's professional review should occur before the client receives the version for that decision.

Agree who can approve on the client side. A project contact may coordinate records without authority to change policy or commit resources. Use the engagement's decision process and identify the required owner. Keep a route for disagreement and for questions the current reviewer cannot settle.

Capture approval conditions with the deliverable. An approval for one workflow and user group should not become a claim that every department can use the system. If the scope changes, check the evidence, permissions, and review requirements again. The new decision may need a different owner.

Handle later corrections through the firm's normal issue and communication process. Assess the impact, notify the relevant people through the agreed route, and maintain a clear current version. Internal evidence about what changed helps the team learn; the client-facing work should state the current conclusion and any action they need to take.

Reuse methods within confidentiality boundaries

Separate reusable methods from client evidence. A checklist for inspecting an integration or a generic evaluation rubric may support later engagements. A client-specific recommendation, record, or interview note can reveal confidential facts. Decide what the firm has the right to reuse before adding it to a shared knowledge base.

Removing names is insufficient when the remaining details identify the client or disclose their operation. A distinctive system combination, transaction, or performance figure may reveal more than a company name. Review the content and its permitted purpose rather than treating anonymisation as automatic permission to share it.

Preserve the boundary in retrieval. Staff working on one engagement should only retrieve materials they are authorised to use there. Enforce access in the application and storage systems, including any search index. A prompt asking the model to keep accounts separate cannot replace those controls.

Review reusable material before publication inside the firm. Give it an owner, a scope, a source or rationale, and a review date. Mark the difference between a generic method and evidence from a particular engagement. A template copied from a prior report can carry outdated assumptions into the next client's work.

Keep approved learning concrete. A team can record that its generic review checklist now asks for evidence of duplicate-write handling. It doesn't need to copy the client's incident narrative to preserve that lesson. Where examples need permission, use the agreed route or create a clearly labelled synthetic example.

Test the knowledge system with realistic access scenarios and maintain a correction process. Check that an unauthorised user cannot retrieve a client extract and that a withdrawn item no longer appears through the relevant search path. Our guide to scoped AI access to existing systems explains the technical boundary.

Apply the workflow to an implementation-readiness memo

Consider an illustrative advisory firm assessing a draft-order assistant for a portfolio company. This example uses invented conditions and claims no client result. The engagement asks whether the company has enough evidence for a limited pilot, with staff approval before orders enter fulfilment.

The researcher gathers approved process records and observes selected cases. They find that product matches sometimes require an operator's contract lookup. The evidence record distinguishes the observed cases from the firm's estimate of how often that exception occurs. The team has not yet measured its frequency across the whole business.

The author drafts a recommendation for a bounded pilot with explicit exclusions. They identify the required contract source and the human approval step, then state which cases need escalation. The peer reviewer checks whether the proposed pilot actually covers the dependencies the research found.

Suppose the draft calls the contract lookup a solved dependency, but the client has not granted the required access. The peer reviewer rejects that claim and the owner revises the conclusion. The memo can describe the access requirement and recommend the next assessment; it cannot use polished wording to establish readiness that the team hasn't verified.

The client confirms the process description and later approves the specified pilot once the relevant owners resolve its dependencies. The firm records those as separate decisions. It retains a generic question about source-access readiness for future work, while keeping the client's records and findings within their approved engagement boundary.

A VC investor can ask a professional-services supplier to show that chain for a startup's implementation plan. A PE operating team can use it when comparing readiness across portfolio companies. An SME or corporate buyer can use the same handoff evidence to understand what the adviser has actually checked before acting on the report.

Measure quality and maintain professional capability

Measure the complete path to accepted work. Record research, drafting, author checks, peer review, and rework, plus any client correction needed after delivery. Report quality alongside time. A faster first draft can still consume more senior attention or create additional work for the client.

Compare work with similar scope and consequence. A short internal summary and a client-facing recommendation need different levels of evidence and review. Record the AI-assisted steps and the limits of the comparison. Don't attribute every change in effort to the tool when the team, sources, or assignment changed too.

Maintain a small set of reviewed cases for testing workflow changes. Include missing evidence, conflicting sources, and inputs the system must not disclose to an unauthorised person. Check the result after a change to the tool, instructions, retrieval, or review process. Our guide to measuring AI quality in business terms explains how to connect the test with completed work.

Keep junior staff involved in the reasoning. Ask them to inspect sources, rebuild a calculation, and explain why the recommendation fits the client. Give feedback on those decisions and supervised practice with difficult cases. Generating a report quickly doesn't replace the work through which they learn to recognise an unsupported conclusion.

Review the operating burden too. Someone needs to maintain approved tools, access, templates, and evaluation cases. Include that effort when assessing efficiency. A PE-backed professional-services firm should inspect whether apparent margin gains rely on partners absorbing unrecorded review work.

Before expanding the workflow, inspect one complete deliverable with its source record, review decisions, and client approval. Ask the accountable professional to explain the conclusion and an alternative they rejected. Confirm that the reusable lesson excludes material the next engagement cannot access. That demonstration gives the firm a concrete basis for deciding what to expand and what still needs correction.