Ein Stoppschalter macht KI-Piloten erst betriebssicher

Ein KI-Pilot fühlt sich oft ungefährlich an. Ein kleines Team testet ein Assistenzwerkzeug, ein Chatbot beantwortet interne Fragen oder ein Modell sortiert Anfragen vor. Solange niemand von einem produktiven Service spricht, wirken Regeln, Notfallwege und Zuständigkeiten schnell übertrieben. Genau dort entsteht aber das spätere Betriebsproblem: Aus einem Experiment wird schleichend ein Arbeitsmittel, ohne dass der Servicebetrieb dieselbe Kontrolle bekommt wie bei anderer geschäftskritischer Software.

Kurz gesagt Ein KI-Pilot ist ein begrenzter Praxistest für ein System, das Aufgaben mit künstlicher Intelligenz unterstützt oder automatisiert. Er soll Nutzen, Grenzen und Risiken sichtbar machen, bevor ein Einsatz in den Alltag rutscht. Für ITSM-Generalisten ist das relevant, weil KI nicht nur eine Fachbereichsidee ist. Sobald Mitarbeitende, Kunden, Tickets, Wissensdatenbanken oder Entscheidungen betroffen sind, braucht der Betrieb klare Stoppsignale, Verantwortliche und nachvollziehbare Spuren.

Der NIST AI Risk Management Framework beschreibt KI-Risiko als Führungs- und Betriebsaufgabe, nicht nur als Modelltechnik. Die EU erklärt mit ihrem KI-Regelwerk risikobasierte Anforderungen an bestimmte KI-Systeme, und ISO/IEC 42001 ordnet Managementsysteme für künstliche Intelligenz. Für itsm.news ist daran vor allem die betriebliche Konsequenz wichtig: Wer KI testet, muss früh wissen, was passieren darf, was nicht passieren darf und wer einen Einsatz zurücknimmt, wenn die Grenze erreicht ist.

Der Pilotstatus darf kein Schutzschild sein

In vielen Organisationen entsteht die riskanteste Phase nicht beim offiziellen Rollout, sondern davor. Ein Pilot bekommt echte Daten, echte Nutzer und echte Erwartungen. Gleichzeitig fehlen oft die harten Fragen: Ist der Dienst im Servicekatalog sichtbar? Gibt es eine verantwortliche Rolle? Welche Daten dürfen eingegeben werden? Wer prüft falsche Antworten? Wo melden Nutzer einen Schaden oder eine Unsicherheit?

Der Begriff Pilot darf deshalb nicht bedeuten, dass der Betrieb wegschaut. Er sollte das Gegenteil auslösen. Ein Pilot braucht eine engere Beobachtung, weil noch nicht klar ist, wie stabil, nützlich und kontrollierbar das Werkzeug im Alltag wirklich ist. Der Status muss zeitlich, fachlich und technisch begrenzt sein. Sonst wird aus Testbetrieb eine Schattenproduktion.

Ein Stoppschalter ist mehr als ein technischer Aus-Knopf

Ein echter Stoppschalter besteht aus mehreren Teilen. Technisch muss ein Zugang deaktiviert, eine Integration getrennt oder ein Workflow auf den alten Weg zurückgestellt werden können. Organisatorisch muss klar sein, wer diese Entscheidung treffen darf. Kommunikativ muss bekannt sein, welche Nutzer informiert werden und welche Antwort der Support gibt. Fachlich muss feststehen, ab welchem Fehlerbild der Pilot pausiert.

Gerade KI-Systeme erzeugen nicht immer einen klassischen Ausfall. Sie können erreichbar sein und trotzdem falsche, unsichere oder nicht belegbare Ergebnisse liefern. Deshalb reicht ein grünes Monitoring nicht aus. Der Betrieb braucht Qualitätsgrenzen: Welche Antworttypen sind kritisch? Welche Daten dürfen nicht verarbeitet werden? Welche Rückfragen müssen an Menschen gehen? Welche Protokolle zeigen später, was das System getan hat?

