Die meisten Organisationen entscheiden sich nicht bewusst dafür, mehrere KI-Governance-Programme zu betreiben. Es ergibt sich, weil die Bereiche Sicherheit, Datenschutz, Recht, Responsible AI und Entwicklung jeweils über ihre eigenen Pflichten mit KI in Berührung kommen, und jeder dieser Bereiche liegt bei seinem Teil des Problems richtig. Der Ausweg besteht darin, einen Datensatz und einen zentralen Eingang gemeinsam zu nutzen, während jedes Team seine eigenen Entscheidungen behält. Eine Umorganisation braucht es dafür nicht.

Warum hat am Ende jedes Team seine eigene KI-Prüfung?

Weil jede Funktion über eine andere Pflicht mit KI in Berührung kommt.

• Das Sicherheitsteam hat es mit neuen Datenflüssen, neuen Anbietern und zunehmend mit Agenten zu tun, die Tools aufrufen dürfen. Deshalb weitet es seine Anbieterbewertung und Bedrohungsmodellierung auf sie aus.

• Der Datenschutz sieht neue Verwendungen personenbezogener Daten und nimmt sie in seine Datenschutz-Folgenabschätzung auf.

• Das Responsible-AI-Team achtet auf Fairness, Erklärbarkeit und menschliche Aufsicht und entwickelt eine nach Risikostufen gegliederte Bewertung anhand der eigenen Grundsätze der Organisation.

• Die Entwicklung erfasst Modelle, Versionen, Evaluierungen und Deployments in einem Register auf ihrer eigenen Plattform.

• Recht und Compliance befassen sich mit neuen regulatorischen Pflichten und Vertragsbedingungen und ergänzen ihre bestehenden Prüfungen um Fragen zu KI.

Jedes Team legt ein Formular, eine Tabelle oder eine Warteschlange an, und sobald das Volumen steigt, sucht jedes nach einem Tool. Jeder dieser Wünsche ist berechtigt. Zusammengenommen stellen sie aber alle dieselbe Frage: Wo soll der Datensatz zu jedem KI-System liegen?

Was kostet die Zersplitterung?

Die Symptome sind leicht zu erkennen:

Mit der Zeit wird es schlimmer. Produktteams lernen, dass Governance langsam ist, und beschreiben Projekte so, dass sie einer Prüfung entgehen. Die Register driften weiter auseinander, und der Abgleich bleibt an demjenigen hängen, dem die nächste schwierige Frage gestellt wird.

Die Verzögerung liegt selten in den Prüfungen selbst. Die meiste Zeit vergeht zwischen den Schritten, während eine Anfrage wartet, bis das nächste Team bemerkt, dass sie bereitliegt. Wenn vier oder fünf Teams dieselben Angaben getrennt erheben, können sich diese Wartezeiten auf Monate summieren.

Wiederholungen schaden auch dem Datensatz. Fachverantwortliche, denen dieselbe Frage erneut begegnet, antworten kürzer und weniger sorgfältig. Doppelte Fragen senken so die Qualität dessen, was jedes Team am Ende prüft.

Was braucht jedes Team aus dem Datensatz?

Weniger, als die Formulare vermuten lassen. Das meiste, was jede Prüfung abfragt, ist dieselbe grundlegende Beschreibung des Systems. Der Unterschied liegt in der Entscheidung, die jedes Team damit trifft.

Der gemeinsame Kern (Zweck, Verantwortliche, Daten, Modell, Betroffene und wie viel das System selbstständig entscheidet) sollte einmal erfasst werden. Jedes Team greift dann darauf zurück, statt erneut zu fragen.

Was gehört in den gemeinsamen Datensatz?

Ein praxistauglicher Datensatz hat drei Ebenen, die jeweils in einem anderen Schritt befüllt werden.

