KI-Werkzeuge gehören in den Servicekatalog, sonst findet niemand die Verantwortung

KI-Werkzeuge tauchen in Unternehmen oft zuerst als praktische Helfer auf: ein Chatfenster für Texte, ein Assistent im Code-Editor, eine Funktion im Ticketsystem oder eine Zusammenfassung in der Wissensdatenbank. Für den einzelnen Nutzer wirkt das wie ein Werkzeug mehr. Für ITSM und IT-Management entsteht aber eine andere Frage: Ist dieses Werkzeug ein kontrollierter Service mit Zuständigkeit, Risikoabwägung und Supportweg, oder nur eine Funktion, die irgendwann jemand eingeschaltet hat?

Genau hier entscheidet sich, ob KI im Betrieb beherrschbar bleibt. Ein KI-Werkzeug kann Daten verarbeiten, Entscheidungen vorbereiten, Kosten auslösen, Fehler verstärken oder vertrauliche Informationen in falsche Kontexte bringen. Wenn es trotzdem nirgends als Service auftaucht, fehlen die einfachen Antworten: Wer ist fachlicher Owner? Welche Daten dürfen hinein? Wer prüft die Ergebnisse? Was passiert bei Ausfall, Fehlverhalten oder Missbrauch? Und wer darf die Nutzung wieder stoppen?

Die Schattenseite beginnt nicht erst bei Schatten-IT

Schatten-IT klingt nach heimlich installierter Software. Bei KI ist die Grenze oft weicher. Eine vorhandene SaaS-Plattform ergänzt eine KI-Funktion. Ein Hersteller aktiviert eine Zusammenfassung. Ein Entwicklungsteam nutzt einen Assistenten, der schon im Werkzeug steckt. Ein Fachbereich testet ein freigegebenes Modell für einen konkreten Prozess. Nichts davon muss absichtlich am Betrieb vorbei laufen. Trotzdem kann daraus eine unübersichtliche Landschaft entstehen, wenn niemand die KI-Funktion als eigenen Servicebestandteil führt.

Für ITSM-Generalisten ist das ein bekanntes Muster. Was nicht im Katalog steht, bekommt selten saubere Betriebsregeln. Es gibt kein einheitliches Onboarding, keinen klaren Supportweg, keine dokumentierten Grenzen, keine Prüffrage für Datenklassen und oft auch keinen Exit-Pfad. Bei klassischen Tools ist das schon ärgerlich. Bei KI wird es gefährlicher, weil Ergebnisse plausibel wirken können, obwohl sie falsch, veraltet oder unvollständig sind. Der Betrieb muss deshalb nicht nur wissen, ob ein Tool verfügbar ist, sondern wofür es verwendet werden darf.

Ein KI-Service braucht mehr als einen technischen Owner

Ein technischer Owner kann erklären, wo ein Werkzeug läuft, wie die Schnittstelle funktioniert und welche Lizenz genutzt wird. Das reicht bei KI nicht. Es braucht zusätzlich einen fachlichen Owner, der den zulässigen Einsatz beschreibt. Darf das Werkzeug Kundendaten sehen? Darf es Entscheidungsvorlagen erzeugen? Darf es Code ändern? Darf es Tickets priorisieren? Muss ein Mensch jeden Vorschlag prüfen? Welche Nutzergruppe ist zugelassen?

Diese Fragen gehören nicht in verstreute Chatverläufe oder Einzelfreigaben. Sie gehören in einen Serviceeintrag, der von Betrieb, Security, Datenschutz, Fachbereich und Management verstanden wird. Ein guter Eintrag muss nicht lang sein. Er sollte aber Zweck, Nutzerkreis, Datenklassen, zentrale Risiken, Freigabegrenzen, Supportweg, Kostenverantwortung und Abschaltpfad sichtbar machen. Dann wird KI nicht zur Sonderwelt, sondern zu einem normal geführten Bestandteil der Servicelandschaft.

