Wer erklärt im Audit, warum eine KI freigegeben wurde?

Eine KI-Anwendung kann fachlich sinnvoll, technisch stabil und im Pilotbetrieb überzeugend sein. Für ITSM und IT-Governance reicht das trotzdem nicht. Spätestens im Audit zählt nicht nur, dass jemand die Nutzung erlaubt hat, sondern warum diese Freigabe nachvollziehbar war.

KI-Governance beschreibt Regeln, Rollen und Kontrollen für den verantwortlichen Einsatz künstlicher Intelligenz. Sie soll nicht Innovation verhindern, sondern Risiken sichtbar machen: falsche Ergebnisse, Datenschutzprobleme, fehlende Zuständigkeit, ungeprüfte Automatisierung oder unklare Haftung. Für ITSM-Generalisten wird daraus eine praktische Betriebsfrage. Wer kann später erklären, welche KI wofür freigegeben wurde und welche Grenzen dabei galten?

Eine Freigabe ist kein Haken am Formular

In vielen Organisationen beginnt die KI-Freigabe mit einem Antrag. Ein Fachbereich beschreibt den Zweck, die IT prüft technische Anforderungen, Datenschutz und Security liefern Hinweise, das Management entscheidet über Nutzen und Risiko. Auf dem Papier wirkt dieser Ablauf sauber. Problematisch wird es, wenn am Ende nur ein Status übrig bleibt: genehmigt.

Ein solcher Haken hilft im Betrieb kaum. Er sagt nicht, welche Daten verarbeitet werden dürfen, welche Ausgabe ein Mensch prüfen muss, welche Fehler tolerierbar sind oder wann die Freigabe erneut bewertet werden muss. Genau diese Details werden später wichtig, wenn eine Beschwerde, ein Sicherheitsvorfall, ein Modellwechsel oder ein Audit nach der Begründung fragt.

Der Zweck muss überprüfbar bleiben

Jede KI-Freigabe braucht einen klaren Zweck. Nicht nur eine Überschrift wie Assistenzsystem, Chatbot oder Analysewerkzeug, sondern eine beschriebene Aufgabe im Arbeitsalltag. Soll die KI Tickets zusammenfassen, Antworten vorschlagen, Vertragsdaten auswerten, Störungen priorisieren oder Wissensartikel vorbereiten? Diese Unterscheidung entscheidet über Risiko und Kontrolle.

Ohne präzisen Zweck wird die Freigabe zu breit. Ein Tool, das für interne Zusammenfassungen erlaubt wurde, wird plötzlich für Kundenantworten genutzt. Ein Modell, das nur Vorschläge liefern sollte, beeinflusst operative Entscheidungen. Ein Pilot, der mit Testdaten gestartet ist, verarbeitet später echte personenbezogene Informationen. Die Prüfspur muss deshalb zeigen, für welchen Einsatz die Freigabe galt und was ausdrücklich nicht freigegeben war.

Risiken brauchen Besitzer, nicht nur Hinweise

Risikohinweise sind schnell geschrieben. Schwieriger ist die Frage, wer sie im Alltag trägt. Wenn die KI falsche Ergebnisse liefert, wer erkennt das? Wenn vertrauliche Daten in Prompts landen, wer stoppt die Nutzung? Wenn ein Anbieter die Modellversion ändert, wer bewertet die Folgen für bestehende Prozesse? Governance bleibt schwach, wenn solche Punkte nur als allgemeine Warnung dokumentiert sind.

Eine belastbare Freigabe benennt deshalb Verantwortliche. Der Fachbereich besitzt den Anwendungszweck. Die IT besitzt Integration, Betrieb und technische Grenzen. Security bewertet Missbrauchs- und Zugriffsszenarien. Datenschutz prüft personenbezogene Daten und Löschlogik. Der Service Desk braucht klare Hinweise, welche Nutzerfragen er beantworten darf und wann eine Eskalation nötig ist.

Kontrollen müssen zur Nutzung passen

