Interner Wissenschatbot: Welche Voraussetzungen braucht ein Unternehmen?

Was ein interner Wissenschatbot leistet – und was nicht

Ein interner Wissenschatbot nimmt Fragen in natürlicher Sprache entgegen und beantwortet sie auf Basis freigegebener Unternehmensinformationen. Häufig wird dafür Retrieval-Augmented Generation, kurz RAG, eingesetzt: Eine Suche ermittelt relevante Inhalte, diese werden dem Sprachmodell als Kontext bereitgestellt und das Modell formuliert daraus eine Antwort.

Microsoft beschreibt RAG als Zusammenspiel aus Abruf, Ergänzung des Modellkontexts und Antwortgenerierung. Der Ansatz eignet sich besonders für private oder häufig aktualisierte Informationen. Er macht aus ungeordneten Dokumenten jedoch nicht automatisch eine verlässliche Wissensbasis. Wenn die Suche unpassende oder unvollständige Passagen liefert, kann auch die erzeugte Antwort unvollständig oder falsch sein.

Ein Wissenschatbot sollte deshalb nicht mit einem autonomen Agenten gleichgesetzt werden. Ein Chatbot kann ausschließlich recherchieren und antworten. Erst wenn das System selbst weitere Werkzeuge auswählt oder Aktionen ausführt, entsteht ein agentischerer Ablauf. Die Entscheidungshilfe KI-Agent oder klassische Automatisierung grenzt diese Stufen genauer ab.

Quellen zu diesem Abschnitt: Microsoft Foundry: RAG und Indizes

Voraussetzung 1: Fragebereich und Verantwortung eingrenzen

„Unser gesamtes Unternehmenswissen durchsuchbar machen“ ist kein ausreichend begrenzter erster Anwendungsfall. Präziser wäre: „Servicetechniker sollen freigegebene Wartungsanweisungen für zwei Produktreihen finden und die verwendeten Quellen öffnen können.“ Damit werden Zielgruppe, Inhalt, Aufgabe und Abnahme greifbar.

Benennen Sie einen fachlichen Eigentümer. Diese Person oder Rolle entscheidet, welche Quellen verbindlich sind, welche Antwortgrenzen gelten und wer fachliche Fehler bewertet. Die IT kann Verfügbarkeit und Sicherheit verantworten, aber nicht allein festlegen, ob eine veraltete Arbeitsanweisung noch gültig ist.

Definieren Sie auch, was der Chatbot ausdrücklich nicht beantworten soll. Individuelle Rechtsauskünfte, Personalentscheidungen, verbindliche Preise oder sicherheitskritische Handlungsanweisungen können je nach Kontext ausgeschlossen oder an zuständige Stellen übergeben werden. Eine klare Nichtzuständigkeit ist eine Systemanforderung, kein nachträglicher Warnhinweis.

Voraussetzung 2: Verbindliche und pflegbare Quellen

Erstellen Sie vor dem Index eine Quellenliste. Für jede Quelle sollten Zweck, Eigentümer, Speicherort, Zielgruppe, Gültigkeitsstatus und Aktualisierungsweg bekannt sein. Mehr Dateien erhöhen nicht automatisch die Qualität. Widersprüchliche Versionen, eingescannte Dokumente ohne brauchbaren Text oder Präsentationen mit fehlendem Kontext erschweren die Suche.

Kennzeichnen Sie die maßgebliche Fassung. Wenn dieselbe Regel in einem Handbuch, einer E-Mail und einer alten Schulungsfolie unterschiedlich beschrieben wird, braucht der Chatbot eine Priorität oder die Quelle muss vor der Aufnahme bereinigt werden. Sonst kann er eine sprachlich überzeugende Antwort aus dem falschen Dokument erzeugen.

Planen Sie Löschung und Aktualisierung mit. OpenAI weist bei Vektorspeichern darauf hin, dass das Entfernen von Dateien vorübergehend eventual consistent sein kann. Unabhängig vom Anbieter muss daher geprüft werden, wann eine geänderte oder zurückgezogene Quelle tatsächlich nicht mehr auffindbar ist.

Quellen zu diesem Abschnitt: OpenAI: Retrieval und Vektorspeicher

Voraussetzung 3: Berechtigungen bis zur einzelnen Quelle

Der Chatbot darf keine Berechtigungsgrenze aufheben. Wenn ein Mitarbeiter ein Dokument im Quellsystem nicht lesen darf, sollte es auch nicht über Suche, Antworttext oder Quellenzitat sichtbar werden. Ein gemeinsamer Index ohne nutzerbezogene Filter kann sonst Informationen aus Personal, Finanzen oder vertraulichen Projekten vermischen.