Risikomanagement darf nicht im Projektordner enden

Das NIST AI Risk Management Framework beschreibt KI-Risiken als etwas, das identifiziert, gemessen, gesteuert und im Kontext bewertet werden muss. ISO/IEC 42001 zielt auf ein Managementsystem für künstliche Intelligenz. Die europäische KI-Regulierung ordnet KI-Systeme nach Risiken und Pflichten. Diese Quellen kommen aus unterschiedlichen Blickwinkeln, führen aber zu einer ähnlichen betrieblichen Konsequenz: KI braucht dauerhafte Steuerung, nicht nur eine Startfreigabe.

Im Alltag scheitert genau das häufig an der Übergabe. Ein Pilotprojekt bewertet Risiken, dokumentiert Annahmen und bekommt Zustimmung. Danach wird die Funktion produktiv genutzt, aber die Dokumentation bleibt im Projektordner liegen. Der Service Desk weiß wenig darüber, Fachbereiche kennen nur die Oberfläche, Security sieht einzelne Zugriffe und das Management bekommt Kosten oder Beschwerden erst spät. Wenn KI im Servicekatalog geführt wird, bleibt die Risikobetrachtung näher am Betrieb: Änderungen, Vorfälle, Nutzergruppen und Datenflüsse können regelmäßig nachgezogen werden.

Der Service Desk braucht klare Antwortgrenzen

KI-Funktionen verändern auch den Support. Nutzer fragen nicht nur, warum ein Tool nicht erreichbar ist. Sie fragen, warum eine Antwort falsch war, warum eine Zusammenfassung fehlt, ob ein Vorschlag verbindlich ist oder ob sensible Daten versehentlich verarbeitet wurden. Ohne klaren Serviceeintrag muss der Service Desk improvisieren. Er weiß dann vielleicht, welches System betroffen ist, aber nicht, welche fachliche Grenze gilt.

Ein KI-Service sollte deshalb typische Supportfälle vorwegnehmen. Was ist ein Incident? Ein Ausfall der Oberfläche, ein falsches Ergebnis, ein Datenschutzverdacht, ein Kostenanstieg oder eine unerwartete Weitergabe von Eingaben? Wer bewertet fachliche Fehler? Wann wird Security eingeschaltet? Wann muss Datenschutz prüfen? Welche Logs sind verfügbar? Welche Daten dürfen Supportmitarbeiter einsehen? Je klarer diese Antworten sind, desto weniger landet im Störungsfall alles bei der falschen Stelle.

Kosten und Verbrauch gehören zur Betriebssteuerung

KI-Werkzeuge bringen oft neue Verbrauchsmodelle mit. Manche Kosten entstehen pro Nutzer, andere pro Anfrage, Modellaufruf, Dokument, Zeichenmenge oder Verarbeitungsschritt. Wenn ein Tool nur als Feature wahrgenommen wird, fallen diese Kosten spät auf. Für IT-Management ist das ein Governance-Thema: Wer darf Nutzung ausweiten, wer sieht Verbrauch, wer bewertet Nutzen und wer stoppt ein Modell, wenn Aufwand und Ergebnis nicht mehr zusammenpassen?

Auch diese Steuerung passt in den Servicekatalog. Nicht als Finanzroman, sondern als klare Verantwortlichkeit. Der Serviceeintrag kann festhalten, welches Budget oder welche Kostenstelle betroffen ist, welche Nutzung beobachtet wird und ab welcher Schwelle eine Review nötig ist. Damit wird KI nicht pauschal gebremst. Im Gegenteil: Gute Services bekommen einen verlässlichen Rahmen, in dem Nutzung wachsen kann, ohne dass der Betrieb erst im Nachhinein aufräumen muss.

Datenklassen sind keine Fußnote

