Bildquelle: Pexels / https://www.pexels.com/photo/black-and-white-chess-piece-260024/
Kurz gesagt KI-Systeme werden im IT-Betrieb oft als Technikprojekt gestartet. Im Alltag entscheidet aber nicht nur das Modell über Erfolg oder Risiko. Entscheidend ist, wer den Einsatz freigibt, wer Fehler bewertet, wer Änderungen prüft und wer stoppt, wenn ein System falsche Empfehlungen liefert.
Der europäische AI Act ordnet künstliche Intelligenz nach Risiken und verlangt für bestimmte Anwendungen klare Pflichten. Das NIST AI Risk Management Framework beschreibt KI-Risiken als Aufgabe, die gesteuert, gemessen und laufend kontrolliert werden muss. Das Bundesamt für Sicherheit in der Informationstechnik weist ebenfalls darauf hin, dass KI sicher, nachvollziehbar und kontrollierbar eingesetzt werden muss. Für ITSM heißt das: KI gehört nicht nur in Architektur und Einkauf, sondern in Betriebsmodell, Rollen und Serviceprozesse.
Künstliche Intelligenz meint hier Software, die aus Daten Muster ableitet, Inhalte erzeugt, Entscheidungen vorbereitet oder Arbeitsschritte automatisiert. Der AI Act ist das europäische Regelwerk für solche Systeme. Er soll Risiken begrenzen, Transparenz fördern und Verantwortlichkeiten klarer machen. Für den IT-Betrieb ist wichtig, ob ein KI-System nur unterstützt oder ob es Entscheidungen beeinflusst, die Nutzer, Kunden, Sicherheit oder Servicequalität betreffen.
Das Modell ist selten der einzige Engpass
In vielen Projekten steht zuerst die Frage im Raum, welches Tool besser ist. Welches Sprachmodell antwortet genauer? Welche Plattform lässt sich einfacher einbinden? Welche Automatisierung spart die meiste Zeit? Diese Fragen sind wichtig, aber sie greifen zu kurz. Ein KI-Helfer im Service Desk kann technisch gut funktionieren und trotzdem operativ gefährlich werden, wenn niemand festlegt, welche Antworten er geben darf, wann ein Mensch übernehmen muss und wie falsche Vorschläge erkannt werden.
Gerade ITSM-Generalisten sollten deshalb die Rollenfrage früh stellen. Wer besitzt den fachlichen Prozess? Wer bewertet Datenschutz, Informationssicherheit und Betriebsrisiko? Wer pflegt Wissensartikel, Prompts, Regeln und Ausnahmen? Wer prüft, ob die Antworten nach einer Änderung noch passen? Ohne diese Zuständigkeiten entsteht eine Lücke zwischen technischer Einführung und dauerhaftem Betrieb.
KI braucht einen Service Owner, nicht nur einen Modellverantwortlichen
Ein KI-System im Betrieb berührt mehrere Ebenen. Es nutzt Daten, greift auf Wissen zu, gibt Empfehlungen, kann Tickets vorsortieren oder Kundenkommunikation vorbereiten. Darum reicht ein einzelner technischer Ansprechpartner nicht aus. Der Service Owner muss wissen, welchen Zweck die KI im Service erfüllt und welche Grenzen gelten. Die Sicherheitsrolle muss bewerten, welche Daten verarbeitet werden dürfen. Der Prozessverantwortliche muss festlegen, wie Ausnahmen, Beschwerden und Fehler zurück in den Verbesserungsprozess kommen.
Diese Rollen müssen nicht in großen Gremien enden. Praktisch reicht oft eine klare Matrix. Darin steht, wer Einsatzfälle freigibt, wer Datenquellen genehmigt, wer Änderungen am Prompt oder an der Wissensbasis prüft, wer Qualitätsproben zieht und wer bei Auffälligkeiten abschaltet. Wichtig ist, dass diese Matrix vor dem Produktivbetrieb existiert und später in Tickets, Change-Datensätzen oder Betriebsdokumentation wiedergefunden wird.
Risikoklassen müssen in Alltagssprache übersetzt werden
Regelwerke sprechen von Risiken, Pflichten und Kontrollen. Im Betrieb muss daraus eine einfache Arbeitslogik werden. Ein internes Schreibwerkzeug für Entwürfe hat ein anderes Gewicht als ein System, das Störungen priorisiert oder Nutzern verbindliche Auskünfte gibt. Ein Chatbot mit Zugriff auf interne Wissensartikel ist anders zu bewerten als eine Automatisierung, die direkt Änderungen im System auslöst.
Für ITSM ist deshalb eine kleine Entscheidungshilfe sinnvoll. Sie fragt nicht nur nach der Technik, sondern nach Wirkung und Nähe zur Entscheidung. Beeinflusst die KI eine Kundenantwort? Verarbeitet sie vertrauliche Daten? Kann sie Berechtigungen, Prioritäten oder Eskalationen verändern? Wird ihr Ergebnis von Menschen geprüft oder läuft es direkt weiter? Je näher das System an echten Entscheidungen liegt, desto stärker müssen Freigabe, Überwachung und Stoppregeln sein.
Der Betrieb muss Fehler sichtbar machen
KI-Fehler sehen im Alltag oft harmlos aus. Eine Antwort klingt plausibel, ist aber veraltet. Eine Zusammenfassung lässt eine wichtige Einschränkung weg. Eine Priorisierung wirkt logisch, bevorzugt aber den falschen Fall. Solche Fehler fallen nicht zuverlässig durch klassische Verfügbarkeitsüberwachung auf. Das System ist erreichbar, die Antwortzeit stimmt, und trotzdem entsteht ein Qualitätsproblem.
Darum braucht KI im Betrieb eigene Prüfpunkte. Dazu gehören Stichproben von Antworten, Feedback aus dem Service Desk, klare Meldewege für falsche Auskünfte, Versionierung von Wissensständen und ein Review nach größeren Änderungen. Auch die Frage, welche Daten nicht genutzt werden dürfen, muss regelmäßig geprüft werden. Ein KI-Service altert nicht nur technisch. Er altert auch fachlich, sobald Prozesse, Produkte, Richtlinien oder Kundenerwartungen wechseln.
Was vor dem produktiven Einsatz geklärt sein sollte
- Welchen konkreten Serviceprozess unterstützt die KI?
- Welche Entscheidungen darf sie nur vorbereiten und nicht selbst treffen?
- Welche Datenquellen sind erlaubt, gesperrt oder nur eingeschränkt nutzbar?
- Wer genehmigt Änderungen an Regeln, Prompts und Wissensbasis?
- Wie werden falsche Antworten gemeldet, korrigiert und ausgewertet?
- Wann muss ein Mensch übernehmen?
- Wer darf den KI-Service im Zweifel stoppen?
Governance darf den Nutzen nicht ersticken
Die richtige Antwort auf KI-Risiken ist nicht, jedes Experiment zu blockieren. IT-Organisationen brauchen geschützte Räume, in denen Teams Erfahrungen sammeln können. Der Unterschied liegt in der Grenze zum produktiven Betrieb. Solange ein Werkzeug nur intern ausprobiert wird, reichen andere Regeln als bei einem System, das Kunden, Mitarbeiter oder operative Entscheidungen beeinflusst.
Ein guter Betriebsrahmen macht diese Grenze sichtbar. Er erlaubt schnelle Tests, verlangt aber vor dem Live-Einsatz klare Rollen, Datenregeln, Qualitätsproben und Stoppmöglichkeiten. So bleibt KI nutzbar, ohne dass Verantwortung im Projektnebel verschwindet. Für ITSM ist das eine vertraute Aufgabe: aus Technik einen verlässlichen Service machen.
Fazit
KI scheitert im Betrieb selten nur an fehlender Rechenleistung oder einem schwachen Modell. Häufiger fehlt die klare Antwort auf einfache Verantwortungsfragen. Wer entscheidet, wer prüft, wer korrigiert, wer stoppt? Wenn diese Fragen vor dem Produktivbetrieb beantwortet sind, kann KI schneller Nutzen bringen und bleibt trotzdem steuerbar.