1. Die Beschreibung, einmalig im Antragsprozess erfasst. Zweck und Anwendungsfall; fachliche und technische Verantwortliche; wer das System nutzt und wer davon betroffen ist; ob es selbst entwickelt, eingekauft oder in einem bestehenden Produkt aktiviert wurde; Modell und Anbieter; die genutzten Daten, einschließlich personenbezogener und sensibler Daten; die Entscheidungen, die es trifft oder unterstützt; und wie viel es ohne Freigabe durch einen Menschen tun kann.

2. Die Einstufung, abgeleitet aus der Beschreibung. Die Risikostufe, die geltenden Vorschriften und internen Richtlinien sowie die Prüfungen, die die Stufe erfordert.

3. Die Entscheidungen und Nachweise, ergänzt von jedem Team. Freigaben und ihre Auflagen, Bewertungsergebnisse, offene Feststellungen, an die Modellversion gekoppelte Evaluierungsergebnisse und der nächste Prüftermin.

Teamspezifische Details können bei dem Team bleiben, das sie braucht. Die vollständige Datenschutz-Folgenabschätzung, das Bedrohungsmodell des Sicherheitsteams und die Evaluierungssuite der Entwicklung können in den jeweils eigenen Tools liegen, solange das Ergebnis und ein Link zurück in den Datensatz gelangen.

Geben Sie die Nutzung frei, nicht nur die Software. Viele bestehende Prozesse sind an die Beschaffung gekoppelt und geben eine Software daher einmal frei, ohne je zu sehen, wofür sie genutzt wird. Derselbe Schreibassistent ist beim Überarbeiten einer E-Mail reine Routine, aber ein echtes Risiko, wenn jemand einen vertraulichen Vertrag hineinkopiert. Nach dem EU AI Act hängt das Risiko davon ab, wofür ein System eingesetzt wird. Eine neue Nutzung eines freigegebenen Tools sollte deshalb erneut über den zentralen Eingang laufen.

Ein Datensatz, getrennte Entscheidungen

Der typische Fehler besteht darin, die Überschneidung aufzulösen, indem man das Tool eines Teams auswählt und alle anderen bittet, es zu nutzen. Das hat selten Bestand, denn das Datenmodell jedes Tools spiegelt das Team wider, für das es gebaut wurde. Eine Datenschutzplattform ist auf Verarbeitungstätigkeiten ausgerichtet, eine Sicherheitsplattform auf Assets und Anbieter, eine ML-Plattform auf Modellversionen. Keine davon ist auf den KI-Anwendungsfall ausgerichtet, und genau den prüft jedes Team.

Das bewährte Muster besteht aus vier Teilen:

1. Ein zentraler Eingang. Jede neue KI-Anfrage, ob selbst entwickelt, eingekauft oder in einem bestehenden SaaS-Produkt aktiviert, läuft über einen einzigen Antragsprozess.

2. Ein Datensatz pro KI-System. Der Antragsprozess erfasst den gemeinsamen Kern und stuft das System nach Risiko ein. Nach der Freigabe wird dieser Datensatz zum Eintrag des Systems im KI-Inventar.

3. Parallele Prüfungen, getrennte Entscheidungen. Der Datensatz geht an die Teams, die die Stufe vorsieht. Jedes Team führt seine eigene Prüfung durch, behält seine eigenen Freigabeverantwortlichen und verantwortet seine eigene Entscheidung.

4. Feststellungen fließen in den Datensatz zurück. Eine Sicherheitsauflage, eine Feststellung des Datenschutzes oder ein Evaluierungsergebnis wird an denselben Datensatz angehängt, sodass jedes Team den aktuellen Stand sieht. Prüft ein Team in seinem eigenen Ticketsystem, muss die Verbindung in beide Richtungen funktionieren. Die Anfrage legt das Ticket an, und Entscheidung, Auflagen und Kommentare fließen in den Datensatz zurück.

Bestehende Systeme bleiben, wo sie sind. Tickets landen weiterhin in Jira oder ServiceNow, und Unternehmensrisiken laufen weiterhin in der GRC-Suite zusammen. Unser Leitfaden zum gestuften KI-Antragsprozess behandelt die Einstufung und die Übergaben an bestehende GRC-Prozesse im Detail, und unser Vergleich von KI-Governance-Tools und GRC-Modulen zeigt, welche Datensätze wohin gehören.

