KI-Werkzeuge dürfen nicht überall selbst zugreifen

KI-Assistenten werden im IT-Betrieb erst dann wirklich nützlich, wenn sie nicht nur Antworten formulieren, sondern auch auf Werkzeuge zugreifen können. Sie lesen Tickets, suchen in Wissensdatenbanken, starten Abfragen oder bereiten Änderungen vor. Für ITSM-Generalisten klingt das nach Entlastung. Gleichzeitig entsteht eine neue Betriebsfrage: Welche Handlung darf eine KI selbst auslösen und wo muss ein Mensch die Kontrolle behalten?

Kurz gesagt Moderne KI-Werkzeuge können über Schnittstellen mit anderen Systemen verbunden werden. Solche Verbindungen machen aus einem Chatfenster einen Arbeitshelfer mit Zugriff auf Daten, Prozesse und teilweise technische Aktionen. Für den Servicebetrieb ist das relevant, weil ein falsch gesetzter Zugriff nicht nur eine schlechte Antwort erzeugt. Er kann Tickets falsch verändern, vertrauliche Informationen offenlegen oder eine Änderung anstoßen, die niemand sauber freigegeben hat.

Genau hier liegt der Unterschied zwischen einem hilfreichen Assistenten und einem unsichtbaren Betriebsrisiko. Eine KI, die nur einen Entwurf schreibt, kann kontrolliert werden, bevor etwas passiert. Eine KI, die direkt in Service-Management-Werkzeuge, Cloud-Konsolen oder Automationsskripte greift, braucht andere Schutzmechanismen. Der Betrieb muss wissen, was erlaubt ist, was protokolliert wird und welcher Stoppknopf existiert.

Werkzeugzugriff verändert die Verantwortung

Ein Service Desk kann KI nutzen, um ähnliche Vorfälle schneller zu finden, Antwortvorschläge zu erstellen oder bekannte Lösungswege zusammenzufassen. Das ist vergleichsweise gut beherrschbar, solange die KI keine verbindliche Aktion ausführt. Schwieriger wird es, wenn sie Tickets schließt, Prioritäten ändert, Kundendaten abfragt oder technische Befehle vorbereitet.

Dann reicht die Frage nach der Modellqualität nicht mehr aus. Entscheidend wird die Prozessqualität rundherum. Wer hat die Verbindung freigegeben? Welche Rolle nutzt sie? Welche Daten darf die KI lesen? Welche Aktionen sind nur als Vorschlag erlaubt? Welche Aktionen brauchen eine zweite Bestätigung? Diese Fragen gehören nicht in ein spätes Sicherheitsreview, sondern in die Einführung jedes KI-Werkzeugs.

Der Servicebetrieb braucht einfache Zugriffsklassen

Hilfreich ist eine Einteilung, die auch außerhalb von Spezialteams verstanden wird. Die erste Stufe ist reines Lesen: Die KI darf Informationen aus erlaubten Quellen zusammenfassen, aber nichts verändern. Die zweite Stufe ist vorbereitendes Arbeiten: Sie darf Entwürfe, Suchabfragen, Checklisten oder Änderungsvorschläge erzeugen, aber ein Mensch gibt sie frei. Die dritte Stufe ist begrenztes Ausführen: Die KI darf klar definierte, risikoarme Aktionen starten, zum Beispiel ein internes Ticket mit Standardfeldern anlegen. Die vierte Stufe betrifft kritische Eingriffe, etwa Änderungen an produktiven Systemen oder Zugriff auf besonders schützenswerte Daten. Diese Stufe sollte ohne starke menschliche Freigabe tabu bleiben.

Diese Klassen sind keine Bürokratie. Sie machen sichtbar, welche Art von Risiko ein KI-Einsatz erzeugt. Ein Assistent für Wissenssuche braucht andere Kontrollen als ein Werkzeug, das in einer Cloud-Umgebung Aktionen vorbereitet. ITSM kann damit eine gemeinsame Sprache schaffen, bevor einzelne Teams ihre eigenen Ausnahmen bauen.

Freigaben müssen an der Handlung hängen

In klassischen IT-Prozessen wird oft eine Anwendung freigegeben. Bei KI-Werkzeugen ist das zu grob. Dass ein Assistent grundsätzlich erlaubt ist, sagt noch nicht, welche konkrete Handlung er ausführen darf. Besser ist eine Freigabe nach Aktionstyp, Datenbereich und Servicekontext.

