Bildquelle: Pexels / https://www.pexels.com/photo/5380642/
Eine KI darf nicht ungeprüft in interne Systeme greifen
Solange ein KI-Werkzeug nur Texte zusammenfasst oder Vorschläge macht, bleibt das Risiko für den IT-Betrieb begrenzt. Kritisch wird es, sobald die KI echte Werkzeuge nutzt, Daten aus internen Systemen abfragt, Tickets verändert, Skripte startet oder Informationen an andere Dienste weitergibt. Dann ist sie nicht mehr nur ein Assistent auf dem Bildschirm. Sie wird zu einem neuen Zugangspunkt in die Betriebslandschaft.
Genau an dieser Stelle braucht IT Service Management eine klare Sprache. Die Frage lautet nicht, ob KI modern oder hilfreich ist. Die Frage lautet, welche Handlung eine KI ausführen darf, wer dafür verantwortlich bleibt und wo der Betrieb die Ausführung stoppen kann. Ohne solche Schleusen entsteht ein System, das freundlich klingt, aber im falschen Moment mehr Rechte nutzt, als ein Mensch im selben Prozess bekommen hätte.
Der neue Zugangspunkt sieht harmlos aus
Ein Chatfenster wirkt vertraut. Nutzer stellen eine Frage, die KI antwortet und die Oberfläche bleibt leicht bedienbar. Hinter dieser Oberfläche kann aber eine mächtige Kette entstehen. Ein Modell erkennt eine Absicht, ruft ein Werkzeug auf, liest Daten, schreibt einen Datensatz oder stößt einen Prozess an. Für den Anwender fühlt sich das wie Komfort an. Für den Betrieb ist es ein neuer technischer Pfad mit Berechtigungen, Fehlermöglichkeiten und Nachweispflichten.
Das Model Context Protocol beschreibt diesen Pfad als Verbindung zwischen KI-Anwendungen, Werkzeugen und Datenquellen. Diese Architektur ist nützlich, weil sie KI-Systeme aus der isolierten Textbox herausholt. Sie erhöht aber zugleich den Bedarf an Steuerung. Jeder angebundene Dienst wird Teil der Frage, was die KI darf, welche Daten sie sieht und welche Folgen ein falscher Werkzeugaufruf haben kann.
Ein Assistent braucht nicht alle Rechte eines Administrators
Der wichtigste Grundsatz ist einfach. Eine KI sollte nur die Rechte bekommen, die sie für einen klar beschriebenen Zweck benötigt. Das klingt selbstverständlich, wird in der Praxis aber schnell unscharf. Wenn ein Assistent Tickets priorisieren soll, braucht er nicht automatisch Schreibrechte auf alle Felder. Wenn er Logdaten erklären soll, braucht er nicht den Schlüssel zu produktiven Änderungen. Wenn er Benutzeranfragen vorbereitet, muss er nicht selbst Konten entsperren.
Für ITSM-Generalisten ist das bekannte Rollenarbeit. Rechte werden nicht nach technischer Bequemlichkeit vergeben, sondern nach Aufgabe, Risiko und Verantwortlichkeit. Bei KI-Werkzeugen kommt hinzu, dass die Entscheidung oft indirekt entsteht. Der Mensch formuliert eine Absicht, das Modell wählt einen Zwischenschritt und ein angebundenes Werkzeug führt aus. Deshalb müssen Berechtigungen enger und sichtbarer geschnitten sein als bei klassischen Automatisierungen.
Werkzeugaufrufe brauchen eine Ampel
Nicht jeder KI-Schritt hat dasselbe Risiko. Eine reine Suche in freigegebenem Wissen ist etwas anderes als das Ändern eines Tickets, das Auslösen eines Deployments oder das Abfragen personenbezogener Daten. Der Betrieb sollte Werkzeugaufrufe deshalb in Klassen einteilen. Grün sind ungefährliche Lesezugriffe auf freigegebene Informationen. Gelb sind vorbereitende Aktionen, die ein Mensch prüft. Rot sind produktive Änderungen, sensible Datenabfragen oder Schritte mit Außenwirkung.
Diese Einteilung muss im Prozess sichtbar werden. Ein gelber Schritt erzeugt einen Vorschlag, keinen fertigen Vollzug. Ein roter Schritt braucht eine ausdrückliche Freigabe, ein Vier-Augen-Prinzip oder bleibt für die KI ganz gesperrt. So wird aus abstrakter KI-Governance eine konkrete Betriebsregel. Der Service Owner kann erklären, warum ein Werkzeug erlaubt ist, wo die Grenze liegt und welche Nachweise im Audit vorgelegt werden können.
Protokolle sind keine Nebensache
OWASP beschreibt für große Sprachmodelle unter anderem Risiken rund um unsichere Werkzeugnutzung, Datenabfluss, übermäßige Berechtigungen und manipulierte Eingaben. Diese Risiken lassen sich im Betrieb nur bewerten, wenn die tatsächlichen Aktionen nachvollziehbar sind. Ein Chatverlauf allein reicht nicht. Er zeigt, was geschrieben wurde, aber nicht zuverlässig, welcher technische Aufruf mit welchen Parametern tatsächlich ausgeführt wurde.
Darum brauchen KI-Werkzeuge ein sauberes Protokoll. Welche Anfrage kam von welchem Nutzer. Welches Werkzeug wurde aufgerufen. Welche Datenquelle war betroffen. Welche Berechtigung wurde genutzt. Wurde nur gelesen oder auch geschrieben. Hat ein Mensch den Schritt freigegeben. Gab es einen Fehler, eine Ablehnung oder eine Sicherheitsregel. Diese Informationen helfen nicht nur der Revision. Sie helfen auch dem Incident Management, wenn nach einem Fehlverhalten schnell verstanden werden muss, was passiert ist.
Prompt-Injection wird zum Betriebsthema
Prompt-Injection bedeutet, dass ein Modell durch fremde oder manipulierte Inhalte zu unerwünschten Handlungen verleitet werden kann. Für Laien klingt das wie ein Spezialproblem aus der KI-Sicherheit. Im Betrieb ist es handfest. Wenn ein Assistent E-Mails, Webseiten, Tickets oder Dokumente liest, kann darin eine Anweisung stehen, die nicht vom berechtigten Nutzer stammt. Das Modell muss lernen, solche Inhalte nicht mit echten Steuerbefehlen zu verwechseln.
Ein praktischer Schutz besteht aus mehreren Schichten. Externe Inhalte werden als untrusted markiert. Werkzeuge akzeptieren nur klar definierte Parameter. Kritische Aktionen verlangen eine explizite Bestätigung außerhalb des gelesenen Inhalts. Sensible Daten werden nicht automatisch in Antworten übernommen. Der Betrieb testet typische Missbrauchsszenarien, statt nur den normalen Erfolgsfall zu prüfen.
Service Desk und Change Management müssen beteiligt sein
KI-Anbindungen entstehen oft in Fachbereichen oder Entwicklungsteams. Der Betrieb merkt sie manchmal erst, wenn Tickets auftauchen oder eine Änderung Nebenwirkungen zeigt. Das ist zu spät. Sobald ein KI-Werkzeug produktive Systeme berührt, gehört es in dieselben Steuerflächen wie andere integrationsnahe Änderungen. Es braucht einen Service Owner, eine Risikoabschätzung, Supportwissen, Betriebsdokumentation und einen klaren Abschaltweg.
Der Service Desk muss wissen, woran ein Fehler erkennbar ist. Hat die KI eine Aktion nicht ausgeführt, falsch ausgeführt oder durfte sie es gar nicht. Welche Meldung sieht der Nutzer. Wohin wird eskaliert. Welche Logs sind relevant. Change Management muss zusätzlich klären, wann neue Werkzeuge, neue Datenquellen oder neue Berechtigungen als Änderung gelten. Ein neuer Anschluss an ein Fachsystem ist kein reines Komfortupdate.
Eine einfache Startprüfung schützt vor Blindflug
Für den Einstieg reicht eine klare Prüfliste. Welche internen Systeme kann die KI erreichen. Welche Aktionen sind nur lesend, welche verändern Daten. Welche Rollen dürfen die Funktion nutzen. Welche Datenklassen können in Antworten landen. Welche Werkzeugaufrufe werden protokolliert. Wo ist eine menschliche Freigabe verpflichtend. Wie lässt sich die Verbindung kurzfristig abschalten. Wer prüft regelmäßig, ob Rechte, Schnittstellen und Dokumentation noch stimmen.
Das NIST AI Risk Management Framework betont, dass KI-Risiken identifiziert, gemessen, gesteuert und überwacht werden müssen. Für den ITSM-Alltag heißt das. Ein KI-Werkzeug ist kein einmaliger Rollout, sondern ein laufender Betriebsgegenstand. Es verändert sich durch neue Modelle, neue Werkzeuge, neue Daten und neue Nutzungsmuster. Deshalb braucht es regelmäßige Kontrolle, nicht nur eine Startfreigabe.
Fazit
KI-Werkzeuge werden im Betrieb wertvoller, sobald sie echte Systeme erreichen. Genau dadurch werden sie aber auch riskanter. Der richtige Schutz besteht nicht aus pauschalem Verbot und nicht aus blindem Vertrauen. Entscheidend sind enge Rechte, sichtbare Werkzeugklassen, menschliche Freigaben für kritische Schritte, belastbare Protokolle und ein Service Owner, der die Verbindung verantwortet. Dann kann KI Aufgaben beschleunigen, ohne unbemerkt zur Schattensteuerung produktiver Systeme zu werden.
