Bildquelle: Pexels / Pixabay / https://www.pexels.com/photo/257736/
Kurz gesagt KI-Helfer im Service Desk können Tickets sortieren, Antworten vorschlagen und Routinen beschleunigen. Gefährlich wird es, sobald sie eigenständig handeln, ohne dass klar ist, welche Entscheidung noch ein Mensch treffen muss. Für ITSM zählt deshalb nicht nur die Frage, ob ein KI-Werkzeug gute Antworten schreibt. Entscheidend ist, wo seine rote Linie liegt: Darf es ein Ticket schließen, Berechtigungen anstoßen, Prioritäten ändern oder Kunden eine endgültige Zusage geben?
Der Service Desk lebt von Tempo. Nutzer warten auf eine Lösung, Fachbereiche brauchen Rückmeldung und technische Teams wollen nicht durch unnötige Weiterleitungen gebremst werden. KI kann hier helfen, weil sie ähnliche Fälle erkennt, vorhandenes Wissen schneller findet und Standardantworten vorbereitet. Genau diese Stärke erzeugt aber auch ein neues Betriebsrisiko. Ein System, das überzeugend formuliert, wirkt schnell sicherer, als es tatsächlich ist.
Künstliche Intelligenz ist in diesem Zusammenhang kein einzelnes Produkt, sondern eine Funktion, die Daten aus Tickets, Wissensartikeln und Systemen verarbeitet. Das NIST AI Risk Management Framework beschreibt Risikomanagement für KI als Führungsaufgabe mit den Schritten Govern, Map, Measure und Manage. Für den Service Desk heißt das in Alltagssprache: Zuständigkeit festlegen, Einsatzgrenzen verstehen, Verhalten prüfen und Risiken laufend steuern.
Ein Vorschlag ist noch keine Entscheidung
Der wichtigste Unterschied liegt zwischen Unterstützen und Entscheiden. Ein KI-Helfer darf einen bekannten Lösungsartikel vorschlagen. Er darf ein Ticket zusammenfassen, eine Rückfrage formulieren oder eine Kategorie empfehlen. Etwas anderes ist es, wenn er einen Vorfall herunterstuft, eine Eskalation zurücknimmt, ein Ticket schließt oder eine Störung als erledigt meldet. Dann verändert er den Betriebszustand, nicht nur den Text im Ticket.
Diese Grenze muss vor dem Einsatz sichtbar sein. Wer nur allgemein festlegt, dass KI „im Support helfen“ soll, überlässt die eigentliche Risikosteuerung der späteren Einzelfallreaktion. Besser ist eine einfache Freigabematrix: Was darf die KI allein vorbereiten, was darf sie nur vorschlagen, was braucht menschliche Bestätigung und was bleibt grundsätzlich gesperrt?
Service Desk und Betrieb brauchen denselben Kontrollblick
Incident Management soll negative Auswirkungen auf den Betrieb begrenzen und Services wieder stabil machen. Dieser Zweck bleibt auch dann bestehen, wenn KI Teile der Arbeit beschleunigt. Ein schneller falscher Abschluss ist schlechter als eine etwas langsamere, aber nachvollziehbare Bearbeitung. Besonders kritisch sind Fälle mit Sicherheitsbezug, Datenschutz, Berechtigungen, Kundenwirkung, Vertragsfolgen oder sichtbaren Ausfällen.
Für Generalisten im IT-Management ist deshalb eine praktische Frage wichtiger als die Modelltechnik: Was passiert, wenn der KI-Helfer falsch liegt? Gibt es einen Stoppmechanismus, einen Audit-Trail, eine klare Kennzeichnung im Ticket und einen Weg zurück? Ohne diese Antworten wird Automatisierung zum stillen Entscheider im Hintergrund.
Die rote Linie gehört in den Ticketprozess
Eine rote Linie ist nur wirksam, wenn sie im Arbeitsablauf auftaucht. Sie sollte nicht in einem Strategiepapier verschwinden. Im Tickettool kann sie als Pflichtbestätigung erscheinen, bevor ein KI-Vorschlag eine Statusänderung auslöst. In der Wissensdatenbank kann sie festlegen, welche Artikel die KI verwenden darf. In der Berechtigungsvergabe kann sie verhindern, dass automatische Antworten direkt in Zugriffsänderungen münden.
Auch die Sprache im Ticket ist wichtig. Nutzer sollten erkennen, ob eine Antwort vollständig geprüft wurde oder ob sie auf einem KI-Vorschlag basiert. Interne Bearbeiter brauchen außerdem einen Hinweis, warum ein Vorschlag entstanden ist: ähnlicher Vorfall, passender Wissensartikel, erkannte Fehlermeldung oder nur statistische Nähe. Je klarer die Begründung, desto leichter lässt sich der Vorschlag fachlich prüfen.
Ein KI-Service braucht einen Owner
ISO 42001 beschreibt Anforderungen an ein Managementsystem für künstliche Intelligenz. Unabhängig davon, ob eine Organisation diese Norm formal nutzt, ist der Gedanke für ITSM wertvoll: KI-Einsatz braucht Rollen, Steuerung und nachvollziehbare Prozesse. Ein Service Desk sollte deshalb nicht nur einen Tool-Administrator haben. Er braucht einen fachlichen Owner für den KI-Einsatz, einen technischen Owner für Integration und Datenflüsse sowie einen klaren Eskalationsweg bei Fehlverhalten.
Der fachliche Owner entscheidet, welche Ticketarten in den KI-Pfad dürfen. Der technische Owner prüft Schnittstellen, Protokolle, Berechtigungen und Änderungen. Security und Datenschutz bewerten sensible Inhalte. Der Service Desk liefert Rückmeldung aus echten Fällen. Erst zusammen entsteht ein Betriebsmodell, das mehr ist als eine eingeschaltete Funktion.
Die Prüfung beginnt mit kleinen, messbaren Fällen
Ein sinnvoller Start sind begrenzte Szenarien mit geringer Außenwirkung. Zum Beispiel Zusammenfassungen langer Tickets, Vorschläge für Rückfragen oder das Finden passender Wissensartikel. Danach lässt sich messen, ob die Vorschläge nützlich sind, wo sie irreführen und welche Fälle konsequent ausgenommen werden müssen. Entscheidend ist, dass Feedback nicht nur gefühlt gesammelt wird. Falsche Vorschläge brauchen Kategorien wie falsche Ursache, fehlender Kontext, riskante Zusage, falsche Priorität oder ungeeigneter Artikel.
Solche Messpunkte machen die Diskussion sachlicher. Dann geht es nicht mehr um Begeisterung oder Skepsis gegenüber KI, sondern um konkrete Betriebsqualität. Welche Ticketarten profitieren? Welche brauchen menschliche Prüfung? Welche dürfen gar nicht automatisiert werden? Wo entstehen neue Supportfragen?
Fazit
KI im Service Desk wird dann nützlich, wenn sie Arbeit entlastet, ohne Verantwortung zu verstecken. Die rote Linie trennt Vorschlag von Entscheidung, Tempo von Risiko und Komfort von Kontrolle. Wer sie früh im Ticketprozess, in Rollen, Messpunkten und Freigaben verankert, kann KI produktiv nutzen. Wer sie offenlässt, merkt erst im Störungsfall, dass ein hilfreicher Textgenerator längst operative Entscheidungen beeinflusst.