Ein Beispiel: Eine KI darf Tickets zu einem bekannten Standardproblem zusammenfassen und eine Antwort entwerfen. Sie darf aber nicht selbst den Status auf gelöst setzen, solange keine Person bestätigt hat, dass der Nutzer wirklich arbeitsfähig ist. In einem anderen Fall darf die KI eine Diagnoseabfrage vorbereiten, aber nicht direkt eine produktive Änderung ausführen. So bleibt Automatisierung nützlich, ohne Verantwortung zu verwischen.

Prüfspuren sind kein Nebenthema

Wenn KI-Systeme Werkzeuge nutzen, muss später nachvollziehbar sein, was passiert ist. Dazu gehören der Nutzer, der Auslöser, das verwendete Werkzeug, der betroffene Service, die gelesenen Datenbereiche, der erzeugte Vorschlag, die bestätigende Person und das Ergebnis. Ohne solche Spuren wird eine Störung schwer aufklärbar. Dann weiß der Betrieb zwar, dass ein Assistent beteiligt war, aber nicht, welche Entscheidungskette zur Aktion geführt hat.

OWASP warnt in seinen Risiken für große Sprachmodelle unter anderem vor unsicherer Ausgabeweiterverarbeitung, übermäßigen Berechtigungen und unzureichender Kontrolle bei autonomen Aktionen. NIST betont im AI Risk Management Framework ebenfalls Nachvollziehbarkeit, Governance und Risikosteuerung. Für ITSM übersetzt heißt das: KI-Werkzeuge brauchen nicht nur gute Antworten, sondern belastbare Betriebsregeln.

Ein Stoppweg gehört in jedes Konzept

Jede produktive Verbindung zwischen KI und Betriebssystemen braucht einen einfachen Abschaltweg. Das kann ein technischer Schalter sein, der bestimmte Werkzeuge deaktiviert, eine Rollenregel, die Ausführung vorübergehend sperrt, oder ein Incident-Prozess für auffälliges KI-Verhalten. Wichtig ist, dass dieser Weg vorher bekannt ist. Ein Stoppknopf, den niemand findet, ist im Ernstfall nur ein theoretischer Schutz.

Auch die Rücknahme muss geklärt sein. Wenn eine KI ein Ticket falsch kategorisiert, lässt sich das leicht korrigieren. Wenn sie eine größere Änderung vorbereitet oder eine falsche Priorität in einen Eskalationsprozess bringt, braucht der Betrieb klare Korrekturwege. Dazu gehören Verantwortliche, Kommunikationsregeln und eine Prüfung, ob ähnliche Aktionen ebenfalls betroffen waren.

Was ITSM-Teams vor der Einführung klären sollten

Vor dem produktiven Einsatz hilft eine kurze, harte Checkliste. Erstens: Welche Datenquellen darf die KI lesen? Zweitens: Welche Aktionen darf sie nur vorschlagen? Drittens: Welche Aktionen darf sie ausführen? Viertens: Welche Rolle oder Person bestätigt kritische Schritte? Fünftens: Welche Protokolle zeigen später, was passiert ist? Sechstens: Wie wird der Zugriff sofort gestoppt, falls etwas falsch läuft?

Diese Fragen sollten pro Service und Werkzeug beantwortet werden, nicht nur einmal allgemein. Ein Assistent im internen Wissensmanagement braucht andere Grenzen als ein Assistent, der Störungsmeldungen triagiert. Ein Werkzeug für Entwicklungsumgebungen hat andere Risiken als ein Werkzeug im produktiven Kundenservice. Die Stärke liegt gerade darin, die Regeln konkret genug zu machen.

Fazit

KI-Werkzeuge können den Servicebetrieb schneller und übersichtlicher machen. Der Nutzen entsteht aber nicht durch möglichst breite Berechtigungen, sondern durch gezielt gesetzte Grenzen. ITSM muss deshalb früh klären, welche Daten gelesen werden dürfen, welche Aktionen eine Freigabe brauchen und wie jede Handlung nachvollziehbar bleibt. Eine KI mit Werkzeugzugriff ist kein normales Chatfenster mehr. Sie ist ein neuer Akteur im Prozess und braucht deshalb klare Leitplanken, bevor sie produktive Systeme berührt.

Quellen und Einordnung Geprüft wurden die Dokumentation zum Model Context Protocol als Beispiel für KI-Werkzeugverbindungen, OWASP Top 10 for Large Language Model Applications und das NIST AI Risk Management Framework. Stand der Quellenprüfung: 20.06.2026.