# AI Governance ist Vorstandsarbeit > Wer KI in einem Unternehmen betreibt, hat eine Governance-Pflicht, die nicht beim Datenschutz endet. Vier Bausteine einer AI-Policy, ein Berichtszyklus für den Vorstand und die Frage, wer im Unternehmen die letzte Entscheidung trifft. Veröffentlicht: 2026-09-16 Wer KI in einem Unternehmen betreibt, erlebt in den ersten zwölf Monaten einen Moment, der nicht im Business-Case stand: eine Frage aus dem Vorstand, die nicht zu beantworten ist. Wer diese Modelle nutzt, soll das auch weiterhin tun? Wer haftet, wenn ein Output falsch ist? Wer entscheidet, welche Daten das Modell sehen darf? Die Antworten auf diese Fragen stehen nicht in der Architektur und nicht im Vertrag, sie stehen in einer AI-Policy, die in den meisten Unternehmen nicht existiert. Diese Lücke zwischen Technik und Verantwortung ist das Thema dieses Beitrags. Wer die Beschaffungsseite kennt, der findet sie in [KI-Beschaffung ohne Lock-in](/posts/beschaffung-und-lock-in/), wer die Risikoseite kennt, der findet sie in [Tail Risk in der KI-Adoption](/posts/tail-risk-ki/), und wer über Investitions-Reporting nachdenkt, dem hilft [Wann eine KI-Investition sich rechnet](/posts/roi-von-ki-investitionen/) weiter. Was fehlt, ist die Brücke zwischen diesen Punkten: die Governance, die alles zusammenhält. ## Auf den Punkt Wer die nächsten fünf Minuten nicht hat: **AI Governance ist keine Compliance-Funktion, sondern eine Vorstandsfunktion.** Wer KI betreibt, hat vier Bausteine, die in einer Policy stehen müssen: Use-Case-Klassifikation, Datenklassifikation, Modell-Substitution, Audit-Trail. Wer auf einen dieser Bausteine verzichtet, hat nach dem ersten Vorfall eine Krise, die der Vorstand managen muss, statt eine Antwort, die der Vorstand geben kann. Die Policy gehört in den Vorstand, nicht in die IT-Abteilung. ## Glossar {% definition term="AI-Policy" description="Das Dokument, das regelt, wie KI in einem Unternehmen eingesetzt wird. Eine AI-Policy ist kein technisches Dokument, sondern ein Verhaltensdokument, das Use-Cases klassifiziert, Daten klassifiziert, Modelle substituiert und Audit-Trails definiert. Wer keine AI-Policy hat, hat die Regeln des Anbieters übernommen, ohne es zu wissen." /} {% definition term="Use-Case-Klassifikation" description="Die Einteilung von KI-Anwendungsfällen in Risikoklassen, typischerweise niedrig, mittel und hoch. Eine Use-Case-Klassifikation ist die Grundlage jeder AI-Policy, weil sie bestimmt, welche Review-Disziplin, welcher Audit-Trail und welche Vorab-Genehmigung ein Use-Case braucht." /} {% definition term="Datenklassifikation" description="Die Einteilung der Daten, die ein KI-System verarbeitet, in Klassen wie öffentlich, intern, vertraulich und reguliert. Eine Datenklassifikation entscheidet, welche Modelle überhaupt eingesetzt werden dürfen und welche vertraglichen Anforderungen an den Anbieter gestellt werden müssen." /} {% definition term="Modell-Substitution" description="Die vertragliche und technische Möglichkeit, ein KI-Modell gegen ein gleichwertiges Modell auszutauschen, ohne die Anwendung neu zu zertifizieren. Modell-Substitution ist nicht nur Beschaffungsthema, sondern auch Governance-Thema, weil die Substitution selbst eine Entscheidung ist, die jemand verantworten muss." /} {% definition term="Audit-Trail" description="Die lückenlose Aufzeichnung aller Eingaben, Ausgaben und Zustandsänderungen eines KI-Systems. Ein Audit-Trail ist die Versicherung, die den Unterschied zwischen einer zweistündigen Klärung und einer sechswöchigen Untersuchung ausmacht. Wer keinen Audit-Trail hat, hat im ersten Vorfall keine Antwort." /} {% definition term="Accountability" description="Die klare Zuordnung von Verantwortung für eine KI-Entscheidung. Accountability ist nicht Delegation, sondern Zurechnung. Wer ein KI-System betreibt, muss eine Person benennen, die im Fall eines Vorfalls die Verantwortung übernimmt, nicht das Unternehmen, nicht der Anbieter." /} ## Was AI Governance nicht ist In den meisten Unternehmen, die ich in den letzten Monaten gesehen habe, ist AI Governance in der Datenschutzabteilung verortet. Das ist verständlich, weil Datenschutz die etablierte Disziplin für Daten-Risiken ist, und KI scheint auf den ersten Blick ein Daten-Risiko zu sein. Diese Verortung ist falsch, und zwar aus einem Grund, der in der Datenschutz-Logik keine Rolle spielt: ein KI-System entscheidet. Datenschutz schützt Daten vor Missbrauch. AI Governance schützt Entscheidungen vor Fehlern. Die beiden Disziplinen überlappen sich an der Schnittstelle, wo Daten in Entscheidungen einfliessen, aber sie sind nicht dasselbe. Wer AI Governance in der Datenschutzabteilung verortet, hat eine Governance, die Datenrisiken sieht, aber Entscheidungsrisiken übersieht. Die Konsequenz zeigt sich in der Praxis. In den Vorfällen, die in den letzten zwölf Monaten öffentlich geworden sind, war der Datenschutz fast immer sauber, und die Entscheidungslogik fast immer das Problem. Wer eine KI-Antwort ausgibt, die diskriminierend ist, hat ein Decision-Risk, kein Data-Risk. Wer eine KI-Antwort ausgibt, die falsch ist, hat ein Decision-Risk. Wer eine KI-Antwort ausgibt, die einen Vertrag verändert, hat ein Decision-Risk. AI Governance gehört deshalb in den Vorstand, nicht in die IT-Abteilung und nicht in die Datenschutzabteilung. Die Frage, die AI Governance beantwortet, ist nicht, ob die Daten sicher sind, sondern ob das Unternehmen die Entscheidungen, die das KI-System trifft, verantworten kann. ## Die vier Bausteine einer AI-Policy ### Baustein eins: Use-Case-Klassifikation Eine AI-Policy beginnt mit der Klassifikation der Use-Cases. Die Klassifikation hat drei Stufen: niedrig, mittel und hoch. Die Stufen entscheiden, welche Review-Disziplin, welcher Audit-Trail und welche Vorab-Genehmigung ein Use-Case braucht. **Niedrigrisiko:** Automatisierte Texterstellung für interne Dokumente, bei der ein Mensch den Output vor der Verwendung liest. Die Review-Disziplin ist die Augenprüfung, der Audit-Trail ist die Versionshistorie des Dokuments, die Vorab-Genehmigung ist die Use-Case-Registrierung. **Mittelrisiko:** Automatisierte Texterstellung für Kundenkommunikation, bei der ein Mensch den Output vor dem Versand reviewt. Die Review-Disziplin ist die Vier-Augen-Regel, der Audit-Trail ist die Eingabe-Ausgabe-Protokollierung, die Vorab-Genehmigung ist die Genehmigung durch den Use-Case-Owner. **Hochrisiko:** Automatisierte Entscheidungen, die finanzielle, rechtliche oder gesundheitliche Konsequenzen haben. Die Review-Disziplin ist die Vorab-Validierung jedes Outputs durch eine qualifizierte Person, der Audit-Trail ist die vollständige Protokollierung mit Erklärung, die Vorab-Genehmigung ist die Genehmigung durch den Vorstand. Wer die Klassifikation nicht macht, hat eine Policy, die auf alle Use-Cases gleich reagiert. Das ist entweder zu lasch (und dann gibt es Vorfälle) oder zu streng (und dann werden Use-Cases blockiert, die sinnvoll wären). ### Baustein zwei: Datenklassifikation Die zweite Frage, die eine AI-Policy beantworten muss, ist: welche Daten dürfen in welches Modell? Die Antwort hängt von der Datenklasse ab. Öffentliche Daten dürfen in jedes Modell, das im Vertrag steht. Interne Daten dürfen nur in Modelle, die im Vertrag als 'intern' zugelassen sind. Vertrauliche Daten brauchen ein Modell, das die Daten im eigenen Haus verarbeitet, nicht in der Cloud des Anbieters. Regulierte Daten brauchen ein Modell, das die regulatorischen Anforderungen des Sektors erfüllt. In den meisten Unternehmen, die ich gesehen habe, ist diese Datenklassifikation nicht dokumentiert. Wer fragt, welche Daten in welches Modell dürfen, bekommt in vielen Organisationen die Antwort: das weiss jeder Use-Case-Owner selbst. Diese Antwort ist im Alltag tragfähig, aber im Vorfall nicht. Wer im Vorfall nicht weiss, welche Daten in welches Modell flossen, hat eine Untersuchung, die Monate dauert. ### Baustein drei: Modell-Substitution Modell-Substitution ist ein Governance-Thema, nicht nur ein Beschaffungsthema. Die Substitution selbst ist eine Entscheidung, die jemand verantworten muss. Wer ein Modell gegen ein anderes tauscht, muss wissen, was sich am Verhalten ändert, wer die Änderung genehmigt, und wie der Audit-Trail dokumentiert wird. In der Praxis läuft die Modell-Substitution in den meisten Unternehmen informell. Wer das Modell tauscht, ist der Engineer, der gerade an der Pipeline arbeitet. Wer die Genehmigung gibt, ist niemand, weil keine Policy es vorsieht. Diese Lücke ist im normalen Betrieb unsichtbar und im Vorfall verheerend. Eine Policy, die Modell-Substitution regelt, definiert vier Dinge: erstens, welche Rollen die Substitution beantragen dürfen. Zweitens, welche Tests vor der Substitution durchgeführt werden müssen (siehe [Modell-Drift](/posts/modell-drift/)). Drittens, welche Genehmigungen erforderlich sind. Viertens, wie die Substitution im Audit-Trail dokumentiert wird. ### Baustein vier: Audit-Trail Der Audit-Trail ist die Versicherung der AI Governance. Wer einen Audit-Trail hat, kann im Vorfall in Stunden klären, was passiert ist. Wer keinen Audit-Trail hat, klärt in Monaten, was passiert sein könnte. Ein Audit-Trail für KI-Systeme dokumentiert vier Dinge: erstens, welche Eingaben in das System flossen. Zweitens, welche Ausgaben das System produzierte. Drittens, welche Version des Modells zu welcher Zeit aktiv war. Viertens, welche Person welche Änderung am System vorgenommen hat. In den meisten Unternehmen, die ich gesehen habe, ist der Audit-Trail lückenhaft. Wer auditierbar sein will, muss den Audit-Trail als Disziplin aufbauen, nicht als nachträgliche Versicherung. Die Kosten sind moderat (zwischen 5 und 15 Prozent des Engineering-Aufwands), die Konsequenzen im Vorfall sind gross. {% timeline caption="Reifegrade einer AI Governance. Die meisten Unternehmen, die ich gesehen habe, stehen zwischen Stufe eins und drei." data="{\"events\":[{\"label\":\"Stufe 1\",\"description\":\"Keine Policy, Ad-hoc-Entscheidungen\"},{\"label\":\"Stufe 2\",\"description\":\"Datenschutz-Policy, KI erwähnt\"},{\"label\":\"Stufe 3\",\"description\":\"Use-Case-Klassifikation, Review-Disziplin\"},{\"label\":\"Stufe 4\",\"description\":\"Audit-Trail, Vorstands-Reporting\"},{\"label\":\"Stufe 5\",\"description\":\"Vollständige AI-Policy mit Modell-Substitution\"}]}" /} ## Der Berichtszyklus für den Vorstand AI Governance wird im Vorstand nicht dadurch sichtbar, dass sie existiert, sondern dadurch, dass sie berichtet. Wer eine AI-Policy hat, aber nicht im Vorstand reportet, hat eine Policy, die im Vorfall nicht zitiert werden kann, weil der Vorstand sie nicht kennt. Der Berichtszyklus hat drei Elemente. Erstens: ein monatlicher Bericht, der die Anzahl der Use-Cases, deren Klassifikation und die Vorfälle zeigt. Zweitens: ein quartalsweiser Bericht, der den Reifegrad der AI Governance, die offenen Findings und die geplanten Verbesserungen zeigt. Drittens: ein jährlicher Bericht, der die gesamte AI-Strategie, die Investments und die Risiken zeigt. Wer diese drei Berichte nicht hat, hat eine AI Governance, die im Vorstand nicht existiert. Wer sie hat, hat eine AI Governance, die im Vorfall zitiert werden kann, weil der Vorstand sie kennt. In den Unternehmen, die ich gesehen habe, sind die Berichtsformate oft zu technisch. Wer Token-Kosten im Vorstand reportet, hat eine Diskussion über Kosten. Wer Use-Cases, Vorfälle und Reifegrade im Vorstand reportet, hat eine Diskussion über Wertschöpfung und Risiko. Die Sprache des Vorstands ist nicht die Sprache der Engineering-Pipeline. {% questionAnswer question="Wer im Unternehmen entscheidet über Modell-Substitution?" answer="Die Person, die in der AI-Policy als 'Model-Substitution-Owner' benannt ist. In den meisten Unternehmen ist das der CTO oder der Head of AI. In mittelgrossen Unternehmen ist es oft der Engineering-Lead, was zu viel Verantwortung bei zu wenig Autorität bedeutet." /} ## Drei Fehler, die ich gesehen habe Drei Fehler, die in den letzten zwölf Monaten in AI-Governance-Strukturen aufgetaucht sind. Sie sind alle vermeidbar, wenn man weiss, dass sie kommen. **Fehler eins: Policy beim Anbieter lesen.** Wer die AI-Policy schreibt, indem er die Acceptable Use Policy des Anbieters kopiert, hat eine Policy, die den Anbieter schützt, nicht das eigene Unternehmen. Die Policy muss im eigenen Haus entstehen, mit den eigenen Use-Cases, den eigenen Datenklassen, den eigenen Risiken. **Fehler zwei: Audit-Trail auf das Modell beschränken.** Wer den Audit-Trail nur auf das Modell beschränkt, hat die Anwendung vergessen. Der Audit-Trail muss die gesamte Kette abdecken, von der Eingabe des Nutzers bis zur Ausgabe des Modells, inklusive der Vorverarbeitung, der Nachbearbeitung und der Review-Schritte. Wer einen Teil vergisst, hat im Vorfall eine Lücke. **Fehler drei: Governance ohne Accountability.** Wer eine AI-Policy hat, aber keine Person benennt, die für die Einhaltung verantwortlich ist, hat eine Policy, die niemand durchsetzt. Accountability ist nicht Delegation an ein Komitee, sondern Benennung einer Person mit Mandat. Wer die Person nicht benennt, hat eine Policy, die im Vorfall niemand verteidigt. ## Wer die letzte Entscheidung trifft Die letzte Frage, die AI Governance beantworten muss, ist: wer trifft im Unternehmen die letzte Entscheidung über KI-Einsatz? Die Frage klingt einfach, aber die Antwort ist in den meisten Unternehmen undefiniert. In der Praxis gibt es vier Kandidaten, die in Frage kommen. Erstens: der CTO, der die Technik verantwortet. Zweitens: der CDO, der die Daten verantwortet. Drittens: der Compliance-Owner, der die Risiken verantwortet. Viertens: der Vorstand selbst, der die Strategie verantwortet. Keiner dieser vier Kandidaten ist allein richtig. Die richtige Antwort ist eine Person, die alle vier Perspektiven verbindet, und das ist in den meisten Unternehmen eine Rolle, die nicht existiert. In grossen Unternehmen ist es der Chief AI Officer, in mittelgrossen Unternehmen ist es der Head of AI Strategy, in kleinen Unternehmen ist es der CTO mit erweitertem Mandat. Wer diese Rolle nicht schafft, hat eine AI Governance, die zwischen CTO, CDO und Compliance aufgeteilt ist, und niemand fühlt sich verantwortlich. Das ist die Konstellation, die in den meisten Krisen die Verzögerung produziert, die den Schaden vergrössert. ## Was am Ende zählt AI Governance ist keine Compliance-Funktion, sondern eine Vorstandsfunktion. Wer KI in einem Unternehmen betreibt, hat vier Bausteine, die in einer Policy stehen müssen: Use-Case-Klassifikation, Datenklassifikation, Modell-Substitution, Audit-Trail. Wer auf einen dieser Bausteine verzichtet, hat im ersten Vorfall eine Krise, die der Vorstand managen muss. Die vier Bausteine sind nicht das Ziel, sondern das Minimum. Das Ziel ist eine AI Governance, die im Vorstand reportet wird, eine Person hat, die sie verantwortet, und eine Sprache spricht, die der Vorstand versteht. Wer das hat, hat eine AI Governance, die nicht nur reagiert, sondern agiert. ## Weiterführend - **[OECD AI Principles](https://www.oecd.org/digital/artificial-intelligence/ai-principles/)**, wer die internationalen Standards für AI Governance verstehen will, findet hier den Rahmen, an dem sich jede eigene Policy messen lassen muss. - **[NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)**, wer eine US-amerikanische, aber international anschlussfähige Methodik sucht, findet hier den operativen Rahmen für Use-Case-Klassifikation und Audit-Trail. - **[McKinsey: AI Governance in the Enterprise](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)**, wer die Verbreitung von AI Governance im Markt benchmarken will, findet hier die Zahlen, mit denen sich eigene Programme vergleichen lassen.