Bildquelle: extern
KI-Assistenten brauchen Grenzen, bevor sie echte Systeme bedienen
KI-Assistenten werden gerade von reinen Antwortmaschinen zu Werkzeugnutzern. Sie können Tickets zusammenfassen, Wissen suchen, Code vorschlagen, Kalender prüfen oder über Schnittstellen Aktionen auslösen. Für ITSM-Generalisten klingt das verlockend, weil Routinearbeit schneller wird. Der kritische Punkt liegt aber nicht in der Chatoberfläche, sondern in den Rechten dahinter. Sobald ein Assistent echte Systeme bedienen darf, braucht er dieselbe Betriebsdisziplin wie jede andere produktive Anwendung.
Die praktische Frage lautet deshalb nicht, ob KI im Servicebetrieb helfen kann. Die Frage lautet, welche Grenze verhindert, dass ein falsch verstandener Auftrag, eine manipulierte Eingabe oder ein unklarer Prozess echte Schäden auslöst. Wer KI-Agenten ohne saubere Werkzeuggrenzen einführt, verschiebt Verantwortung aus dem sichtbaren Prozess in eine schwer nachvollziehbare Automatisierung.
Werkzeuge machen aus KI ein Betriebsobjekt
Solange ein Chatbot nur allgemeine Antworten liefert, bleibt das Risiko begrenzt. Anders sieht es aus, wenn er Zugriff auf Tickets, Kundendaten, Repositories, Monitoring, Dokumente oder Administrationsfunktionen bekommt. Dann wird aus einer Hilfsfunktion ein Betriebsobjekt mit eigenen Abhängigkeiten. Es braucht Owner, Rollenmodell, Protokollierung, Freigabeweg, Testumgebung, Störfallplan und regelmäßige Prüfung.
OWASP beschreibt in den Top 10 für Anwendungen mit großen Sprachmodellen mehrere Risiken, die genau in diese Richtung zeigen. Dazu gehören manipulierte Eingaben, unsichere Ausgaben, übermäßige Handlungsfreiheit und unsichere Schnittstellen. Für den Servicebetrieb heißt das. Nicht die KI als Begriff ist das Problem, sondern die Kombination aus Zugriff, Kontext und automatischer Handlung.
Die erste Grenze ist der Zweck
Ein KI-Assistent sollte nicht mit der Frage starten, welche Werkzeuge technisch möglich sind. Der bessere Start ist der konkrete Zweck. Soll er Tickets klassifizieren. Soll er Lösungsvorschläge vorbereiten. Soll er nur interne Wissensartikel suchen. Oder soll er tatsächlich Änderungen an einem System auslösen. Je näher die Funktion an echte Veränderungen rückt, desto strenger müssen Freigabe, Protokollierung und menschliche Kontrolle werden.
Ein Assistent, der ein Ticket zusammenfasst, braucht andere Rechte als ein Assistent, der eine Änderung im Cloud-Konto ausführen könnte. Diese Trennung muss sichtbar sein. Leserechte, Schreibrechte und Ausführungsrechte gehören in getrennte Rollen. Standardmäßig sollte ein KI-Agent möglichst wenig dürfen. Zusätzliche Rechte müssen begründet, getestet und zeitlich oder sachlich begrenzt werden.
Prompts sind keine ausreichende Kontrolle
Ein häufiger Irrtum lautet, man könne einen Agenten mit einer guten Arbeitsanweisung ausreichend absichern. Anweisungen sind wichtig, aber sie ersetzen keine technischen Grenzen. Wenn ein Werkzeug gefährliche Aktionen erlaubt, darf die Absicherung nicht allein davon abhängen, dass das Modell den Auftrag richtig interpretiert. Sicherheitsgrenzen müssen im System selbst liegen.
Das MCP-Projekt beschreibt Sicherheitsgrundsätze wie Nutzerzustimmung, klare Kontrolle über Datenzugriff und sorgfältige Behandlung von Werkzeugberechtigungen. Für ITSM-Verantwortliche ist daran entscheidend. Jede Werkzeugverbindung braucht eine nachvollziehbare Regel, wer sie freigegeben hat, welche Daten sie sehen darf, welche Aktionen erlaubt sind und wie Missbrauch oder Fehlbedienung erkannt werden.
Protokolle müssen für Menschen lesbar bleiben
Wenn ein Assistent im Betrieb hilft, muss später rekonstruierbar sein, was passiert ist. Ein Log darf nicht nur technische IDs enthalten. Es sollte zeigen, welcher Nutzer den Vorgang gestartet hat, welche Datenquelle genutzt wurde, welches Werkzeug angesprochen wurde, welche Aktion vorgeschlagen oder ausgeführt wurde und ob ein Mensch bestätigt hat. Ohne diese Spur wird ein KI-Fehler schnell zum Verantwortungsnebel.
Das ist besonders wichtig bei Störungen, Beschwerden oder Audits. Der Service Desk muss erklären können, warum ein Ticket anders priorisiert wurde. Ein Change-Verantwortlicher muss sehen, ob eine Änderung nur empfohlen oder wirklich angestoßen wurde. Datenschutz und Informationssicherheit müssen prüfen können, ob sensible Daten in einen nicht vorgesehenen Kontext geraten sind.
Der Abschaltweg gehört in den Betriebsplan
Ein produktiver KI-Assistent braucht einen einfachen Abschaltweg. Wenn ein Werkzeug falsche Ergebnisse liefert, zu viele Rechte hat oder ein neuer Angriff bekannt wird, darf die Organisation nicht erst suchen müssen, wo die Verbindung deaktiviert wird. Der Ausstieg gehört in die Betriebsdokumentation. Dazu zählen technische Deaktivierung, verantwortliche Person, Kommunikationsweg, Ersatzprozess und Prüfung der letzten Aktionen.
Das NIST AI Risk Management Framework betont den Umgang mit Risiken über den gesamten Lebenszyklus. Für den IT-Betrieb lässt sich daraus eine einfache Regel ableiten. KI-Funktionen werden nicht einmalig freigegeben und dann vergessen. Sie müssen regelmäßig überprüft werden, weil Datenquellen, Werkzeuge, Modellverhalten und Nutzergruppen sich ändern.
Was vor dem Produktivstart geprüft werden sollte
Vor dem ersten produktiven Einsatz helfen konkrete Prüfpunkte. Welcher Service Owner verantwortet den Assistenten. Welche Werkzeuge sind angebunden. Welche Daten darf er lesen. Welche Aktionen darf er auslösen. Wo ist menschliche Bestätigung Pflicht. Welche Protokolle werden gespeichert. Wie wird getestet, ob falsche oder manipulierte Eingaben abgefangen werden. Wer kann die Verbindung sofort abschalten.
Diese Fragen bremsen Innovation nicht aus. Sie verhindern, dass ein nützliches Werkzeug später wegen eines vermeidbaren Vorfalls grundsätzlich infrage gestellt wird. Gerade im ITSM ist das wichtig, weil Vertrauen in Prozesse, Nachweise und Zuständigkeiten entscheidet, ob Automatisierung dauerhaft akzeptiert wird.
Fazit
KI-Assistenten können den IT-Betrieb entlasten, wenn sie sauber eingeführt werden. Der Nutzen entsteht aber nicht durch möglichst viele angebundene Werkzeuge, sondern durch klare Grenzen. Zweck, Rechte, Protokolle, menschliche Kontrolle und Abschaltweg gehören vor den Produktivstart. Dann wird aus einem riskanten Experiment ein beherrschbares Betriebsobjekt, das Service-Teams unterstützt, ohne Verantwortung zu verwischen.
