Bildquelle: extern
Ein internes KI-Suchfeld wirkt harmlos, solange es nur Antworten aus vorhandenen Dokumenten zusammenfasst. Für den Betrieb beginnt die eigentliche Frage aber früher: Welche Informationen darf dieses System überhaupt finden, kombinieren und wieder ausgeben?
Interne KI-Suche meint Anwendungen, die Dokumente, Tickets, Wikis, Chats oder Wissensdatenbanken durchsuchen und daraus Antworten formulieren. Häufig steckt dahinter ein großes Sprachmodell, das nicht selbst alles weiß, sondern Inhalte aus Unternehmensquellen heranzieht. Für Nutzer klingt das nach einem besseren Suchfeld. Für IT Service Management und IT-Leitung ist es ein neuer Betriebsservice mit Zugriff auf Wissen, Rechte, Qualität und Haftungsrisiken.
Warum ein Suchfeld plötzlich Betriebsverantwortung auslöst
Der Reiz ist klar. Ein Mitarbeiter fragt nach einer Anleitung, einer Vertragsregel, einem bekannten Fehler oder einer Zuständigkeit und erhält sofort eine lesbare Antwort. Das spart Suchzeit und kann den Service Desk entlasten. Gleichzeitig verschiebt sich die Verantwortung. Früher musste ein Nutzer selbst erkennen, welches Dokument aktuell, freigegeben oder nur für eine bestimmte Gruppe gedacht war. Eine KI-Antwort wirkt dagegen oft wie eine fertige Aussage.
Genau deshalb reicht es nicht, interne KI nur als Produktivitätswerkzeug einzuführen. Sie wird zu einer Übersetzungsschicht zwischen vorhandenen Informationen und operativen Entscheidungen. Wenn diese Schicht falsche Quellen nutzt, veraltete Inhalte bevorzugt oder sensible Informationen aus mehreren harmlos wirkenden Fragmenten zusammensetzt, entsteht ein Problem, das weder klassischer Suchbetrieb noch reines Datenschutzprojekt sauber abdeckt.
Datenklassen müssen vor dem Training verständlich sein
Der wichtigste Startpunkt ist eine einfache Datenordnung. Nicht jede Information im Unternehmen braucht denselben Schutz. Öffentliche Produktinformationen, interne Prozessnotizen, Kundendaten, Sicherheitsdokumente, Personaldaten, Vertragsdetails und Störungsprotokolle gehören in unterschiedliche Klassen. Diese Klassen müssen so beschrieben sein, dass Fachbereiche, Service Desk und Plattformteam sie im Alltag anwenden können.
Für Generalisten ist die Leitfrage einfach: Würde diese Information auch dann an dieselbe Person gehen, wenn sie nicht über eine KI, sondern direkt über ein Wiki, ein Ticket oder eine Datei gesucht würde? Wenn die Antwort unklar ist, darf die KI sie nicht durch eine besonders geschickte Zusammenfassung plötzlich zugänglich machen. Zugriff bleibt Zugriff, auch wenn die Oberfläche freundlicher aussieht.
Das National Institute of Standards and Technology betont im AI Risk Management Framework, dass Risiken rund um KI nicht nur technische Modellfragen sind. Organisation, Governance, Messbarkeit und laufende Kontrolle gehören dazu. Für interne KI-Suche bedeutet das: Datenklassen, Verantwortliche und Prüfprozesse sind kein späteres Feintuning, sondern Teil der Betriebsfreigabe.
Rechte aus Quellsystemen sind nur der Anfang
Viele Einführungen verlassen sich zunächst darauf, dass die KI nur Dokumente sieht, auf die der jeweilige Nutzer ohnehin Zugriff hat. Das ist richtig, aber nicht ausreichend. Berechtigungen in Dateisystemen, Wikis und Tickettools sind oft historisch gewachsen. Gruppen werden nicht regelmäßig bereinigt. Projektordner bleiben offen. Alte Exporte liegen neben aktuellen Handbüchern. Ein KI-System macht diese Unordnung nicht kleiner, sondern leichter nutzbar.
Darum braucht der Betrieb vor dem Rollout eine Rechteprüfung der wichtigsten Wissensquellen. Welche Bereiche enthalten besonders schutzwürdige Informationen? Welche Gruppen sind zu breit? Welche Altbestände gehören archiviert oder ausgeschlossen? Welche Quellen sind nur für Suche erlaubt, aber nicht für generative Zusammenfassungen? Diese Fragen klingen klein, entscheiden aber darüber, ob interne KI Vertrauen aufbaut oder Misstrauen auslöst.
Auch das Zero-Trust-Modell der US-Cybersicherheitsbehörde CISA passt hier als Denkrahmen. Zugriff soll nicht pauschal aus Netzgrenzen oder alten Gruppen abgeleitet werden, sondern aus Identität, Kontext, Gerätezustand, Datenwert und laufender Kontrolle. Für KI-Suche heißt das praktisch: Das System muss Rechte respektieren, Nachweise liefern und verdächtige Nutzung erkennbar machen.
Antwortqualität braucht einen Eigentümer
Ein weiteres Betriebsrisiko liegt in der Qualität der Quellen. Eine KI kann veraltete Betriebsanweisungen, ungeprüfte Notizen oder widersprüchliche Ticketkommentare überzeugend formulieren. Das Ergebnis klingt dann professioneller als die Grundlage. Für den Service Desk ist das gefährlich, weil falsche Sicherheit entsteht.
Jede wichtige Wissensquelle braucht daher einen Eigentümer. Dieser Eigentümer muss nicht jede einzelne Antwort prüfen. Er muss aber dafür sorgen, dass Inhalte aktuell, markiert und aussortierbar sind. Veraltete Dokumente brauchen ein Ablaufdatum oder einen Archivstatus. Kritische Anleitungen brauchen einen Freigabestand. Häufig genutzte Antworten sollten stichprobenartig kontrolliert werden. Ohne diese Pflege wird interne KI zur Beschleunigung des bestehenden Wissenschaos.
Die OWASP Top 10 für Anwendungen mit großen Sprachmodellen beschreibt unter anderem Risiken rund um Datenabfluss, unsichere Ausgaben, übermäßige Berechtigungen und unklare Lieferketten. Auch ohne tiefe Security-Spezialisierung ist die praktische Botschaft klar: KI-Anwendungen brauchen eigene Schutzmechanismen, weil sie Informationen anders verarbeiten und präsentieren als klassische Software.
Was vor dem breiten Einsatz geklärt sein sollte
Ein leichtes Betriebsmodell kann schon viel verhindern. Vor dem breiten Einsatz sollten ITSM, Informationssicherheit, Datenschutz und Fachbereiche gemeinsam festlegen, welche Quellen eingebunden werden, welche Datenklassen ausgeschlossen bleiben, welche Rollen Antworten sehen dürfen, wie Nutzer problematische Antworten melden und wer Korrekturen priorisiert.
Dazu gehört auch Transparenz für Nutzer. Eine KI-Antwort sollte erkennbar machen, auf welche Quellen sie sich stützt, wie aktuell diese Quellen sind und wo die verbindliche Originalinformation liegt. Gerade bei Betriebsanleitungen, Sicherheitsvorgaben und Kundenthemen darf die Antwort nicht wie eine letzte Instanz wirken, wenn sie nur eine Hilfestellung ist.
Ebenso wichtig ist Logging in verständlicher Form. Der Betrieb muss nicht jede Frage inhaltlich überwachen. Er muss aber nachvollziehen können, welche Quellen genutzt wurden, ob Zugriffsfehler auftreten, welche Antwortbereiche besonders oft gemeldet werden und ob sich ungewöhnliche Suchmuster zeigen. Diese Signale helfen, Datenqualität, Rechte und Akzeptanz zu steuern.
Der Servicekatalog darf die KI nicht vergessen
Interne KI gehört als Service in den Servicekatalog. Dort sollte stehen, wofür sie gedacht ist, welche Quellen sie nutzt, welche Grenzen gelten, wie Support funktioniert, wer fachlich verantwortlich ist und welche Fälle ausdrücklich nicht darüber entschieden werden dürfen. Das nimmt dem Werkzeug nicht die Dynamik. Es macht nur sichtbar, dass es Teil des Betriebs ist.
Für ITSM-Teams entsteht daraus eine klare Aufgabe. Sie müssen nicht jedes Modell im Detail erklären. Sie müssen aber sicherstellen, dass Nutzer, Fachbereiche und Management verstehen, was der Dienst leisten darf und was nicht. Die beste interne KI ist nicht die, die am meisten findet. Es ist die, deren Antworten aus sauberen Quellen, passenden Rechten und klarer Verantwortung entstehen.
Quellen und Einordnung NIST AI Risk Management Framework, CISA Zero Trust Maturity Model, OWASP Top 10 for Large Language Model Applications. Stand der Quellenprüfung 22.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.
Bildquelle Pexels / Aktenstapel als Symbol für Datenklassen, Wissensquellen und Informationsordnung / https://www.pexels.com/photo/pile-of-folders-357514/