Wie funktioniert die Weiterleitung in der Praxis?

Jede Organisation zieht die Grenzen etwas anders. In den Workflows, die sich nach unserer Erfahrung bewähren, legen Risikostufen fest, welche Teams was prüfen. So kommen risikoarme Anfragen schnell voran, und risikoreiche durchlaufen jede Prüfung, die sie brauchen. Die Stufe ergibt sich aus wenigen Vorprüfungsfragen im Antragsprozess:

• Nutzt das System personenbezogene oder sensible Daten?

• Trifft oder unterstützt es Entscheidungen über Menschen, etwa bei Einstellungen, Krediten, Preisgestaltung oder dem Zugang zu Leistungen?

• Kann es ohne Freigabe durch einen Menschen in anderen Systemen handeln?

• Erreichen seine Ausgaben Kunden direkt?

• Wurde es intern entwickelt, eingekauft oder in einem bereits genutzten Produkt aktiviert?

• Wo leben die Menschen, die davon betroffen sind?

Ein Ja auf eine der ersten drei Fragen bedeutet in der Regel mindestens die mittlere Stufe. Personenbezogene Daten in Verbindung mit Entscheidungen über Menschen oder autonomem Handeln bedeuten in der Regel die hohe Stufe. Eine einfache Version mit drei Stufen sieht so aus:

Nehmen wir eine typische Anfrage: Ein HR-Team möchte in seiner bestehenden Recruiting-Software eine KI-Funktion aktivieren, die Bewerber in eine Rangfolge bringt. Im fragmentierten Modell gibt das Sicherheitsteam das Update des Anbieters vielleicht an einem Tag frei, während der Datenschutz und das Responsible-AI-Team nie davon erfahren. Im konsolidierten Modell kommt die Anfrage über den zentralen Eingang. Der Datensatz hält fest, dass die Funktion personenbezogene Daten nutzt, um Einstellungsentscheidungen zu unterstützen, und ordnet sie damit der hohen Stufe zu. Der Datenschutz führt seine Folgenabschätzung durch, das Responsible-AI-Team testet auf Fairness und legt Anforderungen an die Aufsicht fest, und das Sicherheitsteam prüft, wie der Anbieter mit Daten umgeht. Alle drei arbeiten mit derselben Beschreibung. Die Auflagen jedes Teams werden an den Datensatz angehängt, und die Funktion geht in Betrieb, sobald sie erfüllt sind. Wenn später jemand fragt, welche Systeme Einstellungsentscheidungen unterstützen, genügt ein Filter im Inventar.

Warum ist ein einziger Datensatz für die Regulierung wichtig?

Aufsichtsbehörden in mehreren Rechtsordnungen erwarten inzwischen, dass Organisationen wissen, wo automatisierte Systeme Entscheidungen über Menschen treffen oder unterstützen, und dass sie darüber Auskunft geben können. Der EU AI Act legt Betreibern von Hochrisiko-KI-Systemen Pflichten auf, und die DSGVO beschränkt Entscheidungen, die ausschließlich auf einer automatisierten Verarbeitung beruhen. US-Bundesstaaten wie Colorado und Kalifornien sowie Quebec und Australien führen Regeln ein, nach denen Organisationen ihren Einsatz automatisierter Entscheidungsfindung offenlegen und in manchen Fällen bewerten müssen. Jedes Gesetz formuliert es anders, aber alle fragen, welche Systeme beteiligt sind, welche Daten sie nutzen, welche Entscheidungen sie beeinflussen und wer sie geprüft hat.

Im fragmentierten Modell sind diese Antworten auf mehrere Teams verteilt. Die Entwicklung weiß, welche Systeme es gibt, der Datenschutz weiß, welche davon personenbezogene Daten nutzen, das Responsible-AI-Team weiß, welche wesentliche Entscheidungen unterstützen, und das Sicherheitsteam weiß, welche Tools von Drittanbietern freigegeben wurden. Mit einem einzigen Datensatz können Datenschutz und Rechtsabteilung auf Anfrage antworten, statt das Bild aus getrennten Listen zusammenzusetzen.

