AI knowledge management software: which solution fits which knowledge?

Most selection processes open with a feature list. AI chat, interfaces, permissions, automatic summaries. That is already too late.

Which class of software is even in scope gets decided earlier, by a single question: does the knowledge in question exist anywhere yet? If it sits in manuals, tickets, emails or process documents, a search or knowledge platform can open up those holdings. If it sits in routines, memories and unwritten decision rules, it has to come out of people's heads first.

Five of the six classes below assume the knowledge is already documented. One does not.

Skip that distinction and you buy a system that misses your actual problem. A tool that searches existing documents brilliantly cannot produce knowledge nobody ever wrote down.

A wiki gives everyone a shared surface for writing, organising and updating. Confluence, Notion, SharePoint wikis, Slite, lexiCan. This works well as long as your people can articulate their knowledge themselves and actually maintain the pages: internal handbooks, project knowledge, onboarding, the questions that keep coming back.

The moment the decisive knowledge was never written down, it stops helping. A wiki is a container. It solves the filing problem, not the elicitation problem. hAiner is no substitute for one.

This is about controlled information: versions, approvals, validity periods, responsibilities, audits, traceable changes. ELO, WissIntra, Q.wiki, OpenKM, SharePoint environments set up accordingly.

If you have to govern work instructions, standards documents or quality-relevant records bindingly, you need a system like this. The pressure usually comes from outside, through ISO 9001, ISO 27001 or customer audits.

What these systems do not answer: why a process looks the way it does. The reasoning almost never appears in the approved document. hAiner replaces neither DMS nor QMS, and formal document control stays with the system of record.

This class connects what you already have and makes it reachable through search or plain questions. Documents, ticket systems, email, intranet, product data. Company-wide search solutions belong here, as do internally operated RAG assistants.

The typical case: there is plenty of material, scattered across systems and formats, and nobody knows where anything sits any more.

The limit is obvious. Search only finds what exists. An experience that never made it into a document, a ticket or a dataset stays invisible. This is exactly where this class parts ways with the last one.

What a system that genuinely reads content turns up in existing holdings is shown by this case from the petrochemical industry: for five products the attached data sheet belonged to a different product. Found with a single question put to the public website.

Skills platforms answer which capabilities are in the building, which roles need them and where gaps are opening. They are used by people development, workforce planning and recruiting, rarely by engineering.

A skills system shows you who has experience with a particular machine. It does not document how that person proceeds during a rare fault and why they settle on a particular step. For succession planning and training this is the right class. For handing over substance it is not.

Chatbots answer enquiries and automate dialogue across website, messenger or service channels, backed by a maintained knowledge base. Useful when frequent customer questions should be handled automatically and passed to a human when it matters.

Internal experiential knowledge is a different matter. A chatbot plays back answers that already exist. Handing over a plant supervisor's knowledge runs the other way round: experiences, exceptions and the reasoning behind decisions have to be elicited in the first place.

This class starts where no usable documentation exists. It helps to elicit cases, routines, exceptions and the decision rules of experienced staff in a structured way. Alone among the six, it does not assume the knowledge is already there.

hAiner holds conversations with key people for this: plant supervisors, shift leads, maintenance technicians, field staff. The questions target what appears in no manual. How do you spot the problem first? Which cause is likely, which one rather not? Which move has proven itself even though it is written down nowhere?

From the approved answers, a retrievable knowledge network takes shape, every statement with its source.

What that looks like in practice is in three field reports: why maintenance knowledge is usually there, just not where it is needed, what gets lost at shift change and only shows up later, and why the last year before retirement is not a year. In more depth on the topic pages securing experiential knowledge and knowledge transfer before retirement.

The features you need follow from the knowledge problem, not from a comparison table. For jointly written content, what counts is the editor, versioning and easy upkeep. For controlled documents, approvals, validity periods, auditability. For existing data holdings, connectors, permission inheritance, semantic search, source references.

With experiential knowledge, entirely different criteria apply. Does the system elicit knowledge in conversation instead of merely receiving it? Does it follow up when a procedure stays vague? Does it stay visible who a statement came from? Can the knowledge holder review and approve before anything circulates in the company? And are contradictions between two statements made visible or quietly resolved?

A long feature catalogue says little about that. A test with a real case from your own operation says everything.

Vendors like to merge these points into one sentence. Keep them apart: where does the application run? Where does the data sit permanently? Where does a language model process the individual request? And is customer data used for model training?

At hAiner, the application and permanent storage run on dedicated hardware at Hetzner in Germany. For processing by the language model we work with Mistral AI in Paris, so the data stays within the European Economic Area and does not go to the United States. Customer data is not used for model training, which is excluded contractually. Certification to ISO 27001 is in preparation and not yet in place.

On these four points most vendors publish nothing substantive. Ask about them specifically during selection and have the sub-processors named individually. What an honest disclosure looks like is in health data in an AI knowledge base, including the passages where the answer gets uncomfortable. More on the subject on the page GDPR-compliant AI for mid-sized companies.

Do not open with a general demo request. Start with a bounded case instead. One specific group of people, one knowledge source, one situation where the missing knowledge hurts.

1. Which decision or task should run faster or more safely afterwards?
2. Is the necessary knowledge already documented? Answered honestly.
3. Who creates, reviews and updates the content in daily operation?
4. Which existing systems have to be connected?
5. Which roles may see which information?
6. Which hosting and data protection requirements apply, and who has to agree? IT, the data protection officer, the works council.
7. How will you measure after a pilot whether the case is genuinely solved?

Usually four of the six classes drop out on those answers alone, before anyone writes a single proposal.

Knowledge management software can maintain content collaboratively, control documents, search existing data, map competencies, answer customer questions or elicit experiential knowledge. No system does all of that equally well.

Those who already document well usually need better search. Those who have to govern regulated processes need a document or management system. And those who have to secure knowledge before a key person leaves should first work out how that knowledge gets out of their head at all. hAiner is built for that last case.