How Should Consultants Use AI? A Client-Data Checklist

A consultant should classify client material before using AI, keep prohibited data out, minimise and redact permitted inputs, check the tool's processing terms, and review every output before it reaches the client. Obtain the client's documented permission where the contract or confidentiality duty requires it. A training-off switch alone does not make an upload safe.

The fastest safe starting point is a green task with no live client facts: draft a generic interview guide, outline a blank risk register or improve wording in a fictional example. Move to real material only after the engagement terms, data route and review owner are clear. A useful policy should let a colleague make the same decision without asking the practice owner every time.

Follow me on Instagram@sagnikteaches

Mark each source green, amber or red

Give the material a tier before opening an AI tool. Green means public or genuinely synthetic information that can be shared without breaching a client commitment. Amber means client-related information that may be used only in an approved tool for an agreed purpose after minimisation and review. Red means material the engagement, law or professional duty prohibits from entering the proposed tool, or a category too sensitive for the current controls. The colour is an internal operating rule, not a legal classification.

Connect on LinkedInSagnik Bhattacharya

A project can contain all three tiers. A public competitor list might be green, a client's market-share estimate amber, and a confidential restructuring memo red. Do not colour an entire folder green because one file in it is public. When classification is uncertain, treat it as red until the engagement lead decides. The business-data classification tutorial explains the general method; a consultancy should add the client contract and project-specific restrictions.

Subscribe on YouTube@sagnikteaches

Record the tier in the project register with source, owner, purpose and expiry date. That prevents a green extract being re-used after a client adds sensitive context. If a client publishes a report later, the published text may become public, but your working notes and unpublished recommendations do not automatically follow it. Classification should be reviewed when the project changes, not treated as a permanent label bestowed by the first analyst.

Read the promise you made to the client

Check the proposal, master services agreement, statement of work, NDA, security schedule and any written client instructions. Look for definitions of confidential information, third-party processors, approved systems, subcontractors, cross-project reuse, retention and deletion. A contract may allow a software processor under specified protections while banning use of client material to improve external models. Another may require written approval for every new service. If the wording is ambiguous, ask the engagement owner and qualified adviser before sending data.

A workable permission request names the task and data. For example: “May we use [named approved service] to classify the attached, coded survey themes for the strategy workshop? We would exclude participant names, email addresses and raw comments, limit access to the project team, and review the output before using it. Please confirm whether this use is permitted under our engagement.” That is illustrative client communication, not a universal legal consent. Do not bury the request in a general promise that “AI will improve efficiency”.

Suppose a client approves AI for public market research but explicitly excludes its internal pricing. The analyst must not paste a pricing table into a market-research prompt because the project label says “approved”. The permission attaches to a purpose and scope. Put a short permission card in the project workspace: approved task, approved tool, allowable fields, excluded material, approver, date and review trigger. If the team changes tools or purpose, revisit it.

Redact the payload, then test the redaction

Minimisation means giving the tool only what it needs. If the task is to group customer complaints, replace names and order IDs, remove unrelated purchase history and consider whether exact timestamps are needed. If the task is to summarise an interview theme, provide a paraphrased extract rather than the entire transcript when the speaker's identity or circumstances are sensitive. Redaction must cover document comments, file properties, spreadsheet hidden sheets and copied text that contains invisible context.

Data-protection rules treat pseudonymised data as still personal when it could be attributed to a person by using additional information, so a separate key or rare details can permit re-identification. A code such as “Executive 7” is weak if the prompt says that person alone led the $40 million transaction. Keep the mapping table outside the AI tool and ask a second person to try to identify the source from the proposed prompt. If they can, remove or generalise more context or choose a manual route.

A before-and-after illustrates the difference. Unsafe input: “Summarise [first name]'s 14 March interview about the planned closure of the evening shift at the 18-person site; include the stated medical accommodation request.” A safer prompt for a genuinely permitted theme analysis might say: “Summarise three anonymised concerns about a proposed shift change; exclude individual circumstances and do not recommend employment actions.” If the rare shift context still identifies the source inside the client organisation, the extract remains restricted. The safer wording is not a magic anonymiser.

For another illustration, a consultant wants a table of 12 supplier bids. The raw file includes contact names, bank details, private discounts and contractual restrictions. A task-specific extract keeps supplier codes, comparable service category, total quoted price and defined scoring criteria. The consultant checks that all 12 rows survived the export and that totals agree with the originals. AI can arrange the comparison, but a human verifies numbers and contract conditions. See the client-data anonymisation tutorial for deeper redaction checks.

Check the tool, account and connected apps

Review the provider's current terms for model training, retention, deletion, support access, subprocessors, region and security controls. Check the actual account plan and workspace settings used by the consultant. For example, Anthropic's privacy centre says inputs and outputs from its commercial products, such as Claude for Work, are not used for model training by default, while consumer Free, Pro and Max accounts rely on a Model Improvement setting in privacy settings. That fact addresses training, not every client contract or data-transfer issue. Do not assume a similarly named personal account has the same protections.