Nicht jede KI-Anwendung braucht dieselbe Kontrolltiefe. Ein internes Werkzeug, das lange Texte für Mitarbeitende zusammenfasst, hat andere Anforderungen als eine Automatisierung, die Supportfälle priorisiert oder Kundentexte vorbereitet. Entscheidend ist, ob die Kontrolle zur tatsächlichen Wirkung passt.

Praktische Kontrollen können einfach beginnen: menschliche Prüfung vor externen Antworten, Verbot bestimmter Datentypen, Pflicht zur Quellenanzeige, Stichproben durch Prozessverantwortliche, Logging von Modellversionen oder ein Review nach jeder wesentlichen Änderung. Wichtig ist nicht die Menge der Maßnahmen, sondern die Verbindung zwischen Risiko, Kontrolle und Verantwortlichem. Ein Audit muss später erkennen können, warum genau diese Kontrolle gewählt wurde.

Änderungen sind der gefährliche Moment

Eine Freigabe altert. Anbieter ändern Modelle, Schnittstellen oder Nutzungsbedingungen. Fachbereiche erweitern den Einsatz. Neue Datenquellen kommen hinzu. Prozesse verändern sich. Was am ersten Tag vertretbar war, kann nach einigen Monaten ein anderes Risikoprofil haben.

Darum gehört zu jeder KI-Freigabe ein Änderungsanlass. Eine neue Modellversion, ein neuer Datentyp, ein Wechsel von interner zu externer Nutzung, ein höherer Automatisierungsgrad oder ein auffälliger Fehler im Betrieb sollten automatisch eine erneute Prüfung auslösen. Ohne diese Regel wird die ursprüngliche Freigabe zur dauerhaften Blanko-Erlaubnis.

Die Prüfspur muss für Nicht-Spezialisten lesbar sein

Auditfähigkeit entsteht nicht durch technische Logdateien allein. Ein Prüfer, eine Führungskraft oder ein ITSM-Verantwortlicher muss den Entscheidungsweg verstehen können. Welche Anfrage lag vor? Welche Risiken wurden gesehen? Welche Alternativen wurden verworfen? Welche Bedingungen wurden gesetzt? Wer hat zugestimmt und auf welcher Grundlage?

Diese Fragen lassen sich in einer einfachen Freigabedokumentation abbilden. Sinnvoll sind Felder für Zweck, Datenarten, Nutzergruppe, erwarteten Nutzen, Hauptrisiken, Kontrollen, Verantwortliche, Änderungsanlässe, Review-Termin und Entscheidungsgrund. Ergänzend helfen Verweise auf Datenschutzprüfung, Security-Bewertung, Anbieterunterlagen und Betriebsanleitung. So entsteht eine Spur, die nicht nur juristisch, sondern auch operativ lesbar bleibt.

ITSM macht KI-Governance betrieblich

Für ITSM liegt der Wert nicht darin, ein weiteres Genehmigungsformular zu bauen. Der Wert liegt darin, KI-Freigaben mit dem laufenden Betrieb zu verbinden. Ein freigegebenes KI-Werkzeug braucht Supporthinweise, Änderungsmanagement, Störungswege, Kommunikationsregeln und eine klare Rücknahmeoption, wenn die Nutzung nicht mehr sicher oder zweckgerecht ist.

Die wichtigste Prüffrage lautet deshalb nicht: Ist die KI erlaubt? Sie lautet: Kann die Organisation später erklären, warum sie erlaubt wurde, welche Grenzen galten und wer bei Problemen handeln muss? Wer diese Antwort dokumentiert, macht aus KI-Governance kein Bremssystem, sondern eine belastbare Betriebsgrundlage.

Quellen und Einordnung: NIST AI Risk Management Framework, IBM AI Governance, ENISA zu KI-Cybersicherheitsrisiken, Europäische Kommission zum AI Act. Bildquelle: Pexels, Foto-ID 955390. Stand der Quellenprüfung: 01.07.2026.