Einen internen Wissens-Chatbot bauen.
In jedem gewachsenen Unternehmen steckt Wissen in verstreuten Dokumenten — Handbüchern, Wikis, Richtlinien, alten E-Mails, Präsentationen. Die richtige Information zu finden, kostet Mitarbeiter täglich Zeit und Nerven. Ein interner Wissens-Chatbot verspricht, diese Frage-Antwort-Lücke zu schließen: Man fragt in normaler Sprache, das System antwortet aus den eigenen Unterlagen. Damit das funktioniert und nicht zur Fehlerquelle wird, braucht es mehr als ein Sprachmodell — es braucht eine saubere Architektur mit belegten Quellen und klaren Berechtigungen.
Warum ein reines Sprachmodell nicht reicht.
Die naheliegende Idee — einfach ein großes Sprachmodell fragen — scheitert an zwei Dingen. Erstens kennt ein allgemeines Modell die internen Dokumente eines Unternehmens nicht; es wurde auf öffentlichen Texten trainiert, nicht auf Ihrem Qualitätshandbuch. Zweitens neigt ein Modell, das eine Antwort nicht kennt, dazu, sie plausibel zu erfinden. Bei internem Wissen ist das fatal: Eine falsch erfundene Urlaubsregelung oder Sicherheitsvorschrift kann echten Schaden anrichten.
Die Lösung heißt RAG — Retrieval-Augmented Generation. Das Prinzip ist einfach: Bevor das Modell antwortet, sucht das System in den echten Firmendokumenten nach passenden Textstellen und gibt sie dem Modell als Grundlage mit. Das Modell formuliert dann eine Antwort ausschließlich auf Basis dieser gefundenen Stellen — und nennt sie als Quelle. So antwortet es nicht aus seinem allgemeinen Training, sondern aus Ihren Unterlagen, und die Antwort lässt sich nachprüfen.
Wie RAG im Kern funktioniert.
Ein RAG-System besteht aus zwei Phasen, die man auseinanderhalten sollte. Die erste läuft einmalig im Voraus, die zweite bei jeder Frage:
- Aufbereitung (einmalig): Alle Dokumente werden in handliche Abschnitte zerlegt. Jeder Abschnitt wird in eine mathematische Repräsentation (ein „Embedding“) übersetzt, die seinen Inhalt erfasst, und in einer durchsuchbaren Datenbank abgelegt.
- Suche & Antwort (pro Frage): Die Frage des Nutzers wird ebenfalls in ein Embedding übersetzt. Das System findet die inhaltlich ähnlichsten Abschnitte, übergibt sie dem Sprachmodell und lässt es daraus eine Antwort mit Quellenangabe formulieren.
Der Clou ist die Suche über Bedeutung statt über exakte Wörter. Wer „Wie viele freie Tage habe ich?“ fragt, findet so auch einen Abschnitt über „Urlaubsanspruch“, obwohl kein Wort übereinstimmt. Diese semantische Suche ist der eigentliche Fortschritt gegenüber einer klassischen Stichwortsuche im Intranet.
Ein konkretes Antwort-Setup.
Der Antwortteil ist überschaubar: Man übergibt dem Modell die gefundenen Textstellen und die Frage und verlangt eine Antwort, die sich strikt an diese Stellen hält. Ein vereinfachtes Beispiel mit der Anthropic-API in Python, wobei die Suche bereits passende Abschnitte geliefert hat:
import anthropic
an = anthropic.Anthropic()
def beantworte(frage: str, abschnitte: list[dict]) -> str:
# abschnitte: [{"quelle": "...", "text": "..."}]
kontext = "\n\n".join(
f"[Quelle: {a['quelle']}]\n{a['text']}"
for a in abschnitte)
msg = an.messages.create(
model="claude-sonnet-4-5",
max_tokens=800,
system=(
"Du beantwortest Fragen AUSSCHLIESSLICH "
"anhand der gegebenen Quellen. Nenne zu "
"jeder Aussage die Quelle. Steht die "
"Antwort nicht in den Quellen, sage klar: "
"'Dazu finde ich keine Information in den "
"Unterlagen.' Erfinde NICHTS dazu."),
messages=[{"role": "user", "content":
f"Quellen:\n{kontext}\n\nFrage: {frage}"}])
return msg.content[0].text
Die wichtigste Zeile ist die Anweisung, bei fehlender Information ehrlich „keine Information in den Unterlagen“ zu antworten. Ein Wissens-Chatbot, der zugibt, etwas nicht zu wissen, ist unendlich viel wertvoller als einer, der Lücken mit erfundenen Antworten füllt. Diese Ehrlichkeit ist kein Makel, sondern das zentrale Qualitätsmerkmal — denn nur eine belegte, nachprüfbare Antwort ist im Unternehmenskontext brauchbar.
Quellenangaben sind nicht optional.
Ein interner Chatbot ohne Quellenangaben ist kaum besser als ein Orakel. Erst die Quellenangabe macht eine Antwort überprüfbar: Der Nutzer sieht, aus welchem Dokument die Auskunft stammt, und kann im Zweifel selbst nachlesen. Das ist besonders wichtig, weil auch ein gut gebautes RAG-System gelegentlich die falsche Textstelle findet oder eine Antwort ungenau formuliert.
Mit sichtbarer Quelle wird aus einer riskanten Behauptung ein nützlicher Verweis. Der Nutzer behandelt die Antwort dann richtigerweise als Wegweiser zur Quelle, nicht als letzte Wahrheit. Diese Haltung — „die KI zeigt mir die Stelle, ich prüfe bei wichtigen Dingen selbst“ — ist der gesunde Umgang mit einem Wissens-Chatbot und sollte aktiv gefördert werden, statt blindes Vertrauen zu erzeugen.
Berechtigungen: die unterschätzte Schwierigkeit.
Der heikelste Teil eines internen Chatbots ist nicht die KI, sondern die Frage, wer was sehen darf. Firmendokumente haben Zugriffsrechte: Die Gehaltsliste ist nicht für alle, die Vertragsentwürfe nicht für jeden. Ein Chatbot, der einfach alle Dokumente durchsucht, könnte einem Mitarbeiter Informationen liefern, die er gar nicht sehen dürfte — ein ernsthaftes Sicherheits- und Datenschutzproblem.
Die Berechtigungen müssen deshalb schon in der Suche greifen, nicht erst in der Antwort. Das System darf für einen Nutzer nur in den Dokumenten suchen, für die er Zugriff hat. Eine naive Umsetzung, bei der erst gesucht und dann gefiltert wird, ist gefährlich, weil die KI den verbotenen Inhalt bereits gesehen hat. Folgende Übersicht zeigt typische Fallstricke:
| Aspekt | Worauf zu achten ist |
|---|---|
| Zugriffsrechte | Schon bei der Suche filtern, nicht erst die Antwort beschneiden |
| Sensible Dokumente | Gehalts-, Personal-, Vertragsdaten ggf. ganz ausschließen |
| Veraltete Versionen | Alte Dokumentstände aussortieren, sonst widersprüchliche Antworten |
| Quellen-Transparenz | Jede Antwort mit nachprüfbarer Herkunft versehen |
| Protokollierung | Nachvollziehbar halten, wer was gefragt und gesehen hat |
Datenschutz und Betrieb.
Ein interner Wissens-Chatbot verarbeitet potenziell den gesamten Dokumentenbestand eines Unternehmens — darunter personenbezogene Daten und Geschäftsgeheimnisse. Wenn diese Inhalte über eine Cloud-API laufen, braucht es einen Auftragsverarbeitungsvertrag mit dem Anbieter, Klarheit über den Datenstandort und eine saubere Rechtsgrundlage nach DSGVO. Gerade weil hier sehr viel sensibler Inhalt zusammenkommt, ist die Frage des Modellbetriebs zentral.
Für besonders schützenswerte Bestände kann ein lokal oder in einer kontrollierten Umgebung betriebenes Modell die sauberere Wahl sein — auf Kosten von Setup-Aufwand und ggf. Antwortqualität. Diese Abwägung gehört an den Anfang des Projekts. Ebenso wichtig: Die Aufbereitung der Dokumente muss regelmäßig aktualisiert werden, damit der Chatbot nicht veraltetes Wissen ausgibt. Dies ist keine Rechtsberatung; die Ausgestaltung gehört mit Datenschutzbeauftragten und IT-Sicherheit abgestimmt.
Wo die Grenzen liegen.
Bei aller Nützlichkeit sollte man ehrlich über die Grenzen sprechen. Ein Wissens-Chatbot ist nur so gut wie die Dokumente, die er durchsucht. Sind die Unterlagen unvollständig, widersprüchlich oder veraltet, erbt der Chatbot diese Schwächen — er kann kein Wissen erzeugen, das nirgends steht. Die Qualität der Antworten steht und fällt mit der Pflege der zugrundeliegenden Quellen.
Außerdem ist die semantische Suche nicht perfekt. Sie findet meist die richtigen Stellen, aber manchmal auch eine knapp danebenliegende. Bei komplexen Fragen, die Informationen aus vielen Dokumenten verbinden müssen, stößt das Verfahren an Grenzen. Und schließlich darf ein Chatbot bei rechtlich, medizinisch oder sicherheitskritisch heiklen Auskünften nicht das letzte Wort haben — hier muss klar sein, dass die Antwort ein Hinweis ist und die verbindliche Klärung beim zuständigen Menschen liegt.
Schrittweise einführen.
Der bewährte Weg ist auch hier der schrittweise. Wer von Tag eins an den gesamten Dokumentenbestand für alle Mitarbeiter öffnet, riskiert beim ersten falschen oder unbefugten Treffer das Vertrauen. Besser:
- Ein abgegrenzter Wissensbereich zuerst: Mit einem klar umrissenen, unkritischen Themenfeld starten — etwa der internen FAQ oder dem Onboarding-Handbuch. Keine sensiblen Daten, überschaubarer Umfang.
- Quellenpflicht von Anfang an: Jede Antwort zeigt ihre Quelle. So lernen die Nutzer von Beginn an, Antworten zu prüfen statt blind zu vertrauen.
- Qualität messen: Stichproben zeigen, wie oft die Antwort korrekt und belegt ist und wie oft das System ehrlich „weiß ich nicht“ sagt. Diese Quoten steuern das weitere Vorgehen.
- Behutsam ausweiten: Erst bei stabiler Qualität und sauber gelösten Berechtigungen weitere, auch sensiblere Bereiche aufnehmen.
Was ich aus der Praxis mitgebe.
- RAG statt rohes Modell. Antworten kommen aus den echten Dokumenten, nicht aus dem allgemeinen Training — sonst drohen erfundene Auskünfte.
- Quellen immer sichtbar. Nur eine belegte Antwort ist im Unternehmen brauchbar. Die Quelle macht aus einer Behauptung einen prüfbaren Verweis.
- Berechtigungen schon in der Suche. Filtern, bevor die KI etwas sieht — nicht erst die Antwort beschneiden. Das ist der heikelste Teil.
- "Weiß ich nicht" ist gut. Ein Chatbot, der Lücken zugibt, ist verlässlicher als einer, der sie mit Erfindungen füllt.
Sie wollen einen internen Wissens-Chatbot auf Ihren eigenen Dokumenten — mit belegten Quellen, sauberen Berechtigungen und Datenschutz? Unverbindlich anfragen — wir schauen uns Ihren Dokumentenbestand, Ihre Rechteverwaltung und einen sinnvollen Pilot-Bereich an.