Bei KI ist die Frage nach Daten besonders direkt. Texte, Tickets, Protokolle, Quellcode, Kundendaten oder interne Strategien können in Eingaben landen. Ein Serviceeintrag muss deshalb klar sagen, welche Daten erlaubt sind und welche nicht. Allgemeine Hinweise wie „keine sensiblen Daten eingeben“ helfen nur begrenzt, wenn Nutzer im konkreten Arbeitsfall nicht wissen, ob ein Ticketauszug, ein Log oder eine Kundenbeschreibung schon kritisch ist.

Besser ist eine einfache, betriebsnahe Zuordnung. Erlaubt sind zum Beispiel öffentliche Inhalte, freigegebene Wissensartikel oder anonymisierte Beispiele. Eingeschränkt sind interne Betriebsdaten, Kundendaten, Sicherheitsvorfälle oder personenbezogene Informationen. Verboten sind besonders vertrauliche Daten, Zugangsdaten, Geheimnisse und Inhalte, die regulatorisch nicht verarbeitet werden dürfen. Diese Grenzen müssen dort stehen, wo Nutzer und Support sie finden: im Serviceeintrag, in der Nutzungsanleitung und im Onboarding.

Abschalten ist Teil des Designs

Ein kontrollierter KI-Service braucht einen Abschaltpfad. Das klingt negativ, ist aber ein Zeichen guter Betriebsreife. Wenn ein Anbieter die Bedingungen ändert, ein Modell auffällig falsche Ergebnisse liefert, Kosten aus dem Ruder laufen oder eine Datenfrage ungeklärt ist, muss klar sein, wer die Nutzung einfrieren oder einschränken darf. Ohne diesen Pfad wird jedes Problem zur Ad-hoc-Eskalation.

Der Abschaltpfad muss nicht bedeuten, dass sofort alles aus ist. Es kann abgestufte Maßnahmen geben: neue Nutzer stoppen, bestimmte Datenklassen sperren, eine Funktion nur noch mit Vier-Augen-Prüfung zulassen, Integrationen trennen oder den Dienst vorübergehend aus dem Katalog nehmen. Wichtig ist, dass diese Maßnahmen vorbereitet sind. KI-Governance wird praktisch, wenn der Betrieb nicht erst im Krisenmoment über Zuständigkeit, Kommunikation und Folgen nachdenken muss.

Was jetzt in den Servicekatalog gehört

Der erste Schritt ist eine Bestandsaufnahme der produktiv genutzten KI-Funktionen, nicht nur der offiziell beschafften KI-Plattformen. Dazu gehören Assistenten in Entwicklungswerkzeugen, Zusammenfassungen in Collaboration-Tools, KI-Suche, automatische Ticketklassifikation, Wissensartikel-Generatoren, Chatbots, Analysefunktionen und eingebettete Modelle in SaaS-Produkten. Jede Funktion bekommt eine einfache Entscheidung: eigener Service, Bestandteil eines bestehenden Services oder nicht freigegebene Nutzung.

Danach reicht für den Start ein schlanker Pflichtsatz pro KI-Service: Zweck, Owner, Nutzerkreis, erlaubte Daten, verbotene Daten, Supportweg, Risiko-Review, Kostenverantwortung, Monitoring und Abschaltpfad. Dieser Satz macht aus KI noch keine perfekte Governance. Er verhindert aber, dass Verantwortung zwischen Tool, Fachbereich, Security, Datenschutz und Betrieb verschwindet.

Die technische Nachricht lautet: KI-Funktionen werden immer leichter verfügbar. Die betriebliche Nachricht ist wichtiger: Was produktiv genutzt wird, braucht einen sichtbaren Platz in der Serviceführung. Ein Servicekatalog ist dafür kein bürokratischer Selbstzweck. Er ist die Landkarte, auf der Verantwortung, Grenzen und Hilfe auffindbar bleiben.

Quellen: NIST AI Risk Management Framework; ISO/IEC 42001; Europäische Kommission zum AI Act; Axelos-Beitrag zu KI und ITIL Service Management.