← Blog

AI knowledge management: what really changes compared to a wiki

AI knowledge management is the practice of capturing a company's know-how passively, from the documents and conversations that already exist, and making it searchable in natural language, with the source in front of you. The difference from a wiki isn't the interface: it's who does the work of writing. In a wiki it's a person who has other things to do. In an AI system it's the system.

That's the whole thesis. The rest of this article is why it matters and what to demand of a system like this so it doesn't end up being another graveyard.

Why do wikis fail, if it isn't a lack of discipline?

Anyone recognises the sequence: a space is opened, ten pages are filled in enthusiastically, and three months later it's out of date and nobody consults it.

The usual explanation is that the team lacks discipline. It isn't that. Documenting is a separate job that competes with the real work, and it always loses. Nobody postpones documenting out of laziness: they postpone it because there's a client waiting. And since the improvement that having an up-to-date wiki would bring has nobody angry behind it, it never rises up the list.

There's a second problem, quieter: when it finally does get written, the obvious part gets written. The steps, the process, the part that can be enumerated. And precisely the valuable part is left out (the judgement, the why, the nuance) because the person who holds it no longer sees it as information. It seems obvious to them.

What changes when the system captures instead of asking?

An AI knowledge system inverts the burden. Instead of asking someone to sit down and write, it observes what is already being produced and keeps what is worth keeping.

In practice that's three ways in:

  • The documentation that already exists. It gets indexed with its author, its type and its date, without reorganising anything. You don't have to tidy the folder before starting.
  • What circulates day to day. A useful answer in a work channel is knowledge even if nobody has called it that. The system detects it and saves it with its context.
  • What nobody has ever written. This is the one almost no product has, and it's the one that changes things most. When someone asks something that isn't recorded anywhere, the system doesn't improvise: it logs the gap, groups the similar questions and goes and finds the person who does know.

The third way is what turns a search engine into a system that learns. Without it, an AI assistant only knows what the company had already written down, which is exactly the problem we came to solve.

What to demand of it so it isn't hot air

The category is filling up with products that are a search engine with a chat layer on top. Four things separate a serious one from a future problem.

1. That it cites the source, always

An answer with no origin can't be verified, and what can't be verified isn't used to decide anything. If the system doesn't say which document, which conversation or which person each answer came from, you haven't solved the knowledge problem: you've added a layer of doubt on top.

2. That it knows how to say «I don't know»

A language model fills gaps by design. If the system isn't deliberately built to flag its low confidence and stop, it will invent with a confidence indistinguishable from when it's right. In an internal context that's worse than having nothing, because it looks like the truth.

3. That permissions are applied at search time, not afterwards

This is the most common failure and the most expensive, and it's listed as its own category in the OWASP Top 10 for LLM applications. Semantic search finds what is most relevant to a question, which is not the same as what the person asking has permission to see. If the permission filter is applied after searching, sooner or later a fragment of the salary table appears in an answer about shifts. I developed this fully in why AI assistants leak information.

4. That personal data doesn't enter the circuit

Payroll, personnel records and health data shouldn't be vectorised at all. The cheap way to stop them coming out where they shouldn't is never to put them in there. And if your company is in the EU, this isn't a design preference: it has GDPR compliance consequences (the text of the Regulation is shorter than it looks) that are best resolved before signing, not after.

When it's worth it and when it isn't

I'll be honest about the limits. A system like this isn't worth it if your company is small and everyone sits in the same room: there, asking out loud is still faster than any tool.

It starts being worth it when two symptoms appear at once: the same two or three people answer every question, and there are problems that were already solved once and come back because nobody remembers how it was done. That's the point where the dependency stops being an anecdote and starts having a measurable cost, even though it doesn't appear on any invoice.

And it isn't worth it either if what you're after is somewhere to store things. You already have a shared drive for that. This is about the opposite question: being able to retrieve what the company already knows at the moment it's needed, without depending on the right person being available.