Inspect sharing and connected apps too. A tool may have access to a whole drive, mailbox or workspace when a single file would do. Ask who can create share links, what other team members can see, and whether a connected app can fetch material outside the approved project folder. Use a test account with dummy files to check scope. If the tool can search every client folder, its convenience may be disproportionate to a one-off summarisation job.

Keep a dated vendor review record: product and plan, contract version, processing purpose, retention answer, training answer, access controls, authorised users and recheck date. If you cannot verify a critical point, mark the tool unapproved for amber material. The AI privacy-terms tutorial gives a general reading checklist, but the consultant must still compare those terms to the promise made on each engagement.

A four-week project with numbers

Consider an illustrative three-person consultancy running a four-week operations review. The client supplies 24 interview notes and a 1,200-row service log. The proposal allows analysis of coded operational data in approved systems but prohibits disclosure of staff identity and pay. The team wants AI to group recurring delays and draft a meeting summary. The engagement lead marks the raw interviews red because they contain named staff and confidential incidents. The service log is amber after the client approves a defined extract.

The analyst first removes 7 columns that are unnecessary, including names, email addresses, free-text medical notes and precise location. The extract has 1,200 rows and 5 fields: coded request type, week, elapsed hours, team category and resolution code. A second reviewer samples 30 rows, searches for direct identifiers and checks the total number of records against the original. They also inspect unusual values; a rare category with only one record is grouped with another category before AI processing because it could identify a person inside a small team.

AI groups the rows and suggests that 310 requests exceeded 48 hours. The analyst recalculates from the approved extract and finds 286. The difference came from the tool treating blank resolution times as overdue. The review note records the corrected number and the rule: exclude blank times from the denominator until their status is investigated. The team spends 40 minutes preparing and checking the extract, 20 minutes reviewing AI output and 15 minutes correcting the summary. Those illustrative times make the control cost visible; they do not prove a saving.

For the interviews, the team reads the notes manually and records five themes without names or verbatim sensitive details. It then gives AI only the approved theme labels to draft an agenda. The final client deck uses 286 verified delayed requests, a clear denominator and a human-written explanation of uncertainty. The project register links the client approval, extract version and reviewer initials. The work is still useful even though the most sensitive source never entered AI.

Five everyday decisions for the project team

A public-source research request. A consultant asks AI to compare two suppliers using their public documentation. That can be green, but the comparison may fabricate features or dates. Open the source pages and verify each claim before including it in a client recommendation. Confidentiality and accuracy are separate gates; passing one does not pass the other.

A pasted meeting transcript. A call recording may include client strategies, other participants and personal details. Even if the consultant organised the call, permission to record is not automatically permission to send the transcript to another service. Check the engagement and meeting notice, identify the processing route and choose a manual summary if necessary. A two-line agenda can be drafted from generic topics without uploading the transcript.

A past client slide used as a template. Deleting the logo may leave confidential metrics, unique process diagrams or speaker notes. Inspect every slide and its notes before reuse. If the material embodies the former client's method, treat it as restricted even when no name appears. A blank structure written from scratch is often quicker than proving an old deliverable is safe to repurpose.

An output that quotes hidden input. AI produces a summary that includes a staff name the consultant believed had been removed. Stop the workflow, identify where the name entered, restrict sharing of the output and follow the client's incident procedure if required. Do not silently delete the name and continue. The event shows a control failure in the input path.

A client-approved tool that changes terms. A provider adds a new retention or sharing feature. The old approval was based on a previous route. Recheck the product terms and workspace settings before the next amber upload, and tell the client if the approved processing scope changes. A quarterly review is helpful, but a material product change should trigger an immediate check.

Copy this one-page consultancy rule into your team handbook

Before using AI on a project, the engagement lead records the client contract restriction, data tier, approved tool and permitted task. Green material may be used in an approved account after source checks. Amber material requires documented permission, task-specific minimisation, a second-person redaction check and a named output reviewer. Red material must not enter the tool. Staff must not use personal accounts or broad connected-app access for client work. Every AI output is a draft and must be checked against source records before a client sees it.

Add an exception route: “If the task cannot be completed within the approved scope, stop, describe the proposed data and recipient, and seek a decision from the engagement lead. Record the decision before uploading. Do not treat an urgent deadline as implied consent.” Make the rule available at the point staff choose a tool, not in a policy folder nobody opens. Use a short form with project ID, task, tier, data fields, tool, approval link, reviewer and deletion date.

Test the rule on one real workflow. Ask one consultant who did not write it to classify a public report, a coded client spreadsheet and a named interview note. If their decisions differ from the engagement lead's, refine examples and definitions. Then review a sample of actual prompts for excess information and a sample of final outputs for unsupported claims. The aim is a repeatable habit: identify the client promise, narrow the input, verify the tool route and sign off the result.

Keep the review trail without retaining every secret

