Turning a Retiring Expert's Knowledge Into an AI-Searchable Company Brain

Every established company has a version of this person: the service technician who diagnoses a machine by sound, the Meister who knows why the process runs at that temperature, the inside sales veteran who remembers what was agreed with a customer in 2011 and why. When they retire, the standard response is a handover document and a few weeks of shadowing, which captures perhaps the outline of what they know. The dense part, the thousands of small decisions and exceptions, has never been written down because writing it down was never anyone's job.

What has changed is that AI removes the old excuse. The reason expert knowledge stayed in heads was that turning it into a searchable, maintained documentation system cost more effort than anyone could justify. A language model changes that equation twice over: it makes capture cheaper, because talking is enough and the model structures the transcript, and it makes retrieval dramatically better, because a colleague can ask a question in plain language instead of guessing which folder or file name the answer hides behind.

Do not hand the expert a template and ask them to fill it in. Experts are usually poor at writing down what they know, because the most valuable knowledge feels obvious to them and gets skipped. Instead, run recorded working sessions: a colleague or the expert's successor asks them to walk through real cases, real machines, real customers. What do you check first when this fault appears? Why do we do it this way and not the obvious way? What did we try before that failed? The failures and the reasons are the gold, and they only come out in conversation.

Then let the model do the clerical work. Transcribe the sessions, have the AI structure each one into topics, extract the decision rules and exceptions, and flag contradictions or gaps for a follow-up session. Add the documents that already exist, service reports, old emails, maintenance logs, into the same pool. The expert's remaining time is spent reviewing and correcting the structured output, which is a far better use of their last months than writing prose nobody will read.

The retrieval side is where this becomes daily infrastructure rather than an archive. The standard approach is retrieval-augmented: the captured material is indexed, and when someone asks a question, the system finds the relevant passages and generates an answer from them, with references to the source documents. The citation part is not optional. An answer that says why, and points to the session or report it came from, lets the user judge whether to trust it. An uncited answer is just a confident guess wearing the expert's authority.

Be honest about the limits with your team. The system will sometimes retrieve the wrong passage or generate an answer that sounds right and is not, especially at the edges of what was captured. It answers from what was recorded, and what was recorded is incomplete. That is why the right framing internally is a well-read colleague who is usually right and always shows their sources, not an oracle. For safety-relevant or high-cost decisions, the system informs the human who decides, it does not decide.

Timing matters more than tooling. If the expert leaves in three months, you will capture fragments under pressure. Start the interview cycle a year or more before the exit date, while there is time for follow-up sessions on the gaps the first pass reveals, and while the expert can still be asked when the system's answer looks wrong. This also changes the emotional dynamic: begun early, the project honors a career's worth of knowledge instead of feeling like an exit formality, and most experts respond to that.

The second failure mode is treating the capture as a one-time project. A knowledge base that stops growing on the expert's last day starts aging on the same day, because processes change and machines get replaced. Give the system an owner, and build one habit into the successor's team: when the system fails to answer a question that later gets solved, the solution goes back in. That single loop, question failed, answer added, is the difference between a company brain and a snapshot of one person's memory slowly going stale.