Microsoft dokumentiert dafür unter anderem Sicherheitsfilter und dokumentbezogene Zugriffskontrollen. Bei Sicherheitsfiltern werden Benutzer- oder Gruppenkennungen mit den Berechtigungsinformationen der Dokumente verglichen und unzulässige Treffer vor der Antwort ausgeschlossen. Welche technische Variante passt, hängt vom Quellsystem und Identitätsmodell ab.

Prüfen Sie nicht nur Standardkonten. Testen Sie Mitarbeitende mit mehreren Rollen, neue und ausgeschiedene Gruppenmitglieder sowie Dokumente, deren Freigabe nachträglich geändert wurde. Vorschaufunktionen sollten dabei nicht stillschweigend wie produktionsreife, vertraglich abgesicherte Funktionen behandelt werden.

Quellen zu diesem Abschnitt: Microsoft: Dokumentbezogene Zugriffskontrolle

Voraussetzung 4: Dokumentaufbereitung und Suchlogik

Für die Suche werden Dokumente meist in kleinere Abschnitte zerlegt, mit Metadaten versehen und indexiert. Zu kleine Abschnitte verlieren Zusammenhang; zu große Abschnitte enthalten viel irrelevanten Text. Überschriften, Produkt, Sprache, Version und Gültigkeitsdatum können als Metadaten helfen, Treffer einzugrenzen und Quellen verständlich anzuzeigen.

OpenAI File Search ist ein Beispiel für einen verwalteten Dienst, der Dateien in Vektorspeichern über semantische und Stichwortsuche durchsucht. Microsoft nennt ebenfalls Stichwort-, Vektor-, semantische und hybride Suche. Diese Produktdokumentationen zeigen mögliche Bausteine, sind aber keine pauschale Produktempfehlung für jedes Unternehmen.

Die Suchqualität muss mit den tatsächlichen Fragen geprüft werden. Ein Treffer kann thematisch ähnlich sein und dennoch die falsche Produktgeneration oder eine ungültige Prozessversion betreffen. Filter, Rangfolge und Metadaten sind deshalb Teil der fachlichen Lösung, nicht nur technische Optimierung.

Quellen zu diesem Abschnitt: OpenAI: File Search · Microsoft Foundry: Such- und RAG-Bausteine

Voraussetzung 5: Antwortregeln, Quellen und Unsicherheit

Legen Sie fest, wie eine belegte Antwort aussieht. Ein sinnvoller Mindeststandard kann verlangen, dass der Chatbot die verwendeten Dokumente verlinkt, Gültigkeitsdatum oder Version sichtbar macht und keine Aussage ergänzt, die in den Treffern nicht gedeckt ist. Nutzer müssen die Originalquelle öffnen können.

Ebenso wichtig ist die Antwort bei fehlender Grundlage. Der Chatbot sollte sagen können, dass in den freigegebenen Quellen keine ausreichende Antwort gefunden wurde. Eine erfundene Ergänzung ist nicht hilfreicher als eine offene Lücke. Für wichtige Fälle braucht es einen benannten Ansprechpartner oder einen bestehenden Eskalationsweg.

Behandeln Sie abgerufene Dokumentinhalte als potenziell unvertrauenswürdige Eingabe. Microsoft weist darauf hin, dass Anwendungslogik und Systemanweisung das Risiko von Prompt Injection aus Dokumenten und Textpassagen begrenzen sollten. Inhalte aus einer Datei dürfen die übergeordneten Regeln des Systems nicht beliebig umschreiben.

Quellen zu diesem Abschnitt: Microsoft Foundry: Sicherheit und Datenschutz bei RAG

Fiktives Beispiel: Wartungswissen für zwei Produktreihen

Das folgende Unternehmen, seine Dokumente und alle Entscheidungen sind vollständig fiktiv. Es handelt sich weder um ein Kundenprojekt noch um gemessene BonusAI-Ergebnisse. Ein Hersteller möchte Servicetechnikern Wartungsanweisungen für zwei Produktreihen zugänglich machen. Im Ablageordner liegen freigegebene Handbücher, alte Präsentationen und einzelne Notizen aus Projekten.

Für den Pilot werden nur freigegebene Handbücher und aktuelle Servicebulletins aufgenommen. Jedes Dokument erhält Produktreihe, Sprache, Versionsstand, Gültigkeitsdatum und fachlichen Eigentümer. Projektordner und allgemeine E-Mails bleiben zunächst ausgeschlossen. Der Chatbot darf Antworten formulieren und Quellen verlinken, aber keine Ersatzteile bestellen oder Wartungsfreigaben erteilen.

Eine bewusst unbeantwortbare Testfrage lautet: „Welche Kulanz dürfen wir diesem Kunden zusagen?“ Da die Wissensbasis keine freigegebenen Kulanzregeln enthält, muss der Chatbot die Grenze nennen und an die zuständige Stelle verweisen. Eine plausible Prozentzahl wäre ein schwerer Fehler, auch wenn andere Wartungsfragen korrekt beantwortet werden.

