KI-Verantwortung lässt sich nicht outsourcen

Ein Workshop und ein Raum, der in der Mitte geteilt war

Vor einigen Jahren leitete ich einen Workshop für Führungskräfte, die in ihren Unternehmen für die Entwicklung und den Einsatz von KI verantwortlich sind. Ich legte ihnen eine Handvoll realer Anwendungsfälle vor und fragte, welche Risikostufe ihr Unternehmen  laut EU AI Act hätte. Bei jedem Beispiel war der Raum mehr oder weniger gleichmäßig gespalten. Das waren keine Laien: Es handelte sich um Personen mit fundiertem Fachwissen, die bei gleicher Fakten-Vorlage zu völlig gegensätzlichen Antworten kamen. Das Beispiel verdeutlicht ein Problem und würde heutzutage vermutlich kaum anders ausfallen.

Wo wir aktuell stehen

Ein Großteil des AI Acts ist bereits in Kraft. Die Verbote und die Anforderung an die KI-Kompetenz gelten seit Februar 2025, die Verpflichtungen für Allzweck-KI-Modelle seit August 2025, und in Deutschland hat die Bundesnetzagentur die Aufsichtsfunktion bereits übernommen. Durch das „Digital Omnibus“-Gesetz wurden die Fristen für Teile der Hochrisiko-Kategorie zwar verschoben, die Verpflichtungen selbst bleiben aber bestehen. So wurde den Unternehmen mehr Zeit eingeräumt, ohne dass sich der Arbeitsaufwand wirklich verringert hat. Was noch aussteht, sind praktische Leitlinien zur Anwendung der Vorschriften auf ein jeweils spezifisches System. Gerade bei dieser Einstufung bereitet eine Definitionslücke momentan aber die größten Schwierigkeiten.

Warum eine jährliche Einstufung nicht ausreicht

Der AI Act knüpft die Risikostufe an den Zweck eines Systems. Das funktioniert gut für Fälle, in denen sehr bestimmte Aufgaben erfüllt und diese kontinuierlich ausgeführt werden. Viele Systeme verändern sich aber erheblich, sobald sie langfristig in Betrieb sind. Nehmen wir als Beispiel einen hypothetischen internen Assistenten, der HR-Fragen beantwortet. Jemand verbindet ihn mit Bewerberdaten, und einige Monate später beginnt ein Rekrutierungsteam, seine Zusammenfassungen zur Erstellung von Auswahllisten zu nutzen. Zu keinem Zeitpunkt hat jemand beschlossen, ein System mit hohem Risiko aufzubauen – doch genau das ist daraus geworden.

Agenten erschweren diese Ebene zusätzlich. Sie verknüpfen Datenquellen und Tools miteinander und jede neue Verbindung kann die tatsächliche Funktionsweise des Systems verändern. Eine einmal durchgeführte und alle zwölf Monate überprüfte Klassifizierung beschreibt das System nur so, wie es am Tag der Überprüfung aussah. Das hat möglicherweise kaum noch Ähnlichkeit mit dem, was derzeit läuft. Die Klassifizierung sollte dementsprechend als eine operative Routine betrachtet werden, mit definierten Auslösern für eine erneute Überprüfung.  Jede neue Datenquelle, jedes neue Tool, jede neue Nutzergruppe und jegliche Änderungen in der Art und Weise, wie die Ergebnisse genutzt werden, können von Relevanz sein.

Die Geschichte weckt Erinnerungen

Viele, die die damaligen Entwicklungen zum ESG mitverfolgt haben, werden einiges davon heute im AI Act wiedererkennen. Die Anforderungen ändern sich ständig, die nationale Umsetzung weicht von dem ab, was die EU-Richtlinien vermuten ließen, und Unternehmen hatten bereits Budget und Personal bereitgestellt, lange bevor jemand mit Sicherheit sagen konnte, was das eigentliche Ziel war. Viele waren am Ende zwar in der Lage, einen Bericht zu erstellen, hatten aber nicht die Möglichkeit, auf dessen Grundlage etwas zu bewirken – und der AI Act könnte denselben Weg gehen, wenn Organisationen die Einhaltung der Vorschriften lediglich als ein Formular betrachten, das ausgefüllt werden muss.

