Should a consulting firm build its own AI model?

What does building your own AI model mean for a consulting firm?#

Building your own AI model can mean four very different projects, and partner meetings often stall because each partner pictures a different one. Training from scratch, fine-tuning an existing model, configuring a commercial model and buying a vertical tool differ sharply in cost, risk and the records they need.

The distinction matters most for client material. Configuration reads documents at the moment someone asks a question and can follow folder permissions. Fine-tuning writes patterns from training examples into the model itself, which is much harder to undo. Most requests that reach a managing partner as our own model turn out to be configuration requests.

• 1Buy: a proposal, research or meeting tool sold to professional services firms and used largely as delivered.
• 2Configure: an enterprise assistant connected to the knowledge base, playbooks and approved past work, with firm instructions and templates.
• 3Fine-tune: an existing model trained further on firm examples so its drafts follow the firm's structure and method.
• 4Train from scratch: a new foundation model, which needs data and compute far beyond any single firm's archive.

The short answer: configure first, build only on evidence#

The short answer for most mid-size consulting firms is no: configure a commercial model on clean, permissioned firm records first, and consider fine-tuning only after that setup has demonstrably failed on a specific, repeated task. Configuration covers the common needs, such as finding past work, drafting proposal sections in house style and summarizing stakeholder interviews, without moving client material into model weights.

Treat licensing your records as a separate column in the same decision. A license does not depend on what the firm builds internally, and records too client-bound to train an in-house model can still be prepared for one.

Three tests before you fund a custom model#

A custom model is worth funding only when three tests pass together: enough consistent examples, clear rights to train on them, and a repeated task where configured tools measurably fall short. Failing any one of the three is a reason to stay with configuration.

Volume is where firms most often overrate themselves. Years of engagements sound like a deep archive, but once client deliverables are carved out and inconsistent formats are set aside, the comparable examples left for any single task are often thin. Write each answer down with evidence before a developer is engaged; a test that passes only in a partner's memory has not passed.

Why client confidentiality usually decides the question#

Client confidentiality usually decides the question because the most useful training examples in a consulting firm are client work. Confidentiality clauses commonly limit use of client information to the purpose of the engagement, and many newer engagement letters address AI tools directly, so training a model on that material can go beyond what the contract allows.

The technical difference sharpens the risk. A retrieval setup reads a document only when asked, so access can follow permissions and a file can be removed by deleting it from the index. A fine-tuned model absorbs patterns from its examples and can sometimes reproduce fragments of them; removing one client's material generally means retraining without it.

Before any fine-tuning project, have counsel review the contracts behind every proposed example and record which are firm-owned, which are permitted with conditions and which are excluded. Acquirers and client auditors ask for the same record.

The costs that rarely appear in a build proposal#

The costs of a custom model sit mostly outside the training run: preparing examples, proving quality and keeping the model current. Developer proposals often price only the build itself.

General-purpose models also improve quickly, so a fine-tune that beats a configured assistant today can be overtaken by the next commercial release and leave the firm maintaining an asset that no longer earns its keep.

• 1Data preparation: pulling examples from SharePoint, the PSA and the CRM, removing client names and figures, and labeling which outputs were good.
• 2Evaluation: a review set of real tasks with expert-graded answers, maintained by senior people whose time is otherwise billable.
• 3Rights review: counsel time to clear each source, repeated whenever new examples are added.
• 4Upkeep: retraining when methods change or when the base model the firm built on is retired.
• 5Ownership: a named person accountable for the model's behavior, access controls and security reviews.
• 6Exit terms: who holds the weights and the training set if the developer relationship ends.

A decision sequence for the next partner meeting#

A decision sequence keeps the build question grounded in evidence rather than enthusiasm. Each step produces a record the partner group can review, and most firms stop before step five, which is the intended result.

Keep the graded review set after the decision, so each new commercial model release can be checked against your current setup without restarting the debate.

• 1Step 1: name one repeated task, such as drafting the approach section of a proposal or synthesizing stakeholder interviews.
• 2Step 2: clean and permission the documents that task depends on, starting with playbooks and firm-owned templates.
• 3Step 3: configure an enterprise assistant on those documents and agree on a review set of real past tasks.
• 4Step 4: have senior staff grade outputs and record exactly where the firm's method is missed.
• 5Step 5: only if gaps persist, run the three tests and scope a fine-tune with counsel and IT.
• 6Step 6: decide separately whether to license prepared, firm-owned records, with terms that do not restrict your own internal use.

Illustrative: a customer experience consultancy weighs a custom model#

Illustrative: a fictional customer experience consultancy redesigns contact center operations for insurers and utilities. Its partners want a proprietary model that writes journey maps and operating model recommendations in the firm's method. Playbooks sit in Confluence, engagement folders in Google Drive, opportunities in Salesforce, and time and staffing in its PSA.

The volume test fails first. Journey maps follow a different template for each partner, and most final recommendations are client deliverables under MSAs that limit reuse. The firm instead configures an enterprise assistant over its Confluence playbooks and curated firm-owned templates, after tightening Drive permissions so client folders stay with their engagement teams.

Partners grade the assistant on past proposal sections and find its first drafts follow the method closely enough. The firm drops the custom model plan, standardizes its journey map template so future work is consistent, and separately starts a metadata-only review of whether its internal project reviews and proposal history could be licensed.

How SourceX approaches firm records in this decision#

SourceX looks at the same records a build decision depends on, but for a different outcome: whether a prepared package could be licensed to AI developers while the firm keeps ownership. SourceX's own rights in a deidentified dataset are set out in the signed supplier agreement.

The SourceX Enterprise Data Value Framework rates records on drivers including domain expertise, human-generated signal, recency and rights, and weighs preparation cost and privacy burden against them. Engagement records that fail the volume test for an in-house model can still rate well when they show expert decisions linked to outcomes.

Any license follows the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Client-owned deliverables are carved out in Rights, client details are removed in Preparation, the firm approves every package, and a SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization.