Knowledge management: why your initiatives fail, and what AI changes

In a lot of companies, two things coexist without ever meeting.

On one side, a Confluence space, a SharePoint or a Notion. Four hundred pages. A tree structure carefully designed three years ago, with naming conventions and a page template. The last meaningful edit is eighteen months old.

On the other, fifteen metres away, the person everyone goes to see. They answer the same questions ten times a week: where to find the latest version of the master agreement, why this customer is not billed like the others, which clause turned out to be expensive back in 2023.

So the company has a repository and it has knowledge. They are simply not in the same place.

The reflex at this point is to blame the tool. We picked Confluence, we should have picked Notion. We picked Notion, we should have picked something else. That is almost always a dead end: the tool was never the cause of the failure, and replacing it fixes nothing.

Knowledge management is the set of practices through which an organization captures, structures, retrieves and reuses what it knows. Four distinct operations: an initiative is never worth more than the weakest of the four. The company above structured very well, and missed the other three.

Knowledge management is not documentation

Capturing means getting knowledge out of people's heads and informal exchanges. Structuring means giving it a reusable form. Retrieving means putting it back in front of someone at the moment the question comes up. Reusing is the only one of the four that pays anything back. The other three cost.

The classic distinction is still the most useful one. Explicit knowledge is what has been written down: procedures, meeting notes, specifications, contracts, formalized lessons learned. Tacit knowledge lives in people's heads: why that customer was lost, which supplier actually meets deadlines, which clause must never be accepted, how you recover a situation when the official process does not apply.

A document repository only handles the first, and only once it has been written down.

Yet nearly every corporate knowledge management initiative has concentrated its effort on a single one of the four operations: structuring. A tree, templates, a naming charter, an editorial committee. Capturing remained an act of goodwill. Retrieving was delegated to a mediocre internal search engine. Reusing was never measured.

That imbalance is enough to explain everything that follows.

And your written knowledge is not where you think it is

There is one more framing error, quieter, that skews most diagnoses: believing that explicit knowledge sits in the document tool. It is almost never all there, and often it is not even mostly there.

Take an honest inventory of your company. You will find:

• the Excel file with the pricing rules, maintained by one person, which carries far more authority than the official sales procedure;
• the "comments" column of the customer tracking file, where the real story of the account lives, the one the CRM does not tell;
• the ticketing tool, and its thousands of resolved cases that make up the company's actual troubleshooting knowledge;
• the ERP reference tables, item codes, business rules and settings, which encode decisions nobody can justify any more;
• the shared drive, with twelve versions of the same proposal and no way to tell which one was signed;
• the email threads and the Teams or Slack channels, where the trade-off was actually made, before being summarized nowhere.

None of this was ever called "knowledge". These are production tools, and knowledge settles in them as a by-product of the work. That is why no knowledge management initiative ever brought them into scope.

This is not a sign of disorder. It is how an organization that works normally behaves: people leave information where they produce it, not where a committee decided it should live. Every company works this way, and there is no reason to think yours is the exception.

Two consequences follow, and they explain the rest. First, an initiative limited to the document tool only covers a fraction of explicit knowledge, often a minority of it: replacing that tool with another one could never have changed anything. Second, the goal of "putting everything in one place" was never reachable, because it assumed migrating information that only makes sense inside the tool where it is produced.

Why knowledge management initiatives fail

Five causes come back, and they are structural. None of them is settled by a software choice.

1. The effort is asymmetric

The person who documents is not the person who benefits. Writing a page takes forty minutes, today, out of time that is already short. The benefit shows up in six months, for someone else, and nobody will ever know it came from you.

An immediate, certain cost against a deferred, uncertain and unattributed benefit: that trade-off is lost before it starts. Employees who do not document are not careless, they are rational.

2. Obsolescence is silent

A page that is wrong raises no alert. It stays online, filed under the right heading, with the right template, and it inspires exactly the same confidence as the day it was written.

This is the point most initiatives underestimate: outdated documentation costs more than no documentation at all. Faced with a gap, people ask. Faced with an obsolete page, people apply it. And it only takes a few bad surprises for teams to stop trusting the repository for good, including the parts that are still correct.

3. Searching costs more than asking again

This is the most decisive cause, and the one least often named.

Finding the information in the repository means opening the tool, guessing the vocabulary the author used, sorting through results, opening three pages, then checking which one is current. Fifteen to twenty minutes, with no guarantee of success.