Eine Plattform kaufen und Rechenschaft darüber ablegen

Einige Unternehmen glauben vorschnell daran, dass eine einmal erworbene Governance-Plattform die Frage der Compliance endgültig klärt. Dieser Impuls ist nachvollziehbar, aber er trügt: Eine Aufsichtsbehörde wird kaum fragen, welches Tool gekauft wurde. Die Fragen lauten vielmehr: Wer hat den Anwendungsfall genehmigt, welche Risikobewertung wurde durchgeführt, wer hat das System anschließend überwacht und wo befindet sich die Dokumentation?

Es ist hier hilfreich, in vier zentralen Ebenen zu denken: dem Governance-Rahmenwerk mit seinen Richtlinien und Leitlinien, der technologischen Umsetzung dieses Rahmenwerks, der Technologie selbst und der Compliance. Tools können sicherlich zugekauft werden, aber die Antworten auf diese vier Fragen müssen von Mitarbeitern innerhalb der Organisation selber kommen. Deshalb bleibt die Verantwortung weiterhin beim Unternehmen, auch wenn die Technologie von außerhalb stammt.

Vier praktische Maßnahmen

Jede dieser Fragen weist auf eine Maßnahme hin, und jede Maßnahme schützt vor einem bestimmten Risiko: 

1. Ein gepflegtes Bestandsverzeichnis schützt vor Systemen, von denen niemand etwas weiß. Seit Jahren setzen Geschäftsbereiche KI-Tools ein – meist mit guten Absichten, aber ohne nennenswerte zentrale Transparenz. Zunehmend tauchen auch KI-Funktionen in Software auf, die das Unternehmen bereits besitzt. Ohne eine kontinuierlich aktualisierte Bestandsaufnahme der Systeme, ihrer Zwecke, ihrer Verantwortlichen und der Daten, auf die sie zugreifen, lässt sich die Frage, wer einen bestimmten Anwendungsfall genehmigt hat, nicht richtig beantworten. Es ist weitaus besser, diese Lücken selbst aufzudecken, als wenn es eine Aufsichtsbehörde oder ein Betriebsrat später aufdeckt.
2. Klarheit über Rollen schützt vor stillschweigenden Statusänderungen. Der Kauf eines Modells von einem Anbieter bedeutet nicht, dass die mit dessen Nutzung verbundenen Verpflichtungen abgetreten werden. Ein Unternehmen, das ein System wesentlich modifiziert oder umfunktioniert, stellt möglicherweise bald fest, dass es vom Betreiber zum Anbieter geworden ist – mit einem umfangreicheren Pflichtenkatalog. Es ist sinnvoll, die Rolle für jedes System frühzeitig festzulegen, bevor andere Entscheidungen auf einer Annahme basieren, die sich als falsch erweist.
3. Dokumentation als fortlaufender Prozess schützt vor veralteten Klassifizierungen. Eine Bewertung, die zur Erfüllung eines Audits verfasst wurde, ist in dem Moment bereits veraltet, in dem sich etwas am System ändert. Die Verknüpfung der Dokumentation mit den oben beschriebenen Faktoren bedeutet, dass zu jeder Zeit eine Antwort parat ist auf die Frage: „Welche Risikobewertung wurde durchgeführt?“
4. Gemeinsame Zuständigkeit schützt vor einer Zersplitterung der Verantwortung. Die Rechtsabteilung, die IT, die Geschäftsbereiche und die Personalabteilung haben jeweils einen Teil des Gesamtbildes im Blick; daher muss für die Frage, wer ein System überwacht hat, ein namentlich definierbarer Verantwortlicher mit vereinbarten Übergaben zwischen diesen Abteilungen festgelegt werden. Eine Ansammlung gestreuter und einzelner Maßnahmen führt nicht zu schlüssigen Antworten.