Eine Oversight-Entscheidungsliste erfasst, wer welche Entscheidung über welches KI-System getroffen hat, auf Grundlage welcher Informationen und mit welchem Vorbehalt. Das klingt einfach. In der Praxis scheitert die erste Version oft, weil sie als neuer Prozess neben bestehende Besprechungen gestellt wird. Ein zweiter Prozess neben dem bestehenden wird ignoriert, nicht weil Menschen unwillig sind, sondern weil niemand Zeit für etwas reserviert, das nicht zu einer bereits vollen Agenda passt.
Die Liste ist kein Aktivitätenprotokoll und kein Risikoregister. Sie enthält Entscheidungen: Momente, in denen jemand mit Befugnis etwas genehmigte, ablehnte, aufschob oder unter Bedingungen fortsetzen ließ. Pro Zeile gehören mindestens vier Elemente dazu: das System oder die Anwendung, auf die sich die Entscheidung bezieht, Name und Funktion des Entscheiders, das Datum und die Begründung oder der Vorbehalt. Ohne Begründung ist eine Entscheidungsliste eine Anwesenheitsliste. Mit Begründung wird sie zum Beleg dafür, dass nachgedacht wurde, nicht nur, dass etwas abgehakt wurde.
Die Liste sollte auch Raum für Überarbeitung bieten. Eine Entscheidung, die vor einem halben Jahr auf Grundlage der damals verfügbaren Informationen getroffen wurde, kann überholt sein. Eine gute Entscheidungsliste zeigt, wann eine Entscheidung erneut bestätigt oder zurückgenommen wurde, nicht nur, wann sie ursprünglich getroffen wurde.
Vorstände und Geschäftsführungen haben bereits einen Rhythmus: Quartalssitzungen, Risikoausschüsse, Prüfungsausschüsse. Wer eine neue Oversight-Struktur aufbaut, die losgelöst von diesem Rhythmus steht, verlangt von Menschen, zusätzliche Zeit für etwas zu finden, das keinen festen Platz hat. Das geschieht selten dauerhaft. Die ersten paar Male gelingt es vielleicht, mit Mühe. Danach verschwindet es von der Agenda, sobald etwas Dringenderes auftaucht, und etwas Dringenderes taucht immer auf.
Die Lösung besteht nicht darin, einen neuen Prozess aufzubauen, sondern die Entscheidungsliste an das anzuhängen, was bereits geschieht. Wenn es bereits einen Risikoausschuss gibt, der sich jedes Quartal trifft, sollte die KI-Entscheidungsliste ein fester Bestandteil dieser Agenda sein, keine separate Sitzung. Wenn es bereits einen Prüfpfad für finanzielle Entscheidungen gibt, sollte die Logik dieses Pfads — wer unterzeichnet, wer kontrolliert, wo es gespeichert wird — für KI-Entscheidungen wiederverwendet werden. Das ist auch der Grund, warum die Anbindung an die bestehende Risikostruktur ein eigenes Thema ist: Eine Entscheidungsliste, die nicht an bestehende Risikogespräche anknüpft, bleibt ein isoliertes Dokument, das niemand konsultiert.
Eine Entscheidungsliste funktioniert nicht für sich allein. Sie speist die Berichterstattung, die ein Vorstand benötigt, um sagen zu können, dass er Einblick in das KI-Risiko hat, und sie setzt voraus, dass es einen Weg gibt für den Fall, dass eine Entscheidung sich als nicht mehr tragbar erweist. Ohne einen Board-Bericht von einer Seite, der die Entscheidungsliste zusammenfasst, verschwindet die Information in einem Archiv, das niemand durchblättert. Ohne funktionierende Eskalationspfade bleibt eine überholte Entscheidung einfach bestehen, weil niemand weiß, an wen er sich damit wenden soll.
Die drei hängen zusammen: Die Entscheidungsliste hält fest, was entschieden wurde, die Berichterstattung macht das auf der Ebene sichtbar, auf der es Gewicht hat, und Eskalation sorgt dafür, dass eine Entscheidung wieder aufgegriffen werden kann, wenn sich die Situation ändert. Baut man eines ohne die anderen beiden auf, entsteht ein Schein von Überblick, der beim ersten Test — ein Vorfall, eine Frage einer Aufsichtsbehörde, ein Journalist — nicht abdeckt, was tatsächlich geschieht.
Eine Entscheidungsliste ist nur so gut wie die Informationen, die in sie einfließen. Wenn niemand weiß, welche KI-Systeme tatsächlich im Einsatz sind — einschließlich dessen, was außerhalb der IT-Abteilung beschafft oder aufgesetzt wurde —, erfasst die Liste nur Entscheidungen zu den sichtbaren, formell genehmigten Anwendungen. Der Rest bleibt unentschieden, nicht weil keine Entscheidung nötig war, sondern weil niemand wusste, dass es etwas zu entscheiden gab. Deshalb geht eine Inventarisierung einer Entscheidungsliste immer voraus und folgt ihr nicht nach. Was ein Vorstandsmitglied darüber wissen sollte, ist beschrieben in was ein Vorstandsmitglied über KI-Risiko wissen sollte; was ein CIO in dieser Inventarisierung erkennen sollte, steht in was ein CIO über KI-Risiko wissen sollte.
Was feststeht: Eine Entscheidungsliste ohne Anbindung an ein bestehendes Gremium wird nicht gepflegt, und eine Entscheidungsliste ohne vollständiges Bild dessen, was tatsächlich läuft, erfasst nur einen Teil der Realität. Was von der Organisation abhängt: welches Gremium der geeignete Ankerpunkt ist, wie oft dieses Gremium zusammenkommt und wer die Befugnis hat, eine Entscheidung zu treffen, die in die Liste aufgenommen wird. Das unterscheidet sich je nach Branche, Unternehmensstruktur und Risikokultur, und deshalb gibt es keine feste Vorlage, die überall ohne Anpassung funktioniert.
Der Responsible AI Scan befindet sich im Aufbau. Wer derzeit eine Entscheidungsliste benötigt, die an die bestehende Struktur anknüpft, kann sich für die Warteliste anmelden; es wird noch nichts angeboten, das es noch nicht gibt.
Eine Entscheidungsliste sagt, wer entschieden hat, nicht wie viel Arbeit ein System tatsächlich übernimmt oder übernehmen könnte. Für diese Frage — welcher Teil einer Aufgabe sich an KI übertragen lässt und welcher nicht — braucht es einen anderen Blick, als Governance allein bietet. Der Werkscan von FTE TO AI berechnet pro Aufgabe, welcher Teil der Arbeit übernommen werden kann, als Ergänzung zu dem Überblick, den eine Entscheidungsliste und die zugehörige Oversight-Struktur bieten.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.