Ein AI-Programmleiter erhält üblicherweise ein Mandat: dafür sorgen, dass AI adoptiert wird, dass Teams davon schneller werden, dass das Programm Ergebnisse zeigt. Ein zweites Mandat kommt selten hinzu: dafür sorgen, dass alles, was währenddessen entsteht, verantwortungsvoll ist. Trotzdem wird er auf beides abgerechnet, sobald etwas schiefgeht. Das ist der Kern seines Risikos: er ist verantwortlich für ein Programm, dessen Ränder er nicht kennt.
Was er mit Adoption gewinnt — schnellere Prozesse, zufriedene Teams, eine sichtbare Erneuerungsgeschichte — steht dem gegenüber, was er verliert, wenn es schiefgeht: ein Vorfall mit einem Tool, das nicht auf seiner Liste stand, ein Audit, das Fragen stellt, auf die er keine Antwort hat, ein Vorstand, der fragt, warum das Programm nicht sah, was bereits lief. Diese Asymmetrie macht seine Position verwundbar, auch wenn das Programm selbst gut läuft.
Seine Frage ist nicht "welche AI-Tools haben wir freigegeben". Diese Liste hat er, und sie ist oft kürzer als die Wirklichkeit. Seine Frage ist: was nutzen Teams, die nicht auf meiner Liste stehen, und wie bekomme ich das transparent, ohne dass Menschen es verstecken. Ein Programmleiter, der Adoption fördern will, kann es sich nicht leisten, dass Nutzer ihre Tools aus Angst vor einer Korrektur verstecken. Wer fragt, was genutzt wird, und daraus anschließend ein Problem macht, bekommt bei der nächsten Frage keine Antwort mehr. Governance und Adoption arbeiten hier gegeneinander, wenn es falsch angegangen wird.
Eine Antwort, die er nicht akzeptiert, ist eine einfache Blockade: "AI-Nutzung ist ohne Freigabe nicht erlaubt." Diese Antwort befriedigt einen Auditor für einen Moment, verlagert die Nutzung aber an Orte, die niemand sieht. Es ist das Gegenteil von dem, was ein Programmleiter erreichen will: er will, dass AI-Nutzung sichtbar und begleitet ist, nicht dass sie in den Untergrund geht. Ein Verbot ohne Mechanismus zum Melden und Lernen ist für ihn ein Verlust, auch wenn es auf dem Papier compliant klingt.
Er akzeptiert auch keine Antwort, die alles gleich behandelt. Ein Tool, das Text für internen Gebrauch zusammenfasst, ist nicht dasselbe Risiko wie ein Tool, das automatisch Entscheidungen über Kunden oder Mitarbeiter trifft. Ohne Unterscheidung nach Rolle und Risikoniveau kann ein Programm nicht priorisieren, und ein Programmleiter, der nicht priorisieren kann, kann sein Mandat nicht ausführen.
Was funktioniert, ist eine Bestandsaufnahme, die bei dem beginnt, was existiert, nicht bei dem, was freigegeben ist. Das bedeutet, Teams zu fragen, was sie tatsächlich nutzen, und das auf eine Weise zu tun, die keine Abrechnung mit sich bringt. Nur dann kommt Schatten-AI ins Bild — die Systeme, die ohne formellen Prozess eingeführt wurden, oft weil sie Arbeit erleichterten und niemand einen Grund sah, auf eine Freigabe zu warten.
Danach folgt die Klassifizierung: welche Anwendung betrifft Kunden, welche betrifft nur den internen Prozess, welche trifft Entscheidungen ohne Menschen dazwischen. Diese Einteilung bestimmt, wo Aufsicht streng sein muss und wo sie leicht bleiben kann. Ohne diese Einteilung behandelt ein Programm alles gleich streng oder gleich leicht, und beides ist ein Problem: das eine bremst Adoption, das andere lässt Risiken unbeaufsichtigt.
Die Governance-Struktur, die darauf folgt, muss sich an das anschließen, was innerhalb der Organisation bereits existiert — die bestehenden Risikoausschüsse, die bestehenden Berichtslinien — nicht ein neuer Kreislauf daneben. Das ist auch der Punkt, an dem sich ein Programmleiter von anderen Rollen in der Organisation unterscheidet: ein Vorstand will wissen was ein Vorstand über AI-Risiko wissen muss auf der Ebene der Gesamtverantwortung, ein CIO nähert sich dem über Systeme und Zugang, wie beschrieben in was ein CIO über AI-Risiko wissen muss, und ein General Counsel blickt auf Haftung und Dokumentationspflicht über was ein General Counsel über AI-Risiko wissen muss. Ein Programmleiter muss diese drei Perspektiven bedienen können, ohne seine eigene Aufgabe — Adoption — zu verlieren.
Welche konkreten Verpflichtungen für welche Risikokategorie gelten, und innerhalb welcher Fristen, ist nicht das Thema dieser Seite. Dieser Text ändert sich, wird verschärft und erhält Erläuterungen an anderen Stellen. Hier geht es um den Mechanismus: wie ein Programm Einblick bekommt in das, was tatsächlich läuft, wie es das in Risikoniveaus übersetzt, und wie es das nachweisbar gegenüber Vorstand und Aufsicht macht, unabhängig davon, was der genaue Regeltext zu einem bestimmten Zeitpunkt vorschreibt.
Sobald klar ist, was läuft und wer dafür verantwortlich ist, entsteht eine andere Frage: was es einbringt, wenn diese Arbeit gut organisiert wird. Das ist eine Frage, die pro Aufgabe beantwortet werden muss, nicht pro Organisation. Der Werkscan von FTE TO AI berechnet auf dieser Ebene, welcher Teil der Arbeit von AI übernommen werden kann, sodass ein Programmleiter nicht nur weiß, was läuft, sondern auch, wo das Hinzufügen von Kapazität tatsächlich einen Unterschied macht.
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.