Messaging the colleague who knows takes thirty seconds, and the answer comes back reliable and in context.

As long as that cost ratio holds, the repository loses every time. Not because it is badly built, but because it is more expensive to use than the human alternative. And that alternative has a hidden price, paid by the three or four people everyone turns to.

4. KM was treated as a project, not as a flow

A budget, a steering committee, a migration phase, an acceptance test, a launch, an internal communication campaign. Then the end of the project, and the team scattering onto something else.

A company's knowledge is not a stock to be built once, it is a flow that renews itself continuously. A flow whose supply you cut runs dry. The first six months keep up appearances, because the initial base is still fresh. The decay becomes visible around month eighteen, when nothing matches reality any more.

5. Storing was confused with making findable

A three-terabyte SharePoint is not a knowledge management system. It is a warehouse.

Storing has been solved for twenty years and costs almost nothing. Making findable, in the sense of "the right answer, to the right person, at the moment they need it, with the source", was never solved by document management tools. They index words, not questions. An employee searching for "can we push back billing for this type of customer" has no keyword that appears in the document holding the answer.

What AI actually changes

Four things have moved, and none of them deserves the word "revolution".

It flips the effort

The classic model asked you to file things upfront in order to find them later. All the rigour had to be invested at writing time, by the author, without knowing the future questions.

Natural language search grounded in the company's documents flips that contract. The interpretation effort is paid at question time, by the machine, and for a real question. The author no longer has to anticipate the vocabulary of whoever will be searching.

It makes an imperfect base usable

This is the most underestimated change. A classic engine needed a clean base to return good results. A RAG (Retrieval-Augmented Generation) setup reads what is badly filed: meeting notes, scanned PDFs, support tickets, discussion threads, old sales proposals. We cover the mechanism in our RAG guide.

This is not an implementation detail, it is what changes the economics of the subject. The entry condition is no longer "have a clean repository", a prerequisite nobody ever met. It becomes "have accessible sources", which almost every company already has.

It breaks the economics that killed the repository

Go back to cause 3. If getting a sourced answer takes thirty seconds instead of twenty minutes, the trade-off between searching and asking again tips over. For the first time, the system becomes cheaper to use than the colleague.

That is the only mechanism we know of that actually brings teams back to formalized knowledge. Not the charter, not the committee, not the internal communication: the fact that it has become the shortest path.

It finally tells you what is missing

This is the least known point, and probably the most interesting one over time.

A classic repository is blind. It knows how many pages it holds, never what people looked for and failed to find. So you steer documentation by opinion: the committee decides that "the purchasing processes should be documented", because someone said so in a meeting.

As soon as an assistant is connected to your sources, every question asked becomes a usable signal. And the questions arrive in natural language, the way people actually ask them. Analyzing them surfaces three things nobody could see:

• The gaps. A question that comes back twenty times a month with no source answering it correctly points precisely at the page to write. That is no longer an opinion, it is a measurement.
• The contradictions. When two documents say the opposite on the same subject, the assistant runs into it on every relevant query. Those conflicts, invisible as long as nobody read both pages side by side, become a list.
• Useful obsolescence. Not all outdated pages are equal. The one nobody has ever requested can wait. The one that sources thirty answers a week has to be fixed this week. Real questions rank the update effort for you.

That is what closes the loop. Causes 2 and 4 above, silent obsolescence and KM treated as a project, both came down to the same blindness: no way to know where the repository was slipping, therefore no way to maintain anything but a frozen stock. Usage becomes the source of truth about what needs documenting, and maintenance becomes a flow steered by facts.

An honest recap:

What AI does not change

An article that stopped there would be dishonest. Four limits hold.

Knowledge that was never written down stays out of reach. No model will recover why you walked away from that supplier in 2021 if it only exists in two people's memory. AI substantially improves "retrieving" and "reusing". It does nothing for "capturing". That is what remains the real knowledge management work, and the fact that it is now the only hard point is good news: you can concentrate your effort there instead of spreading it thin.

Access rights become more critical, not less. An assistant that crosses silos also crosses the partitions those silos were quietly providing. A poorly protected HR folder was not a problem as long as nobody knew it existed. It becomes one as soon as a natural language question can surface it. A serious assistant inherits the permissions of the source tools and only answers within the scope of the person asking.

