AI governance policy for consulting firms: what to include

What a consulting firm AI policy must settle#

A consulting firm AI policy must settle the decisions consultants face every day: whether a tool is allowed, whether this client's material may go into it, whether the client should be told, and who checks the result. If the policy leaves those to individual judgment, each engagement team will answer differently.

Clients expect written answers. Security questionnaires, procurement terms and renewal conversations ask which tools touch client data and how AI-assisted work is reviewed. A policy with evidence behind it turns those questions into a document request rather than a debate.

This outline is a starting point rather than finished policy text. Contract terms, client policies and applicable law differ, so counsel should review the final wording.

Copy-ready policy outline#

The outline below covers the sections most consulting firms need. Each heading can be a short paragraph in the finished policy; resist the urge to turn it into a manual.

• 1Purpose and scope: who the policy covers, including contractors and subcontractors, and what counts as AI use.
• 2Approved tools: a named list of tools and account types, with the contract terms that make each acceptable, such as no training on firm or client content.
• 3Data classes and rules: what may enter which tool, by class of information.
• 4Client data: the default rule, how engagement-specific restrictions are recorded, and who checks the contract.
• 5Disclosure: when the firm tells clients that AI assisted a deliverable, and the standard wording.
• 6Human review: who must review AI-assisted analysis, text or code before it reaches a client, and what they check.
• 7Records: what is logged about AI use on each engagement, and where.
• 8New tools: how staff request a tool and who approves it.
• 9Incidents: what to do if client information enters an unapproved tool.
• 10Training and updates: how staff learn the policy and what triggers a revision.

Data classes and where each may go#

Data classes make the policy usable, because a consultant can classify a document faster than they can interpret a clause. Five classes cover most consulting work.

Client data rules and engagement-level overrides#

Client data rules start from the engagement contract, which overrides any firm default. Many confidentiality clauses limit the client's information to performing the services, some client policies ban third-party AI tools outright, and others allow them within the client's own environment.

The practical answer is a field in the PSA or CRM for each engagement: AI permitted, not permitted, or permitted with conditions, linked to the clause or client email that decided it. Engagement partners set it at kickoff; nobody should have to reread a contract mid-project.

Treat training separately from use. Applying an approved tool to a client's material for that client's work is one question; using that material to train or fine-tune a tool the firm keeps is a narrower one that usually needs explicit contract language or client consent. The policy should say so in one sentence and point to the firm's process for asking.

How to approve a tool: read the terms plan by plan#

Approving a tool means reading the vendor's terms for the specific plan the firm will buy, because one vendor can treat business and individual accounts differently. GitHub states that it does not use Copilot Business or Copilot Enterprise customer data to train AI models, while its documentation says that from April 24, 2026, interactions on individual Copilot plans may be used for training unless the user turns that setting off.

Microsoft's documentation for Microsoft 365 Copilot states that prompts, responses and data accessed through Microsoft Graph are not used to train foundation models. Zoom's terms state that it does not use audio, video, chat and similar communications content to train Zoom or third-party AI models, and Zoom notes that customers on separately negotiated contracts are governed by those contracts. Record what you checked and the date in the tool register, because terms and features change.

• 1Training: can inputs, files or outputs train the vendor's or anyone else's models, and on which plans?
• 2Retention: how long are prompts, files and outputs kept, and can admins shorten that?
• 3Location: where is data processed, and which subprocessors are involved?
• 4Controls: can admins manage sharing, connectors and newly released AI features?
• 5Contract: do negotiated terms or a data processing agreement override the online terms?

Disclosure, review and records: owners and evidence#

Disclosure, review and record-keeping are where policies fail quietly, because nobody owns them. Assign each element to a role and decide what evidence proves it happened.

What a reviewer of AI-assisted work should check#

A reviewer of AI-assisted work checks substance, not style. Fluent text hides errors well, so the policy should name what the reviewer confirms before signing off, and the sign-off should be recorded in the project file.

The reviewer should be someone who could have produced the analysis without the tool, usually the engagement manager or partner, not the person who prompted it. Where a deliverable mixes AI-assisted and manual sections, the review covers the whole document, since errors often sit where the two meet.

• 1Sources: every factual claim and figure traces to a source the reviewer can open.
• 2Client facts: names, numbers and dates match the client's own documents.
• 3Confidentiality: no other client's information appears in text, tables or charts.
• 4Reasoning: recommendations follow from the analysis rather than from confident wording.
• 5Ownership: the engagement team agrees with the conclusions and can defend them in the room.

Illustrative: a compliance consultancy writes its first policy#

Illustrative: a fictional compliance consulting firm learned that consultants were summarizing client policy manuals in personal chat accounts. The discovery came when a financial services client sent a security questionnaire asking which AI tools touched its documents.

The general counsel drafted a policy from the outline above, moved staff to business accounts whose terms excluded training on customer content, and added an AI permission field to every open engagement in the PSA. Proposals gained a short disclosure paragraph, and the tool register recorded the plan, terms and review date for each approved tool.

The questionnaire was answered with the policy, the tool register and the engagement record. The data classes also showed that the firm's methods and internal reviews were firm internal material, which later made a licensing fit check on those records quick to scope.

How the policy connects to licensing firm records#

The same data classes that govern AI tools also show which records a firm could ever license. SourceX considers only firm-owned material, typically the firm internal class, and carves out client confidential and restricted material in the Rights step of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery.

For any package that proceeds, a SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization. A firm with a working AI policy has already done much of the classification that packet relies on.