A project record should show what was decided, not become a second uncontrolled archive of sensitive prompts. Record the project ID, data tier, source extract version, tool and account, approval reference, reviewer, output version and date. Keep the actual confidential source in the client's authorised repository under its existing retention rules. If an incident investigation later needs to reconstruct the AI input, the versioned extract and access log can support it without duplicating client material in a policy spreadsheet.

For an illustrative management project, the approved AI task is to group 80 coded workshop comments. The register might say “P17, amber, extract v3, 80 rows, client approval 12 April, analyst review 13 April, report chart v2”. It need not reproduce all 80 comments. If the comments are removed from the AI provider after the project, record the deletion action and the provider's confirmation mechanism. Do not promise deletion from every backup unless the contract actually provides it.

Output review deserves its own checklist. Check numbers against the source, inspect quotations for changed meaning, test whether the model invented a person or event, and look for confidential details pulled from earlier context. For a recommendation, separate observed evidence from the consultant's judgement. An AI summary saying “staff resist the change” may overstate three ambiguous comments. The reviewer can instead write “three of 80 comments raised concerns about the new rota; the sample is too small to infer a wider view”. That is an illustrative correction with a traceable denominator.

Send the final version through the client's agreed channel. A share link from an AI chat may expose the entire conversation, while an approved document can contain only reviewed output. Check attachments and document properties before sending. If a colleague asks to reuse the report on another client, run the classification again: a polished final slide may still carry confidential metrics or distinctive methods. The human-review tutorial explains the general sign-off pattern; the consultant's extra duty is to protect the client context throughout that pattern.

Decide what to do when the answer is unclear

Ambiguity should have a short route to a decision. The analyst writes a two-sentence request: the proposed task, the minimum data fields, the recipient and why a synthetic example will not work. The engagement lead checks the contract and tool record. If the issue is legal or professional, a qualified adviser reviews it. The decision is recorded as allowed with conditions, refused, or pending. “The deadline is tomorrow” changes urgency, not permission.

For instance, a client requests a board presentation by Friday and sends an unredacted 60-page personnel review on Thursday. AI could summarise it quickly, but the document includes staff health and disciplinary details outside the agreed AI scope. The team can read it manually, ask the client for a safe aggregate extract, or discuss a properly controlled route if there is time. It cannot assume that the client's request for speed authorises an unapproved upload. A good policy makes that decision ordinary rather than a personal confrontation.

Confidentiality questions for consultants

Is an NDA with the client enough to use any AI tool?

No. The NDA may restrict disclosure to third parties and may say nothing about AI processing. Read the engagement terms, client security requirements and the tool's processing terms. Obtain documented approval for the exact use if required. A separate confidentiality agreement with the tool provider does not override your promise to the client.

Can I paste a client document if I turn model training off?

Switching off model training addresses one use of the data, not every issue. Retention, human support access, subprocessors, connected apps, sharing and deletion still matter. Decide whether the client permits the transfer and whether the full document is necessary; use a redacted extract where possible.

What if the client refuses AI processing?

Record the restriction on the engagement and use a manual or synthetic-data route. Tell staff and subcontractors which project materials are excluded. A refusal does not stop you using AI for unrelated generic work, such as drafting a blank meeting agenda, provided no confidential client facts enter the prompt.

Further reads

• Questions to Ask Before Buying AI That Touches Client Data — Ask the vendor about retention and access before approval.
• How to Mention AI Use in Client Contracts and Proposals — Document a permitted use in the engagement terms.
• Reusing Past Client Work With AI Without Leaking Client Data — Control reuse of old deliverables across engagements.
• How to Use ChatGPT Projects to Keep Client Work Separate — Organise approved work by client once permissions are clear.
• Is It Safe for an Accountant to Use ChatGPT With Client Data? — Compare a profession-specific confidentiality case.
• Best AI to Use for DoD Contractors: A CUI Screening Checklist — A 17-question checklist for a small DoD subcontractor: what to ask any AI vendor about data location, retention and compliance before CUI goes near it.
• Consulting Pricing Models After AI: Fixed Fee, Retainer or Value? — Which pricing model survives AI-cut hours? Worked fixed-fee and retainer sums, a value-pricing test, scope limits and wording for telling clients.
• How to Use AI in a Small Consultancy: Proposals, Research and Delivery — Stage-by-stage AI use for a three-person consultancy: proposals, research and delivery, with the confidentiality rules that decide which tools you can use.
• ICAEW AI Guidance for Small Practices: A Client Notice and Staff Checklist — ICAEW's generative AI guide turned into a client notice, terms-of-business wording and a one-page staff checklist for a small accountancy practice.
• AI Tools for Tax Advice: The Risks a Small Practice Must Manage — Invented rules, exposed client data and unreviewed drafts are the real risks of AI tax advice. Here are the controls a small practice can set up this month.
• Can Consultants Use ChatGPT With Client Data? NDAs and Settings — A clause-by-clause NDA check and a redaction workflow for consultants who want to use ChatGPT on client work.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: GDPR Recital 26 on pseudonymised data; Anthropic privacy centre articles on whether data is used for model training (commercial and consumer products). Checked 4 November 2026.