Contradictions still require a human decision. When two documents say the opposite, a good system cites both and flags the conflict. It does not arbitrate, and it should not. That is a governance point, not a technology one.

Confidentiality remains an architecture choice. Feeding internal documents into a consumer AI means handing their content to a third party, with no traceability and no way back. We cover that point and its practical consequences in Contextual AI for your business.

What a knowledge management system looks like in 2026

No longer a single tool everyone is supposed to file into, but five layers built on what you already have.

Loading diagram…

The diagram reads as a closed circuit: documents stay in the tools where they already live, continuous indexing and permission-filtered search feed the assistant, and human review sends corrections back to the source rather than to a copy. That return arrow is what separates an ongoing flow from a one-off project.

The layers, in order: sources where they already are, continuous ingestion rather than a one-off migration, semantic search filtered by permissions, answers that cite their sources with dates, and a correction loop that lets a user flag a wrong answer and get the original document fixed.

That last layer is the one people forget, and it is the one that answers cause 4. It turns every use into an opportunity to improve, and turns the setup into a flow rather than a project.

Add light governance: who owns which source, how often you prune, who arbitrates contradictions. Three rules are enough, as long as they have an owner.

Do you still need a dedicated knowledge management tool?

This question comes up every single time, and our answer is probably the opposite of what you expect: the storage layer matters far less than it used to, the access layer matters far more.

In other words, do not replace your Confluence or your SharePoint. Connect them.

Migrating to new knowledge management software eats six to twelve months, mobilizes exactly the people whose knowledge you want to capture, and reproduces all five causes of failure in a more recent environment. You will have a prettier warehouse, with the same problem.

The only case where changing knowledge management tool is justified is when the current source is technically closed, meaning no API and no usable export. That is rare, and it can be checked in half a day.

For everything else, enterprise knowledge management has shifted from the choice of tool to the quality of the access layer: does it cover all your sources, does it respect your permissions, does it cite, is it still accurate in six months.

The first of those four criteria is the one that disqualifies the most solutions. An access layer that only reads your document tool takes you back to square one: it ignores the pricing file, the resolved tickets and the ERP tables, which is a large share of what your teams are actually looking for.

When knowledge management starts paying off

A few orders of magnitude to help you decide, to be weighed against your own situation rather than taken literally.

The trigger is almost never the volume of documents. It is the concentration of knowledge. Put the question differently: how many people in your company get interrupted more than five times a day for questions whose answer exists somewhere? If the answer is two or three, you already have an expensive problem, and growth is making it worse.

The other signals that matter:

• Onboarding longer than three months before a new joiner is autonomous on routine questions.
• An upcoming departure on a key role, with knowledge concentrated in a single head.
• More than three or four different sources of truth, with nobody knowing which one wins.
• Recurring mistakes caused by working from an outdated version of a document.

Below fifteen to twenty people, informal collective memory is usually enough and the subject can wait. Between fifty and three hundred, that is the zone where the cost becomes real without being visible in a budget yet, because it is paid in interruptions and delays rather than in invoices.

A concrete example: IT maintenance

Take an IT equipment maintenance provider, a case we know well.

Their technicians work on customer sites. Some are employees, others are external subcontractors brought in depending on workload and geographic coverage. On site, a technician needs three things at once: the applicable procedure, the customer history, and the context of the previous visit.

That knowledge is of two different natures, and that is what makes the case interesting.

There are documents first: the generic procedures, but also every particularity specific to a given customer. This piece of equipment must be shut down in a precise sequence. That site imposes an intervention window. This customer has a network configuration unlike any other. Those specifics are written down, but scattered across sheets, contract annexes and visit reports.

Then there is a database: the history of tickets and interventions. Who came, when, what was replaced, what failed again three weeks later. That is structured data, with dates, references and statuses, not documents.

No document repository covers both. This is exactly cause 5: the provider was not missing information, they had no single path to reach it. As a result, the rational behaviour for a technician on site was to call support, who would query the ticketing tool while the customer waited. Every call cost two people instead of one.

The subcontractor case added a constraint that classic repositories handle badly. An external technician needs access to the procedures of the customer they are working at that day, and nothing else. Broad access is unacceptable, no access at all makes them less effective than their internal colleagues.

On top of that comes a third use, in the office this time. Support and management need to query those same operational databases for analytical questions: profitability per contract, recurring failures across a fleet, adherence to response times. Same data assets, completely different question. We cover that specific angle in Your databases are a gold mine.

