Czas czytania: 13 minut
From tacit knowledge to training asset: how to capture internal expertise with AI
Capturing internal knowledge isn't documenting it. It's a process of extraction, structuring, and maintenance that turns what an expert knows into a trackable, ready-to-consume training module.
Somewhere in your company there's a person who knows something nobody else does. How to recover a line when it jams on the second shift, what a senior rep checks before writing off an account, in what order to review a file so no error slips through. That knowledge isn't in any manual. It lives in the head of whoever has been doing it for years.
When someone notices this, the usual instinct is to ask that person to document it. Write down the procedure, record a session, leave "everything noted" before going on holiday or changing roles. And the result almost always disappoints: a long document that misses the important part, or an hour-long recording nobody watches again.
The problem isn't the person's willingness. It's that capturing knowledge and documenting it are two different things, and most companies only have a method for the second one.
In this article we break down the full process: how to extract the knowledge an expert doesn't even realize they have, how to turn it into a training asset people can actually consume and update, and what to measure to know whether the capture really worked.
When you ask an expert to explain what they do, they give you an incomplete version. Not because they want to hide anything, but because they don't have conscious access to much of their own judgment. They've automated it.
There's a classic piece of research on this in surgical training. When expert surgeons were asked to describe, step by step, a procedure they'd performed hundreds of times, they left out around 70% of the clinical knowledge steps, half of the action steps, and nearly three quarters of the decisions.¹ And this happened even with structured interviews designed to draw that knowledge out. It's called the expert's blind spot: the better you master a task, the less aware you are of what you actually do to carry it out.
This has an uncomfortable consequence. If your capture method is "tell me how you do it", the result will be incomplete by design, no matter how good the expert is or how willing they are to help.
On top of that fundamental problem sits one of scheduling. In practice, the expert who holds the knowledge is also the busiest person on the team. In a recent study on instructional design, expert-availability delays show up as the second-biggest barrier to speed, flagged by 30% of professionals, and the median designer gets expert collaboration during just 38% of the project.² The knowledge exists; access to whoever holds it is the bottleneck.
That's why an operation that depends on the right people always being available is a fragile operation: the day that person is out, retires, or moves on, the knowledge leaves with them and no method is left to recover it.
The practical takeaway is that capturing critical knowledge needs a process, not good intentions. And that process has concrete steps.
We call the process that turns what a person knows into a training asset the organization can consume, measure, and maintain without depending on them the Knowledge Capture Protocol. It isn't a documentation project, but a sequence of five steps, and each one fixes a different failure of the traditional approach.
This method is what feeds a knowledge infrastructure, the system that then keeps that know-how available and up to date. Here we focus on the step before that: how assets enter the system in the first place.
Not all knowledge deserves the same effort. The criteria for prioritizing combine three signals:
The overlap of the three gives you the starting list. A critical procedure that only one person masters and that gets used every week is an obvious candidate. A one-off trick half the team uses with barely any consequences can wait. The idea is to start with three or four focal points, not with an inventory of the whole company.
This is the step almost nobody does well, and the one that most determines the quality of the result. Eliciting means extracting the knowledge with a technique built to get around the expert's blind spot, instead of asking them to recite it.
Three techniques that work better than the open interview:
This is where AI shifts the balance of effort. AI-assisted capture transcribes the session, orders it into blocks, and flags the gaps where a decision or a reason is missing, so you only go back and ask about what's left. That way the expert doesn't write: they hold a well-directed conversation, and the work of structuring what they said no longer falls on them.
A raw transcript isn't training. The next step is to restructure that material into modules that can be consumed independently.
When the starting point is an existing document, the process has a name: Visual SOP Refactoring. It isn't "turning a PDF into a video", but analyzing the hierarchy of the original content, identifying the knowledge blocks, and reorganizing them into 3-to-7-minute units, each with one complete, testable idea. The logic is the same when the starting point is an interview: from the continuous flow of what the expert said, you extract standalone modules, ordered by dependency.
A well-built module meets three conditions: it's short, it answers one concrete question, and it records who completed it. That last condition is what turns it into an asset rather than one more video in a folder.
With the modular script ready, you generate the content. Video has a practical advantage here: it's checked at the point of need, paused, replayed, and watched from any device.
AI production lets you avatarize the expert themselves from a photo and a minute of audio, so the knowledge keeps a recognizable face without a studio and without calling that person back in every time something changes. And the same module can be deployed in over 120 languages, including regional ones like Catalan, Galician, and Basque, without multiplying production. In a workforce with several nationalities, that's the difference between the knowledge reaching the whole team or only part of it.
An asset you can't measure or update is fragile knowledge again, just in a different format. The last step closes the loop:
Without this step, capture is a one-off effort. With it, it becomes part of the infrastructure.
Before. In a packaging plant, the fine adjustment of one machine was mastered by a technician with twelve years on the job. When he was off, downtime from micro-adjustments dragged on: the shift waited for him to come back or called his mobile. The knowledge was there, but one person away.
After. The technician was recorded making the adjustment while explaining out loud what he was looking at and why. That session produced a short module, with his avatarized face, that any operator checks right at the machine and in their own language. The technician stopped being the only point of support, and downtime from that cause stopped depending on his calendar.
What changed wasn't the technology, but where the knowledge lives.
A capture process with no metrics is an act of faith. These are the signals that tell you whether the knowledge really moved from the person to the asset, organized by what each one measures.
| Metric | What it measures | Sign it's working |
|---|---|---|
| Critical coverage | % of priority knowledge already turned into an asset | The Step 1 processes have a published module |
| Fragility index | Nº of critical processes that depend on a single person | Drops with each capture; no critical process left unbacked |
| Capture time | Expert hours needed per asset produced | Tends to fall to one or two directed sessions instead of days of writing |
| Real consumption | % of the target audience that completes the module | High and sustained, not just in the first week |
| Application | Drop in questions to the expert about what's already captured | The team solves on its own what it used to ask |
The metric that matters most over the medium term is the fragility index. It measures exactly what the project sets out to solve: how many single points of failure the operation still has. If after six months of capture that number isn't dropping, the process is producing content, but it isn't transferring knowledge.
We've seen the same project derail for the same reasons. Four worth avoiding:
The know-how that holds up your operation doesn't need to be created. It already exists, spread across the people who've been doing their job well for years. What almost never exists is a method to get it out of their heads and turn it into something the organization can use without depending on them being available.
That method has steps, and none of them is "ask them to document it". It's about surfacing what the expert doesn't know they know, ordering it into modules someone will actually consume, and keeping it current so it doesn't go stale again. Technology (platforms like Vidext) makes that process viable at scale, but the starting point is treating knowledge as what it is: an asset, not a pending conversation.
The useful question isn't how much knowledge your company holds, but how much of it is one person away from disappearing today. Answering that is the first step; giving it a method, the second.
Documenting means writing down what a person can consciously explain. Capturing also extracts the tacit knowledge, the judgment, and the decisions the expert has automated and that don't appear in their own description. Documentation produces a file; capture produces a consumable, trackable training asset. Confusing the two is why so many manuals are complete and yet nobody can operate without asking.
With elicitation techniques built to get around the expert's blind spot. Instead of asking for a general explanation, you ask about specific cases ("the last one that went wrong"), record the person while they carry out the task, and push to the edges ("what do you check first when something fails"). These techniques surface decisions the person never verbalizes because to them they're obvious.
AI reduces the time the expert has to spend and the manual work of structuring. It transcribes the sessions, organizes them into blocks, flags the gaps where information is missing, and generates the final content in video, including the option to avatarize the person and translate the module into more than 120 languages. The judgment stays human; AI removes the heavy lifting that made capturing at scale unviable.
With the processes that are at once critical, fragile, and frequent: high cost if done wrong, dependent today on a single person, and needed often. Starting with three or four focal points like this delivers visible results fast and avoids the exhaustion of trying to inventory the whole company at once.
With a structured process, the expert usually needs one or two directed sessions per knowledge area, instead of days writing documents. The total time depends on the complexity of the process, but the whole point of the method is to reduce the load on the expert, who is the scarcest resource.
An LMS is where you host and deliver the modules; the Knowledge Capture Protocol is the method for creating those modules from the knowledge that lives in people today. An empty LMS doesn't solve the problem of critical know-how not being captured. The two are complementary: capture produces the asset, the infrastructure keeps it alive, and the LMS delivers it.
² State of Instructional Design, survey of more than 400 practitioners - Synthesia