Worüber stolpern Teams bei der Konsolidierung?

Bei den meisten Konsolidierungen treten dieselben wenigen Probleme auf.

• Zwei Eingänge während der Umstellung. Bleibt das alte Formular während einer Migration aktiv, nutzen manche Antragsteller es weiter und gehen dann davon aus, dass ihre Anfrage verloren gegangen ist. Schalten Sie das alte Formular an dem Tag ab, an dem das neue in Betrieb geht.

• Zu früh angelegte Inventareinträge. Legt das Einreichen einer Anfrage sofort einen Inventareintrag an, geben viele nur das Allernötigste ein, damit es weitergeht, und das Inventar füllt sich mit lückenhaften Datensätzen zu Systemen, die womöglich nie freigegeben werden. Erfassen Sie die Beschreibung im Antragsprozess und nehmen Sie das System ins Inventar auf, sobald es freigegeben ist.

• Für Antragsteller sichtbare Risikoergebnisse. Antragsteller, die sehen, welche Antworten die Stufe erhöhen, können lernen, so zu antworten, dass die Stufe niedrig bleibt, und manche sehen Risikohinweise, die sie nicht einordnen können. Meist ist es besser, das Ergebnis nur Prüfern und Freigabeverantwortlichen anzuzeigen.

• Risikowerte, die niemand mit der Rechtsabteilung abgestimmt hat. Ein dokumentierter hoher Risikowert für ein Tool, das die Organisation anschließend freigibt, kann in einem späteren Rechtsstreit ungünstig wirken. Sicherer kann es sein, mit einfachen Prüfergebnissen zu beginnen, die von keinen Bedenken bis zur Sperrung reichen, und Risikowerte erst einzuführen, wenn die Risikotaxonomie feststeht und auf die unternehmensweite Risikomatrix abgestimmt ist. Fragen Sie die Rechtsabteilung nicht nur, was bewertet werden soll, sondern auch, wie Risiken festgehalten werden sollen.

• Eine Kontrolle, die niemand geplant hat. Die Zahl der Agenten bleibt oft aus Gründen niedrig, für die sich niemand entschieden hat, etwa weil für jeden Agenten noch ein IT-Ticket nötig ist. Diese Grenze fällt weg, sobald Mitarbeitende Agenten selbst erstellen können. Wenn eine Warteschlange stillschweigend die Aufgabe einer Kontrolle übernimmt, lassen Sie Agenten über den zentralen Eingang laufen, bevor die Warteschlange wegfällt.

• Alle im Prüfgremium gelten als Freigabeverantwortliche. Prüfgremien wachsen oft so lange, bis das Governance-Team seine Tage damit verbringt, Prüfern per Chat und E-Mail hinterherzulaufen, und die Mitglieder nicht erkennen können, wann eine Anfrage tatsächlich ihre Mitwirkung erfordert. Trennen Sie diejenigen, die freigeben müssen, von denen, die nur informiert sein müssen, und benachrichtigen Sie beide Gruppen unterschiedlich.

Erste Schritte

1. Erfassen Sie die Überschneidungen, bevor Sie Tools auswählen. Listen Sie die Felder auf, die das aktuelle Formular jedes Teams erhebt, und markieren Sie diejenigen, die das System beschreiben und nicht eine teamspezifische Entscheidung. Die Überschneidung ist meist groß.

2. Einigen Sie sich auf den gemeinsamen Datensatz und die Verantwortung dafür. Legen Sie fest, welche Felder in den Datensatz zum KI-System gehören und wer ihn pflegt. Verantwortlich ist häufig das Responsible-AI-Team oder die KI-Leitung, gemeinsam mit dem Datenschutz.

3. Halten Sie die Stufen schriftlich fest. Veröffentlichen Sie die Vorprüfungsfragen, die Prüfungen, die jede Stufe erfordert, und jeweils eine angestrebte Bearbeitungszeit, damit Antragsteller vorab wissen, was sie erwartet.