What this case shows: as soon as a company outgrows the wiki stage, its knowledge is mixed, both documentary and structured, and addressed to populations with different permissions. A knowledge management system that only handles one of the two natures leaves the problem intact.

How we approach the subject at Ask This Guy

Our position follows directly from the above: no migration.

Ask This Guy connects to your existing sources, whatever they are, and indexes them continuously. Your teams do not change where they put things, and you do not pay for six months of document overhaul before getting the first useful result.

We handle both natures of knowledge in the same assistant: documents, through RAG, and business databases, queried in natural language as described on our Talk to data page. That is what makes it possible to answer "what is the procedure on this site" and "how many interventions on this fleet since January" without switching tools.

Three points we do not compromise on, because they decide whether usage lasts:

• Every answer cites its sources, with dates. A user who cannot verify will not trust it, and a user who does not trust it goes back to their inbox and their colleague.
• Permissions are inherited from the source tools. The assistant never answers beyond what the person already had access to.
• Hosting is European, with an on-premise option when document sensitivity requires it.

Finally, we do not stop at go-live. Once the assistant is in place, your users produce every week the raw material all your previous initiatives were missing: the real questions. Our Insights console tracks volumes, tags, sentiment and answers rated unsatisfactory; we help you turn that into a concrete documentation work plan, the list of topics to write, contradictions to arbitrate and pages to fix first.

The detail of the approach, the available connectors and the cost model are on the turnkey enterprise RAG page, and the technical workings in our documentation.

Frequently asked questions about knowledge management

What is knowledge management?

Knowledge management is the set of practices through which an organization captures, structures, retrieves and reuses what it knows. It covers explicit knowledge, what has been written down, as well as tacit knowledge, what lives in people's heads. The weakest of the four operations decides the value of the whole.

What is the difference between knowledge management and document management?

Document management organizes files: versions, filing, lifecycle, archiving. Knowledge management targets the use of knowledge, including when it does not take the form of a document. A pricing file, a ticket history or an ERP settings table carry knowledge without being documents in the document management sense. That is why a purely documentary project only covers a fraction of the subject.

What is the difference between tacit and explicit knowledge?

Explicit knowledge has been formalized: procedures, meeting notes, contracts, specifications. Tacit knowledge was never written down: why a supplier was ruled out, which clause must never be accepted, how you recover a situation when the official process does not apply. Repositories only handle the first, and only once it has been put in writing.

What is a knowledge management system?

In 2026, it comes down to five layers. Sources stay where they are. Ingestion runs continuously, instead of a migration done once. Search is semantic and filtered by each person's permissions. Answers cite their sources with dates. And a user who hits a wrong answer can flag it and get the original document fixed. The single tool everyone was supposed to file into is no longer part of it.

What are the knowledge management tools?

The historical tools are wikis and intranets (Confluence, SharePoint, Notion, Jalios), alongside support knowledge bases and document management systems. The important point is elsewhere: the storage layer matters far less than it used to, the access layer far more. Knowledge management software that only reads its own content leaves out the pricing spreadsheet, the resolved tickets and the business databases. That is where a good share of the answers actually sit.

Why does knowledge management matter for a company?

The volume of documents matters little. What triggers the subject is knowledge concentrated in the two or three people everyone turns to. The other signals: onboarding that runs past three months, an announced departure on a key role, three or four competing sources of truth, mistakes that keep coming back because someone worked from an outdated version. The cost is paid in interruptions and delays, rarely in invoices, and stays invisible for a long time as a result.

Does AI replace knowledge management?

No. It moves where the effort is paid. It clearly improves "retrieving" and "reusing", and makes an imperfect base usable where a classic engine required a clean one. It does nothing for "capturing": knowledge that was never written down stays out of reach. Access rights, arbitrating contradictions and the hosting choice remain human decisions.

Conclusion

Knowledge management initiatives of the last twenty years were not absurd. They were right about the intent and wrong about the method: they demanded upfront filing effort from people who got no benefit from it, to feed a system that was more expensive to consult than a message to a colleague.

What AI changes is not the ability to store, which was never the problem. It is where the effort gets paid.

If the project takes the shape of an assistant your teams can query, our guide to the internal company chatbot covers the use cases that pay off, the classic pitfalls and the conditions for success.

If you recognize your company in the first scene of this article, the subject is ripe: book a demo, we will start from your real sources.