KI-Governance als Entscheidungsarchitektur

Viele Unternehmen behandeln KI-Governance wie eine zweite Tür vor dem Projekt. Der Fachbereich bringt einen Anwendungsfall, IT prüft die Plattform, Legal stellt Fragen, Compliance ergänzt Vorgaben, am Ende entsteht eine Freigabe oder ein Stopp. Das wirkt geordnet, ist aber oft zu langsam für harmlose Fälle und zu oberflächlich für kritische.

Der bessere Ausgangspunkt ist nicht die Frage, wer genehmigt. Der bessere Ausgangspunkt ist die Frage, welche Entscheidung überhaupt ansteht. Ein internes Textwerkzeug ohne personenbezogene oder vertrauliche Daten braucht eine andere Behandlung als ein Agent mit Schreibrechten im ERP. Eine Vertrags-Triage mit menschlicher Prüfung ist etwas anderes als eine automatisierte Kredit- oder Bewerbungsentscheidung. Ein einheitlicher Prüfprozess verdeckt diese Unterschiede.

Governance muss drei Dinge gleichzeitig leisten: Geschwindigkeit für niedrige Risiken, Aufmerksamkeit für hohe Risiken und eindeutige Verantwortlichkeit für den Betrieb. Genau darin liegt der Managementwert. Sie ersetzt nicht die Use-Case-Prüfung und nicht den Business Case. Sie entscheidet, unter welchen Bedingungen ein wirtschaftlich plausibler Fall überhaupt produktionsfähig wird.

1. Inventar vor Policy

Der erste Governance-Baustein ist ein KI-Inventar. Nicht als Verwaltungsfriedhof, sondern als Arbeitsregister. Es erfasst, welche KI-Systeme, Modelle, Agenten, Assistenten und eingebetteten KI-Funktionen im Unternehmen genutzt oder geplant sind.

Das Register muss nicht mit fünfzig Feldern starten. Für die Entscheidung reichen am Anfang wenige Angaben: Zweck, Fachbereich, betroffene Daten, Modell oder Anbieter, Nutzergruppe, Autonomiegrad, externe Wirkung, menschliche Prüfung, Verantwortliche, Status und Risikoeinstufung. Ohne diese Übersicht sieht Governance nur die offiziell eingereichten Projekte. Die tatsächliche Nutzung findet dann an ihr vorbei statt.

Ein gutes Inventar ist deshalb auch ein Frühwarnsystem. Es zeigt, wo ähnliche Fälle mehrfach entstehen, wo dieselben Risiken wiederkehren und wo aus einem einmal geprüften Muster ein Playbook werden kann. Genau dort gewinnt Governance Geschwindigkeit.

2. Vier Lanes statt Einheitsprüfung

BCG beschreibt für KI-Risikomanagement eine vierstufige Triage: Self-Service, Trust but Verify, Strategic Review und Prohibited. Als typische Richtwerte nennt BCG mindestens rund 75 Prozent Self-Service-Fälle, bis zu 20 Prozent Trust but Verify, 5 bis 15 Prozent Strategic Review und unter 1 Prozent Prohibited. Das sind BCG-Richtwerte, keine Sixtyfour-Erhebung. Die Logik ist für C-Level-Entscheidungen brauchbar, weil sie Risiko und Geschwindigkeit zusammenbringt. Nicht jeder Fall braucht dieselbe Prüftiefe. Aber jeder Fall braucht eine klare Zuordnung.

Lane	Typische Fälle	Entscheidung	Kontrolle
Self-Service niedriges Risiko	Interne Entwürfe, Zusammenfassungen, Recherchehilfen ohne vertrauliche oder personenbezogene Entscheidungswirkung.	Kein Freigabegremium. Nutzung nach Standardregeln, Eintrag im Inventar, klare Verbote für Daten und Outputs.	Policy, kurze Schulung, Stichproben, Tool- und Datenfreigaben.
Trust but Verify bekanntes Risiko	Wiederholbare Muster mit bewährten Gegenmaßnahmen: RAG gegen freigegebene Wissensbasis, Support-Entwürfe, Chatbot-Erweiterungen.	Fachbereich und IT dürfen umsetzen, wenn dokumentierte Mitigations erfüllt sind.	Unabhängiger Check nach Playbook, Logging, Qualitätsmessung und Eskalationsweg.
Strategic Review neu oder hochwirksam	Neue Risikomuster, regulierte Prozesse, personenbezogene oder externe Wirkung, Agenten mit Schreibrechten, Einsatz in HR, Kredit, Recht oder Compliance.	Formale Entscheidung durch Business, IT, Risk/Compliance und gegebenenfalls Legal oder Datenschutz.	Dokumentierte Risikoabwägung, Testplan, Human Oversight, Incident-Flow und Stage-Gate vor Produktivsetzung.
Prohibited nicht akzeptabel	Fälle gegen gesetzliche Verbote, Unternehmenswerte oder Risikobereitschaft; etwa autonome Änderungen an Kundenkonten oder Transaktionen ohne menschliche Freigabe.	Ablehnen, nicht auf eine spätere Prüfung vertagen.	Vorab im KI-Verhaltenskodex dokumentieren und technisch blockieren, wo möglich.