4. Beginnen Sie mit einer kurzen ersten Version. Einfache Formulare werden tatsächlich genutzt. Decken Sie in der ersten Version den Großteil dessen ab, was Sie brauchen, und ergänzen Sie den Rest, sobald das Formular im Einsatz ist. Wenn verschiedene Regionen eigene Fragebögen verwenden, führen Sie diese zuerst zusammen und fügen Sie danach Verzweigungen für einzelne Rechtsordnungen hinzu.

5. Betreiben Sie einen zentralen Eingang und leiten Sie parallel weiter. Behalten Sie die Freigabeverantwortlichen jedes Teams bei; ändern Sie nur, wo die Anfrage eingeht und wo der Datensatz liegt.

6. Nehmen Sie die bereits genutzten Systeme auf. Beginnen Sie mit denen, die wesentliche Entscheidungen über Menschen treffen oder unterstützen oder sensible Daten nutzen, denn sie bergen das größte Risiko und ziehen die meisten Fragen auf sich.

7. Wählen Sie die Tools zuletzt. Die richtige Plattform ist die, deren Datenmodell den Datensatz zum KI-System abbildet und sauber an den bestehenden Workflow jedes Teams übergibt.

Häufig gestellte Fragen

Bedeutet die Konsolidierung der KI-Governance, dass ein Team die Prüfungen der anderen übernimmt?

Nein. Die Konsolidierung betrifft den Datensatz und den zentralen Eingang. Jedes Team behält seine eigene Prüfung und seine Freigabeverantwortlichen und trifft weiterhin seine eigene Entscheidung; die Teams hören lediglich auf, dieselben Informationen getrennt zu erheben.

Müssen Teams die Tools aufgeben, die sie bereits nutzen?

Nein. Der Datenschutz kann seine Datenschutzplattform behalten, das Sicherheitsteam sein Tool für Anbieterrisiken und die Entwicklung ihr Modellregister. Der Datensatz zum KI-System kann auf diese Tools verlinken und enthält das Ergebnis jeder Prüfung, sodass die Tools nicht mehr darum konkurrieren, das Inventar zu sein.

Wer sollte für den gemeinsamen Datensatz zum KI-System verantwortlich sein?

In der Regel das Responsible-AI-Team oder die KI-Leitung, gemeinsam mit dem Datenschutz, denn zusammen decken sie den Anwendungsfall und die Daten ab. Am wichtigsten sind ein einziger Datensatz und benannte Verantwortliche für die Richtlinie und für die Durchführung des Prozesses. Treibt die KI-Leitung auch die KI-Einführung voran, geben Sie der Prüfung eine eigene Leitung. Programme geraten oft ins Stocken, während ein Lenkungsausschuss über die Zuständigkeit diskutiert. Meist bringt die Benennung dieser beiden Verantwortlichen sie wieder in Gang.

Wie bringen Sie Produktteams dazu, den zentralen Eingang zu nutzen?

Machen Sie ihn zum schnellsten Weg zu einer Entscheidung. Ein Formular statt drei, klare Stufen und parallele Prüfungen geben Teams einen Grund, ihn zu nutzen. Wenn Beschaffung und Plattformzugang an einen freigegebenen Datensatz gekoppelt sind, ist der Rest weitgehend erledigt.

Die Rolle von Enzai

Enzai ist darauf ausgelegt, dieser gemeinsame Datensatz zu sein. Ein zentraler Eingang für Anträge gibt jedem KI-System einen einzigen Datensatz, stuft es nach Risiko ein und leitet es an die Prüfung jedes Teams weiter, mit Übergaben an Jira und ServiceNow. Das KI-Inventar entsteht aus diesen Datensätzen. So behält jedes Team seine Entscheidungen und arbeitet zugleich mit denselben Fakten. Wenn Sie KI-Governance über Teams hinweg konsolidieren, sprechen Sie mit dem Enzai-Team.