Datenwege entscheiden über das Risiko

KI-Piloten wirken oft wie eine reine Benutzeroberfläche. Im Hintergrund geht es aber um Datenwege. Ein Modell liest Dokumente, greift auf eine Wissensbasis zu, verarbeitet Tickets oder erhält Prompts mit internen Informationen. Für ITSM zählt deshalb nicht nur, ob das Werkzeug bequem ist. Entscheidend ist, welche Daten hineinfließen, welche Ergebnisse herauskommen und ob der Weg dokumentiert ist.

Ein sauberer Pilot trennt Testdaten, produktive Daten und besonders schützenswerte Informationen. Er beschreibt, welche Quellen erlaubt sind, wie lange Protokolle gespeichert werden und wer Zugriff auf Auswertungen bekommt. Ohne diese Ordnung kann niemand belastbar sagen, ob ein Fehler nur peinlich, betrieblich störend oder rechtlich heikel ist.

Der Service Desk braucht klare Antwortgrenzen

Sobald ein KI-Werkzeug im Alltag genutzt wird, landen Rückfragen beim Support. Nutzer fragen, warum eine Antwort falsch war, warum eine Datei nicht gefunden wurde oder ob sie dem Vorschlag folgen dürfen. Wenn der Service Desk dann nur auf das Projektteam verweist, entsteht Reibung. Der Betrieb braucht deshalb einfache Antwortgrenzen schon während des Piloten.

Dazu gehören typische Fehlerbilder, erlaubte Workarounds, Eskalationswege und Formulierungen für Nutzer. Ein Satz wie „Das ist nur ein Pilot“ hilft im Störungsfall wenig. Besser ist eine konkrete Aussage: Welche Funktion ist betroffen, welche Alternative ist gültig, ob Ergebnisse nachgeprüft werden müssen und wann der Pilot wieder freigegeben wird.

Metriken müssen Nutzung und Schaden sichtbar machen

Klassische Betriebsmetriken erfassen Verfügbarkeit, Antwortzeit und Fehlercodes. Bei KI-Piloten reicht das nicht. Der Betrieb sollte zusätzlich wissen, welche Aufgaben das Werkzeug übernimmt, wie häufig Nutzer Ergebnisse korrigieren, welche Antworten eskalieren, welche Datenquellen Probleme machen und ob der Nutzen die zusätzliche Kontrolle rechtfertigt.

Diese Metriken müssen nicht kompliziert sein. Eine kurze Liste mit Nutzungsfällen, Fehlertypen, Korrekturen und Stoppsignalen kann mehr helfen als ein großes Dashboard ohne Entscheidung. Wichtig ist, dass die Daten regelmäßig besprochen werden. Ein Pilot, der keine Lernschleife hat, ist kein Pilot. Er ist nur ein ungeprüfter Vorlauf zur Produktion.

Vom Experiment zum Service braucht es ein Gate

Der Übergang in den Regelbetrieb sollte nicht beiläufig passieren. Vor dem Rollout braucht es ein klares Gate. Sind Zweck und Nutzergruppe beschrieben? Sind Datenquellen freigegeben? Gibt es einen Menschen für kritische Entscheidungen? Kann der Pilot gestoppt werden? Sind Supportantworten vorbereitet? Sind Protokolle und Verantwortlichkeiten nachvollziehbar?

Diese Fragen bremsen KI nicht aus. Sie verhindern, dass ein nützliches Werkzeug an fehlender Betriebsreife scheitert. Der beste KI-Pilot ist nicht der, der möglichst schnell größer wird. Es ist der, der seinen Nutzen zeigt, seine Grenzen offenlegt und einen sicheren Rückweg kennt. Erst dann wird aus einer guten Idee ein belastbarer Service.

Stand der Quellenprüfung: 21.06.2026. Der Beitrag enthält keine konkreten Beträge oder Leistungssätze.