Interne Wissensdatenbank aufbauen: Leitfaden mit KI-Suche
Aktualisiert: · Veröffentlicht:
Eine interne Wissensdatenbank macht das Wissen eines Unternehmens — Arbeitsanweisungen, Richtlinien, Produktdaten, gelöste Fälle — für die eigenen Mitarbeiter auffindbar. Die meisten solcher Datenbanken scheitern nicht an der Software, sondern daran, dass niemand sie pflegt: Wissen wird einmal eingetragen, veraltet und verliert damit das Vertrauen der Nutzer. Eine KI-gestützte Suche ändert daran genau eine Sache — sie nutzt die Dokumente, die ohnehin entstehen, statt auf einer zusätzlich zu pflegenden Sammlung. Was sie nicht ändert: Wenn Wissen nirgends aufgeschrieben ist, findet es auch die beste Suche nicht.
Was ist eine interne Wissensdatenbank?
Eine interne Wissensdatenbank macht das Wissen eines Unternehmens für die eigenen Mitarbeiter auffindbar: Arbeitsanweisungen, Richtlinien, Produkt- und Preisdaten, Vertragsmuster, gelöste Kundenfälle, Einarbeitungsunterlagen. Anders als ein Helpcenter für Kunden ist sie nicht öffentlich, und anders als eine Dateiablage soll sie Antworten liefern, nicht nur Dateien.
Dahinter stehen zwei grundverschiedene Bauarten. Die klassische ist eine gepflegte Sammlung — ein Wiki, in das jemand das Wissen einträgt. Die neuere ist eine Suche über den Bestand: Sie nutzt die Dokumente, die ohnehin entstehen, und beantwortet Fragen mit Verweis auf die Fundstelle. Welche Bauart passt, entscheidet sich weniger an der Technik als an der Frage, wer die Pflege übernimmt.
Drei Wege im Vergleich
Zwischen beiden Bauarten liegt ein dritter Weg: die KI-Funktion, die ein vorhandenes Werkzeug bereits mitbringt.
| Gepflegtes Wiki | KI-Funktion im vorhandenen Werkzeug | KI-Suche über den gesamten Bestand | |
|---|---|---|---|
| Wo das Wissen liegt | in Artikeln, die jemand schreibt | im jeweiligen Produkt, etwa Wiki oder Office-Paket | in den vorhandenen Ablagen: Laufwerk, SharePoint, DMS, Wiki, Tickets |
| Pflegeaufwand | hoch, dauerhaft | wie beim Werkzeug selbst | gering: gepflegt wird das Dokument, nicht eine Kopie |
| Reichweite | nur das, was eingetragen wurde | meist nur die Daten dieses Produkts | alle angebundenen Quellen |
| Quellenangabe | der Artikel selbst | je nach Produkt | Dokument, Absatz und Stand |
| Zugriffsrechte | eigene Rechteverwaltung | aus dem Produkt | aus den Quellsystemen übernommen |
| Verarbeitungsort und Vertrag | beim Wiki-Anbieter oder im eigenen Haus | beim Anbieter des Werkzeugs, je nach Tarif | im Projekt festgelegt, etwa im EWR oder im eigenen Haus |
| Kosten | Lizenz je Nutzer | Lizenz je Nutzer, oft als Aufpreis zur Grundlizenz | Einführungsprojekt, danach Betrieb |
Die Wege schließen einander nicht aus. Häufig bleibt das Wiki für das, was wirklich nur dort steht — Einarbeitung, Ansprechpartner, Abläufe —, und die Suche übernimmt den Bestand, den nie jemand ins Wiki übertragen hat. Wer ohnehin ein Werkzeug mit eingebauter KI-Funktion nutzt, sollte zuerst prüfen, ob dessen Reichweite genügt: Durchsucht es nur seine eigenen Inhalte, bleiben Laufwerk und DMS außen vor.
Was gehört in eine interne Wissensdatenbank?
Was mehrmals im Monat gefragt wird und eine belegbare Antwort hat:
- Arbeits- und Prüfanweisungen, Verfahrensanweisungen, Checklisten
- Richtlinien: Reisen, Einkauf, IT, Datenschutz, KI-Nutzung
- Produktdaten, Preislisten, technische Datenblätter, Handbücher
- Vertragsmuster und freigegebene Klauseln
- gelöste Fälle aus Kundenservice und Reklamationen
- Einarbeitungsunterlagen und Zuständigkeiten
Nicht hinein gehören Personalakten und Gesundheitsdaten, ebenso wenig alles, was nur ein kleiner Kreis sehen darf, solange die Rechte dafür nicht sauber abgebildet sind. Bei einer Suche über den Bestand ist das keine Frage der Auswahl, sondern der Rechte: Was ein Mitarbeiter im Quellsystem nicht öffnen darf, bekommt er auch nicht als Antwort — sofern die Rechte dort stimmen.
Warum veralten klassische Wissensdatenbanken?
Nicht wegen schlechter Software. Der Mechanismus ist immer derselbe und hat mit Technik nichts zu tun.
Eine Wissensdatenbank verlangt doppelte Arbeit: Das Wissen entsteht ohnehin — in Handbüchern, Protokollen, Mails, Tickets, Verträgen — und muss zusätzlich in die Datenbank übertragen werden. Diese zweite Arbeit hat keinen unmittelbaren Nutzen für den, der sie leistet, und wird deshalb als Erstes weggelassen, sobald es eng wird.
Nach einigen Monaten enthält die Sammlung veraltete Einträge. Ein Nutzer findet einen davon, merkt es, und benutzt die Datenbank fortan nicht mehr — nicht weil sie leer wäre, sondern weil er ihr nicht mehr traut. Ab da beschleunigt sich der Verfall: Weniger Nutzung bedeutet weniger Pflege bedeutet weniger Vertrauen.
Was ändert eine KI-Suche daran?
Genau eine Sache, und sie ist entscheidend: Sie nutzt die Dokumente, die ohnehin entstehen, statt auf einer zusätzlich zu pflegenden Sammlung. Die doppelte Arbeit entfällt, und damit der Mechanismus, der die Datenbank hat veralten lassen.
Praktisch heißt das: angebunden werden Dateiablagen, SharePoint, DMS, Confluence, Ticketsysteme, Postfächer. Die bestehende Ordnerstruktur bleibt, nichts muss umsortiert werden. Wer ein Dokument aktualisiert, aktualisiert damit die Antwort — ohne einen zweiten Arbeitsschritt.
Der zweite Unterschied: Gefragt wird nach Sachverhalt statt Stichwort. Die Volltextsuche findet Wörter, die man bereits kennt; wer die Formulierung von damals nicht kennt, findet nichts, obwohl das Dokument da ist.
Was sie nicht ändert
Drei Dinge, und sie zu verschweigen wäre unredlich.
Wissen, das nirgends steht, bleibt unauffindbar. Keine Suche findet, was nicht dokumentiert ist. Wenn die Antwort ausschließlich im Kopf einer Person existiert, ist Dokumentation der erste Schritt — und den nimmt keine Software ab.
Ungeklärte Zugriffsrechte werden sichtbar, nicht gelöst. Eine Suche über den Gesamtbestand führt sofort vor, wo Berechtigungen nie sauber gesetzt wurden. Das ist nützlich, aber es ist Arbeit, die vorher niemand eingeplant hat.
Widersprüchliche Dokumente bleiben widersprüchlich. Liegen zwei Fassungen mit unterschiedlichen Aussagen im Bestand, kann ein System beide zeigen und den Stand nennen — entscheiden, welche gilt, muss ein Mensch.
Woran scheitern solche Projekte?
An der Zerlegung der Dokumente. Werden sie stur nach Zeichenzahl geschnitten, zerreißen Tabellen und Absätze, und die Suche findet Bruchstücke ohne Zusammenhang. Bei enttäuschenden Trefferquoten lohnt der Blick zuerst hierher, nicht auf das Modell.
An der Versionierung. In gewachsenen Beständen liegen fast immer mehrere Fassungen desselben Dokuments: das Original, eine hausintern ergänzte Version, eine Kopie im Projektordner. Ohne Behandlung dieser Fälle erscheint eine überholte Fassung als aktuelle Antwort — der gefährlichste stille Fehler, weil er nicht wie ein Fehler aussieht.
An fehlender Abnahme. Ohne eine Person, die verbindlich sagt „diese Antwort ist gut genug“, läuft die Rückmeldeschleife endlos weiter. Diese Rolle lässt sich nicht an den Dienstleister abgeben: Ob eine Auskunft im eigenen Haus brauchbar ist, weiß nur, wer die Arbeit kennt.
Wissensdatenbank mit KI aufbauen: fünf Schritte
1. Bestand abgrenzen und echte Fragen sammeln. Begonnen wird mit einem überschaubaren Ausschnitt statt mit dem gesamten Laufwerk und mit echten Fragen statt mit Demofragen. Was Sie dafür brauchen: zwanzig Fragen, die in der letzten Woche tatsächlich jemand gestellt hat, und die Unterlagen, in denen die Antworten stehen sollten.
2. Ausgangslage messen. Gemessen werden drei Größen, und zwar vor dem Start: Suchzeit pro Anfrage, Zahl der Rückfragen an Kollegen, Anteil der Fragen mit belegter Antwort. Ohne Ausgangsmessung endet die Bewertung in einer Diskussion über Eindrücke — der häufigste Grund, warum funktionierende Systeme nicht verlängert werden.
Die Erhebung selbst kostet wenig: eine Woche lang notieren, wie oft gesucht wurde und wie lange es gedauert hat. Genau dieser Schritt wird am häufigsten übersprungen, weil er vor dem eigentlichen Projekt liegt und niemandem gehört.
3. Quellen anbinden — mit den bestehenden Rechten. Zuerst die zwei oder drei Ablagen, in denen die Antworten auf die gesammelten Fragen tatsächlich liegen, nicht alle auf einmal. Die Berechtigungen werden aus den Quellsystemen übernommen; wo sie nie sauber gesetzt wurden, zeigt sich das hier.
4. Pilot mit Abnahme. Zwei bis vier Wochen mit einer Gruppe, die die Fragen wirklich stellt, und einer Person, die verbindlich sagt, ob eine Antwort gut genug ist. Maßstab ist die Ausgangslage aus Schritt 2; gezählt wird auch, wie oft eine überholte Fassung als Antwort ausgegeben wurde.
5. Lücken schließen und Pflege regeln. Aus dem Pilot entsteht die Liste der Fragen ohne belegte Antwort. Wer welche Lücke schließt und wer bei widersprüchlichen Fassungen entscheidet, wird vor dem Regelbetrieb festgelegt, nicht danach.
Datenschutz und Mitbestimmung
Eine Suche über interne Dokumente verarbeitet fast immer personenbezogene Daten — Namen in Protokollen, Verteilern, Tickets. Läuft sie bei einem externen Anbieter, braucht es einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, und der Verarbeitungsort gehört in den Vertrag, nicht nur auf die Produktseite. Worauf es dabei ankommt, steht unter RAG DSGVO-konform mit eigenen Dokumenten.
Weil ein solches System technisch protokollieren kann, wer was gefragt hat, sollte ein vorhandener Betriebsrat früh eingebunden werden — wie die Mitbestimmung in Deutschland und Österreich abläuft, beschreibt KI-Einführung und Betriebsrat.
Was kostet eine KI-Wissensdatenbank?
Die Rechnung hängt von der Bauart ab. Wiki und eingebaute KI-Funktionen werden je Nutzer lizenziert; die Kosten wachsen mit der Belegschaft. Eine KI-Suche über den Bestand ist ein Einführungsprojekt: bei uns ein Discovery ab 5.000 €, dann das Projekt ab 25.000 €; danach fallen Kosten für Betrieb und Rechenleistung an — ohne Preis je Nutzer.
Ob sich das rechnet, lässt sich mit einer einfachen Modellrechnung abschätzen; die Annahmen ersetzen Sie durch Ihre Messung aus Schritt 2. Angenommen, 80 Mitarbeiter suchen täglich je 15 Minuten nach Informationen, die im Bestand stehen: Das sind 1.200 Minuten, also 20 Stunden am Tag. Halbiert die Suche diesen Aufwand, werden 10 Stunden am Tag frei, bei 220 Arbeitstagen 2.200 Stunden im Jahr. Nicht eingerechnet sind Rückfragen an Kollegen, die dabei seltener werden, und der Aufwand für die Pflege, der im Pilot gemessen wird.
Der unbequeme Nebenertrag
Die dritte Größe aus Schritt 2, der Anteil der Fragen mit belegter Antwort, ist die ehrlichste. Fragen ohne belegte Antwort sind kein Versagen des Systems, sondern eine Bestandsaufnahme des eigenen Wissens: Sie zeigen, wo der Betrieb von einzelnen Personen abhängt.
Diese Liste rechtfertigt für sich genommen oft schon den Pilot, selbst wenn das System danach nicht eingeführt wird. Für die meisten Unternehmen ist sie die einzige belastbare Übersicht dieser Art, die je entstanden ist.
Der Umgang damit ist eine Führungsfrage, keine technische: Die Lücken zeigen, wo Dokumentation fehlt, und das trifft fast immer Bereiche, in denen erfahrene Mitarbeiter seit Jahren improvisieren. Wer diese Liste als Vorwurf präsentiert, bekommt sie beim nächsten Mal nicht wieder.
Wie die Suche im Detail funktioniert, steht unter Dokumente durchsuchen; die Begriffe dazu im Glossar unter Wissensdatenbank, RAG und Embedding.
Liegt der Bestand in SharePoint, Confluence oder einem Dokumentenmanagement-System, ist die Anbindung an diese Quellen der praktische Einstieg — einschließlich der Frage, wie dabei die bestehenden Berechtigungen erhalten bleiben: KI-Suche über SharePoint, Confluence und DMS.