KI-Governance: Leitplanken, die im Betrieb greifen

Was KI im Servicebetrieb anders macht

Klassische Software liefert bei gleicher Eingabe dasselbe Ergebnis, und wenn sie es nicht mehr tut, gab es eine Änderung, die im Change Record steht. Bei einem KI-gestützten Service kann sich die Antwortqualität verschieben, ohne dass jemand eingegriffen hat: Die Datengrundlage altert, die Art der Nutzung verschiebt sich, oder der Anbieter tauscht ein Modell aus.

Das bricht eine stillschweigende Annahme im Servicebetrieb. Ein Ausfall ist erkennbar, eine schleichend schlechter werdende Antwort ist es nicht. Wer nicht misst, erfährt davon durch Beschwerden, und zwar erst, wenn die Fachseite dem Ergebnis schon nicht mehr traut.

Die zweite Besonderheit ist die Zurechenbarkeit. Wenn ein Modell eine Entscheidung vorbereitet hat, muss nachvollziehbar bleiben, welche Daten dafür herangezogen wurden und wer das Ergebnis bestätigt hat. Ohne diese Spur ist im Nachhinein weder eine Korrektur noch eine Erklärung möglich.

Governance ist die Verteilung von Entscheidungsrechten

Der häufigste Fehlgriff ist eine Richtlinie ohne Zuständigkeiten. Ein Dokument, das den verantwortungsvollen Umgang beschreibt, verändert nichts, solange nicht festgelegt ist, wer einen Anwendungsfall freigibt, wer widersprechen kann und wer den Betrieb stoppen darf.

Nützlich ist stattdessen eine kurze Aufstellung je Thema: wer entscheidet, wer setzt um, was ist die typische Stolperfalle. Diese Aufstellung passt auf eine Seite und ist damit die einzige Fassung, die tatsächlich gelesen wird. Alles Weitere gehört in die Verfahrensbeschreibungen der beteiligten Practices.

Dazu kommt eine Regel für den Einstieg. Werkzeuge mit KI-Funktionen kommen heute meist über bestehende Abonnements ins Haus und nicht über Beschaffungsprojekte. Wer erst bei der Freigabe eines eigenen Anwendungsfalls ansetzt, hat den größten Teil der tatsächlichen Nutzung nie gesehen.

Wo KI die bestehenden Practices berührt

Change Enablement muss klären, ob der Wechsel eines Modells oder eine veränderte Anweisung an das Modell eine Änderung im Sinne des Verfahrens ist. Die naheliegende Antwort ist ja, und dann braucht es dafür ein eigenes Change-Modell, sonst entsteht ein Bereich, in dem sich Verhalten unkontrolliert verschiebt.

Incident Management braucht eine Definition dafür, was eine Störung ist, wenn der Service verfügbar ist und trotzdem falsche Ergebnisse liefert. Ohne diese Definition landet der Fall zwischen Support und Fachseite und wird als Meinungsverschiedenheit behandelt. Problem Management braucht im Gegenzug eine Analysemethode, die mit einem statistischen Fehlerbild umgehen kann und nicht mit einer einzelnen Fehlerursache rechnet.

Service Configuration Management stellt die Frage, was hier eigentlich ein Configuration Item ist. Sinnvoll sind mindestens das eingesetzte Modell samt Version, die verwendeten Datenquellen und die hinterlegten Anweisungen, denn genau diese drei bestimmen das Ergebnis und ändern sich unabhängig voneinander.

Welche Zusagen möglich sind und welche nicht

Eine Zusage über die Richtigkeit einzelner Antworten lässt sich nicht geben, eine Zusage über die Verfügbarkeit des Dienstes dagegen schon. Dazwischen liegt der Bereich, der tatsächlich vereinbart werden kann: dass in einem definierten Umfang geprüft wird, dass Abweichungen gemeldet werden und dass es einen Weg gibt, ein Ergebnis anzufechten.

Für die Überwachung im Betrieb braucht es mindestens eine regelmäßige Stichprobe mit menschlicher Bewertung, deren Ergebnis über die Zeit vergleichbar bleibt. Erst diese Reihe zeigt eine schleichende Verschlechterung. Dazu kommen die Zahlen, die ohnehin anfallen: wie oft Ergebnisse verworfen oder korrigiert werden und wie oft ein Fall an einen Menschen weitergereicht wird.

Der Andockpunkt ISO/IEC 42001

ISO/IEC 42001 beschreibt ein Managementsystem für künstliche Intelligenz. Der Aufbau folgt derselben Struktur wie andere Managementsystemnormen, also Kontext der Organisation, Führung, Planung, Unterstützung, Betrieb, Bewertung der Leistung und Verbesserung. Wer bereits nach ISO/IEC 27001 arbeitet, kennt diesen Rahmen und kann Nachweise, Audits und Termine gemeinsam führen.

Für den Servicebetrieb sind zwei Bestandteile besonders greifbar: die Kontrollmaßnahmen im Anhang der Norm samt den zugehörigen Umsetzungshinweisen und die Folgenabschätzung für KI-Systeme, die vor der Einführung fragt, wen das System betrifft und was schiefgehen kann. Beides lässt sich an vorhandene Verfahren hängen, statt daneben ein zweites System aufzubauen.

Ob eine Zertifizierung sinnvoll ist, hängt davon ab, ob jemand den Nachweis verlangt. Die Struktur der Norm ist auch ohne Zertifikat brauchbar, weil sie eine vollständige Liste der Fragen liefert, die sonst einzeln und verspätet auftauchen. Regulatorische Anforderungen sind eine eigene Baustelle, die Norm liefert aber den Ort, an dem sie sich später einhängen lassen.