How to anchor AI knowledge so it does not leave with one person

Almost every business we walk into has one of them. The person who started using AI before anyone asked, who built the prompt that saves the sales team an hour a day, who knows which tool works for what and which one quietly gives wrong answers. Usually they are not in IT. Often nobody officially asked them to do any of it.

That person is the best thing that happened to your AI adoption, and the largest single point of failure in it. Because almost none of what they know exists anywhere except in their head.

Why this is a bigger risk in a small business

A large organisation has redundancy by accident. Three people do overlapping work, there is a wiki nobody loves but everyone uses, and a departure means a rough quarter rather than a full stop. A business of forty people has none of that. Knowledge concentration is not a governance failure there, it is just how small teams work: one person becomes the person who does the thing, and everyone else is glad someone does.

That works fine for the coffee machine and badly for the tool that now drafts your quotes. When the AI enthusiast leaves, three things go at once: the working setup, the reasons behind the setup, and the judgment about when not to trust it. The first is recoverable. The second and third usually are not.

Handwritten notes on paper. Most AI knowledge in a small business is never written down anywhere.

What actually walks out the door

It helps to be specific, because "knowledge" is too vague to act on. Four separate things leave with that person, and they need different fixes.

The mechanics. Which tool, which account, which settings, which prompt. This is the easiest to write down and the part people usually mean when they say documentation. It is also the least valuable of the four, because it is the part most easily rebuilt.

The reasoning. Why this tool and not the other one, why the prompt is phrased that oddly, why the output gets checked at that specific step. Without this, the next person inherits a set of rituals they cannot evaluate and will either follow blindly or throw out entirely.

The failure knowledge. Where it goes wrong. Which kinds of questions produce confident nonsense. What the tool did that one time in March that made everyone lose an afternoon. This is almost never written down anywhere and it is the most expensive to relearn, because you relearn it by making the same mistake again in front of a customer.

The relationships. Who at the vendor actually answers, which colleague agreed to review the outputs, who signed off on using it for customer data. Invisible until it is gone.

Four things that keep it in the building

None of these require a documentation project or a new system. They require deciding that the knowledge belongs to the company rather than to a person, and then acting like it.

One: a second pair of hands from the start. Not a backup who reads about it, a second person who actually runs the thing some of the time. Knowledge that has only ever been used by one person is not verified knowledge. The first time someone else uses it is the first time you find out what was never explained. Do that while the original person is still there to answer, not after.

Two: write down the failures, not the features. If you only have the energy for one page, make it the page of things that went wrong and what was done about it. It is the part that cannot be reconstructed from the tool's own documentation, and it is the part that protects the next person from repeating an expensive afternoon.

Three: put the tool in a shared account, not a personal one. This sounds administrative and it is the single most common way capability walks out the door. A tool bought on someone's own login, paid on their card, tied to their email, leaves when they do, along with the history that explains how it was used.

Four: make the judgment explicit in writing. Not "use AI responsibly" but "this tool drafts, a person always sends" and "we do not put customer names in it." That belongs in your AI-beleid, and the point of writing it down is precisely that it stops depending on one person remembering to be careful.

Two colleagues at a whiteboard. Knowledge that survives is knowledge a second person has actually used.

The four categories against the four fixes

The pattern in that table is the point: the thing that is easiest to document is the thing that matters least, and the thing nobody writes down is the thing that costs the most to lose. Most documentation efforts get this exactly backwards, producing a neat page of settings and no record of the March incident.

Why this is also a legal question now

Article 4 of the EU AI Act requires organisations to support a sufficient level of AI literacy among the people who work with these systems. The wording matters here: the obligation sits with the organisation, not with the individual who happens to be interested. An organisation where all the AI understanding lives in one self-taught employee is not meeting that standard in any meaningful sense, regardless of how good that one employee is.

This is not a reason to panic, and there is no inspector coming to check your prompt library. It is a reason to notice that the organisational fix and the compliance fix are the same fix. Spreading the knowledge is what Article 4 is asking for, and it is what protects you from the resignation letter. Read more on what the requirement actually covers under AI-geletterdheid.

What this looks like in practice

The cheapest version of this is a conversation, not a project. Sit with the person who knows, and go through the four categories out loud with someone else in the room who does not know. Write down what surprises the second person. That list is your documentation, and it is more useful than anything produced by asking someone to "document the AI workflow," because it captures exactly the gap between what one person knows and what everyone else does.

Do it before you need it. The version of this conversation that happens during someone's notice period is a worse conversation, because by then they are already half gone and the incentive to explain the awkward parts has quietly disappeared.

About this page

The Article 4 reference is to the AI literacy obligation in the EU AI Act, which sits with the organisation rather than the individual, cross-checked against the AI Act text. The four-category split and the four fixes are Radical's own working method, drawn from what we see in AI-Foto sessions. Written by Radical's own team; no client data was used.