Die Lanes sind keine Bürokratie-Etiketten. Sie definieren Entscheidungsrechte. Ein Self-Service-Fall soll nicht wochenlang warten. Ein Strategic-Review-Fall soll nicht als schneller Pilot am Kontrollsystem vorbeilaufen. Ein Prohibited-Fall soll nicht in einem Workshop wiederbelebt werden, nur weil der Use Case geschäftlich reizvoll klingt.

3. Rollen müssen Entscheidungen tragen

KI-Governance wird schwach, wenn Verantwortung zwischen Gremien verdampft. Für jeden produktiven Fall braucht es mindestens drei benannte Rollen.

Business-Verantwortlicher: Zweck, Nutzen, Prozessänderung, Budget und fachliche Folgen.
Technischer Verantwortlicher: Architektur, Datenzugriff, Modell, Sicherheit, Integration, Monitoring und Betrieb.
Risk-/Compliance-Verantwortlicher: Risikoklassifizierung, Datenschutz, regulatorische Anforderungen, Kontrollnachweise und Eskalation.

Diese Rollen ersetzen kein Gremium. Sie verhindern, dass ein Gremium die eigentliche Verantwortung übernimmt. Das Gremium sollte Grenzfälle entscheiden und Standards setzen. Der Betrieb braucht Personen, die Entscheidungen treffen dürfen und später für die Folgen ansprechbar bleiben.

4. Menschliche Aufsicht ist kein Häkchen

Human-in-the-Loop klingt beruhigend und ist oft die schwächste Stelle im Design. Ein Mensch am Ende der Kette verbessert wenig, wenn er keine Zeit hat, den Output nicht versteht, keine Gegeninformation sieht oder organisatorisch dafür bestraft wird, die Maschine zu überstimmen.

Der EU AI Act verlangt für Hochrisiko-KI wirksame menschliche Aufsicht. Der EDPS weist unabhängig davon auf ein praktisches Problem hin: Das bloße Einschalten eines Menschen reicht nicht; Aufsicht braucht Design, Kompetenz, Zeit, Autorität und Eingriffsmöglichkeiten. Dazu gehört ein Interface, das Zweifel erleichtert statt Zustimmung zu erzwingen.

Für die Governance-Architektur heißt das: Human Oversight nur dort versprechen, wo sie materiell gestaltet ist. Bei niedrigen Risiken reichen oft Stichproben. Bei hoher Außenwirkung braucht es Freigaben, Gegenprüfung, Eskalation oder Vier-Augen-Prinzip. Bei Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung reicht ein formales Abnicken nicht.

5. Logging, Audit Trail und Incident-Flow gehören vor den Rollout

Viele KI-Projekte dokumentieren den Start und vergessen den Betrieb. Für Management und Aufsicht zählt aber nicht nur, wer den Fall freigegeben hat. Entscheidend ist, ob später rekonstruierbar bleibt, was das System getan hat, welche Daten es verwendet hat, welche Version aktiv war, wer geprüft hat und wie auf Fehler reagiert wurde.

Für Hochrisiko-KI enthält der EU AI Act konkrete Anforderungen an Risikomanagement (Art. 9), technische Dokumentation (Art. 11), Logging (Art. 12), Transparenz und Information (Art. 13), menschliche Aufsicht (Art. 14) sowie Genauigkeit, Robustheit und Cybersicherheit (Art. 15). Nicht jeder interne KI-Fall ist Hochrisiko. Trotzdem ist die Managementlogik übertragbar: Produktivsetzung ohne Prüfspur ist bei KI eine bewusste Schwächung der eigenen Verteidigungsfähigkeit.

