The real failure isn't "no answer" — it's the right answer to the wrong engagement
Picture a senior consultant on a Tuesday morning, three days into a stalled implementation, typing into the firm's shiny new AI assistant: "How did we handle the data migration cutover when the legacy system wouldn't export cleanly?" The assistant answers in two seconds, cites a delivery memo, and sounds completely sure of itself. The consultant ships the recommendation to the client by noon.
The problem: that memo was written for a different client, on a different platform, under a contract that explicitly carved out a workaround your current client's compliance team would never accept. The model didn't lie. It retrieved a real document. It just retrieved the wrong real document — and in consulting, that is the failure mode that costs you, because your entire product is "we know what to do here, specifically." A generic search box that returns ten links lets the human judge. A confident assistant that returns one synthesized paragraph removes the moment of judgment that used to catch this.
Consulting firms rarely lack knowledge. They lack a governed way to reuse it without leaking it sideways across engagements. Proposals, issue logs, cutover runbooks, methodology decks, and post-mortems sit scattered across drives and project folders, each soaked in client-specific assumptions that were never meant to travel. Point retrieval-augmented generation at that pile and you have not built leverage — you have built a very fast way to apply one client's context to another's problem. If you want a structured path through this, AI Knowledge Systems and RAG is the lane. If leadership is still arguing about what to automate first, start with the AI Opportunity Score.
Three controls, in this order, because a support knowledge base lives or dies on whose context it can see
First, permissioning that respects engagement walls — not just employee seniority. Most access models ask "is this person senior enough to see this?" A consulting knowledge base has to ask a harder question: "is this person on this engagement, and is this source allowed to inform that one?" A partner cleared to read everything is exactly the person who shouldn't have Client A's pricing logic auto-injected into Client B's proposal draft. Document-level boundaries and source-system permissions need to be wired in and tested before a single pilot user touches it — because the leak you can't undo is the one a model paraphrases into a deliverable.
Second, source quality, which for a firm means stripping client-specific reasoning from anything reusable. Tag approved materials by service line, document type, date, author, version, and — critically — by whether they're generalized methodology or client-bound work product. The reusable support knowledge base should hold sanitized troubleshooting paths and de-identified patterns, not the raw delivery memo with the client's system names still in it. Drafts, superseded runbooks, and one-off workarounds get archived or excluded. Gartner's research on building the case for data quality is blunt about why this drudgery pays: the cost of acting on bad data compounds quietly until something breaks expensively (Gartner guidance on data quality business cases), and Gartner separately warns that the lack of AI-ready data is the thing quietly killing AI projects (Gartner AI-ready data outlook).
Third, retrieval testing against your actual consultants' questions. Before launch, take the twenty questions your delivery teams actually ask under deadline — the cutover ones, the "client pushed back on the SOW scope" ones — run them through the system, and inspect which source documents it pulled, not just whether the answer reads well. If retrieval grabs the wrong engagement's memo, the answer is wrong even when the prose is flawless. This is precisely where MIT Sloan found firms stall: pilots that demo beautifully and never cross into trusted daily use, a gap so common it has a name (MIT Sloan Management Review: GenAI Divide).
Build it for one recurring job: the question your consultants ask under deadline
The first assistant should answer one narrow, high-frequency question well — not "everything the firm knows." For a support knowledge base, that question is usually some flavor of "we've hit this exact obstacle before; what's the approved way through it?" A library that returns sanitized, methodology-level troubleshooting paths with visible sources beats a firmwide oracle every time, because the oracle's ownership, permissions, and source hygiene are too diffuse for anyone to actually trust it. IDC's work on knowledge-worker time lost to hunting for information is real (IDC research on knowledge worker productivity) — but that time is only recovered if the answer the consultant gets is one they can defend to a client, and Bain's findings on missed targets are a reminder that activity without reliable execution doesn't move the number (Bain commercial excellence survey).
Here's the Monday sequence: name the user group (say, the delivery consultants on active implementations). Pick one source repository. Pull every document that names a specific client, and either sanitize it into a reusable pattern or exclude it. Tag what survives by service line and document type. Run your twenty real questions and read the retrieved sources, not the answers. Set a review cadence and a one-click "this answer was wrong" report — then watch what your consultants flag, because their failed queries are your roadmap for which knowledge to clean up next.
The assistant should always show its sources, and your team should know exactly when to trust it, when to escalate to a human who owns the methodology, and how to report a bad pull. When the source domain is clear, AI Knowledge Systems and RAG is the practical next step. If engagement-wall permissions or employee-use rules are still unsettled, fix that first with AI Governance and Training — because in a consulting firm, the rules about whose context can inform whose answer aren't paperwork. They're the product.