Andere Inhalte, Rollen und Auswirkungen erfordern andere Grenzen. Das Beispiel zeigt eine Vorgehensweise, keine fertige Zielarchitektur.

Voraussetzung 6: Ein Testset vor dem Pilotbetrieb

Sammeln Sie typische Fragen aus dem Arbeitsalltag und ergänzen Sie schwierige Varianten: mehrdeutige Begriffe, veraltete Produktnamen, fehlende Angaben, widersprüchliche Quellen und Fragen außerhalb des vereinbarten Bereichs. Für jede Frage wird vorab festgehalten, welche Quellen zulässig sind und welche Kernaussagen eine akzeptable Antwort enthalten muss.

Bewerten Sie Suche und Antwort getrennt. Hat die Suche die maßgebliche Passage gefunden? Ist die formulierte Aussage durch diese Passage gedeckt? Verweist das Zitat wirklich auf die verwendete Stelle? Bleibt eine nicht beantwortbare Frage offen? Sieht ein Nutzer nur Inhalte, für die er berechtigt ist? Diese Trennung zeigt, ob ein Fehler aus der Wissensbasis, der Suche oder der Antwortgenerierung stammt.

NIST empfiehlt für generative KI unter anderem, Zweck, Annahmen, Grenzen, Datenherkunft, Datenqualität, RAG-Ansatz und Evaluationsdaten zu dokumentieren. Ein Pilot sollte daher nicht nur Treffer zeigen, sondern nachvollziehbare Testfälle, Ergebnisse, Fehlermuster und Entscheidungen hinterlassen.

• Beantwortbare Fragen mit eindeutiger freigegebener Quelle
• Fragen mit mehreren relevanten Dokumenten oder widersprüchlichen Versionen
• Unbeantwortbare und ausdrücklich ausgeschlossene Fragen
• Berechtigungstests für unterschiedliche Rollen und Gruppen
• Änderungs- und Löschtests für aktualisierte Quellen
• Prüfung von Antwort, Zitat, tatsächlicher Quelle und Systemprotokoll

Quellen zu diesem Abschnitt: NIST: Generative AI Profile

Voraussetzung 7: Betrieb, Pflege und Rückmeldung

Ein Wissenschatbot ist nach dem ersten Import nicht fertig. Dokumente ändern sich, Berechtigungen wechseln und Nutzer stellen Fragen, die im Testset nicht vorkamen. Definieren Sie, wie schnell Änderungen übernommen werden, wer fehlende Quellen ergänzt und wie problematische Antworten gemeldet werden.

Monitoring sollte fachliche und technische Signale verbinden: Suchanfragen ohne brauchbaren Treffer, häufig geöffnete Quellen, abgebrochene Antworten, Berechtigungsfehler, Laufzeit und Rückmeldungen. Reine Nutzungszahlen zeigen nicht, ob Antworten richtig oder hilfreich waren.

Planen Sie außerdem einen Rückfallweg. Wenn Suche, Modell oder Identitätsprüfung nicht verfügbar sind, sollte das System keine unbelegte Antwort ausgeben. Abhängig vom Anwendungsfall kann es stattdessen auf die manuelle Suche, eine FAQ-Seite oder den zuständigen Ansprechpartner verweisen.

Readiness-Checkliste: Bauen, vorbereiten oder stoppen?

Bewerten Sie jedes Feld mit „geklärt“, „offen“ oder „nicht erfüllt“. Offene Punkte erhalten einen Verantwortlichen und einen Termin. Ein technisch möglicher Prototyp ist noch kein geeigneter Pilot, wenn Quellen oder Berechtigungen ungeklärt bleiben.

Sind Quellenqualität oder Zugriffsschutz nicht ausreichend, sollte der Pilot vorbereitet statt vorschnell veröffentlicht werden. Eine kleinere, saubere Wissensbasis ist für die erste Lernrunde oft aussagekräftiger als ein ungeprüfter Vollimport.

Der hilfreiche nächste Schritt: eine Quellen- und Fragenprobe

Wählen Sie einen eng begrenzten Wissensbereich und sammeln Sie einige reale, anonymisierte oder fiktiv nachgebildete Fragen. Ordnen Sie jeder Frage die maßgebliche Quelle, zulässige Nutzergruppe und erwartete Kernaussage zu. Bereits diese Probe zeigt, ob Wissen tatsächlich dokumentiert, aktuell und eindeutig genug ist.

Der Leitfaden KI-Use-Cases finden und priorisieren hilft bei der Auswahl des passenden ersten Anwendungsfalls. Wenn Architektur, Berechtigungen und Pilotkriterien gemeinsam geklärt werden sollen, unterstützt eine KI-Strategie-Beratung. Für Teams, die Retrieval und Agenten praktisch verstehen möchten, ist der KI-Agenten-Workshop der passende Lernrahmen.