Der Incident-Flow muss vor Go-live stehen. Was passiert bei Datenabfluss, systematischer Falschinformation, Diskriminierungsverdacht, Prompt Injection, unzulässiger Tool-Aktion oder Vendor-Störung? Wer stoppt das System? Wer informiert Fachbereich, IT, Datenschutz, Legal, Kunden oder Aufsicht? Wer entscheidet über Wiederinbetriebnahme? Ohne diese Antworten ist ein produktiver Rollout nur ein Pilot mit größerem Risiko.

6. Stage-Gate vor Produktivsetzung

Der Governance-Gate liegt nach dem Pilot und vor der Produktivsetzung. Er prüft nicht, ob die Demo funktioniert. Er prüft, ob der Fall unter realen Bedingungen verantwortbar betrieben werden kann.

Ist der Use Case im Inventar erfasst und richtig klassifiziert?
Sind Datenzugriff, Modell, Anbieter und Betriebsort dokumentiert?
Gibt es einen Business-Verantwortlichen, technischen Verantwortlichen und Risk-/Compliance-Verantwortlichen?
Sind Qualitätsmetriken, Fehlerschwellen und Review-Regeln definiert?
Ist menschliche Aufsicht dort, wo sie behauptet wird, tatsächlich ausführbar?
Existieren Logs, Audit Trail, Incident-Flow und Stopprecht?
Ist die wirtschaftliche Logik aus dem Business Case nach dem Pilot noch tragfähig?

Wenn mehrere Antworten offen bleiben, ist der Fall nicht produktionsreif. Das ist keine Compliance-Verzögerung. Es ist ein Managementsignal. Der Pilot hat dann gezeigt, welche organisatorische Vorarbeit fehlt.

Entscheidungsvorlage für Geschäftsführung, CIO, CFO und Compliance

Eine Governance-Vorlage muss kurz genug sein, um entschieden zu werden. Sie sollte nicht alle Rechtsfragen lösen. Sie muss die richtige Eskalation auslösen.

Feld	Leitfrage	Stoppsignal
Zweck Use Case und Wirkung	Welche Entscheidung, Handlung oder Arbeit wird durch KI unterstützt oder automatisiert?	Der Fall ist als Tool-Nutzung beschrieben, nicht als Geschäftsprozess.
Lane Risikotriage	Self-Service, Trust but Verify, Strategic Review oder Prohibited?	Niemand kann begründen, warum der Fall nicht höher eingestuft wird.
Daten Zugriff und Schutz	Welche Daten werden genutzt, wer darf sie sehen, und welche Daten dürfen nie in das System?	Berechtigungen werden erst im Pilot geklärt.
Verantwortung Business, Technik, Risiko	Wer entscheidet fachlich, wer betreibt technisch, wer bewertet Risiko und Compliance?	Verantwortung liegt bei einem Projektteam oder Gremium ohne benannte Person.
Aufsicht Menschliche Kontrolle	An welcher Stelle kann ein Mensch verstehen, widersprechen, stoppen oder eskalieren?	Human-in-the-Loop bedeutet nur finale Zustimmung.
Betrieb Logs und Incident-Flow	Welche Ereignisse werden geloggt, wer sieht Abweichungen, und was passiert bei einem Vorfall?	Monitoring, Logs oder Notfallabschaltung sind nicht Teil des Go-live-Plans.

Drei Fehler, die sich wiederholen

Governance erst nach Go-live. Dann sind Datenpfade, Rechte, Verantwortlichkeiten und Lieferantenentscheidungen meist schon faktisch gesetzt. Nachträgliche Governance ist teurer und politischer als Governance vor dem Pilot.
Alles durch ein Gremium schleusen. Ein Gremium kann Standards setzen und Grenzfälle entscheiden. Es darf nicht jede harmlose Nutzung verlangsamen. Sonst steigt genau der Anreiz zur Schatten-KI, die Governance verhindern soll.
Human-in-the-Loop als Abnicken missverstehen. Menschliche Kontrolle ist nur dann belastbar, wenn Menschen Zeit, Kompetenz, Autorität und echte Eingriffsmöglichkeiten haben. Alles andere ist ein Haftungsritual.

Damit ergänzt Governance die bestehende Praxis-Reihe. Erst werden tragfähige KI-Use-Cases identifiziert. Dann wird die wirtschaftliche Logik im Business Case geprüft. Governance entscheidet anschließend, welche Fälle schnell laufen dürfen, welche in die harte Prüfung gehören und welche gar nicht erst starten. Die technische Modell- und Betriebsfrage bleibt damit verbunden, wie die Modellstrategie für europäische Unternehmen zeigt. Ohne diese Reihenfolge entstehen die Muster aus gescheiterten KI-Piloten: funktionierende Technologie, aber keine tragfähige Entscheidung.