Hochriskant erkannt — wie eine KI-Risikoanalyse in der Praxis aussieht

In Teil 2 dieser Serie habe ich die vier Risikostufen des EU AI Acts beschrieben und erklärt, warum HR-KI fast immer hochriskant ist. Der häufigste Nachfolgesatz, den ich darauf höre, ist: “Okay. Und was muss ich jetzt konkret tun?”

Das ist die richtige Frage, und die Antwort beginnt mit einer Unterscheidung, die viele überraschend findet.

Provider oder Deployer? Diese Frage kommt zuerst

Der EU AI Act unterscheidet zwischen zwei Rollen im Umgang mit KI-Systemen.

Provider ist, wer ein KI-System entwickelt oder entwickeln lässt, um es in Verkehr zu bringen oder im eigenen Betrieb zu nutzen. Deployer ist, wer ein bestehendes KI-System in eigenen Prozessen einsetzt, ohne es grundlegend verändert zu haben.

In der Praxis: Wer ein HR-Tool von einem Softwareanbieter kauft und nutzt, ist Deployer. Der Softwareanbieter ist Provider. Wer ein Open-Source-Sprachmodell mit eigenen Unternehmensdaten fine-tuned und daraus eine interne Anwendung baut, ist wahrscheinlich selbst Provider.

Wichtig: Wer ein zugekauftes KI-System erheblich verändert, etwa durch eigenes Training auf andere Aufgaben anpasst, kann vom Deployer zum Provider werden. Die Grenze ist nicht immer scharf, und im Zweifel ist rechtlicher Rat hier gut angelegt.

Was Provider leisten müssen

Ein Hinweis vorweg: Die folgenden Pflichten selbst hat der Gesetzgeber nicht verändert, nur ihren Stichtag. Der Digital Omnibus hat sie im Juli 2026 von August 2026 auf den 2. Dezember 2027 verschoben (für in Produkte eingebettete Hochrisiko-KI sogar auf 2. August 2028). Wer die Rollen und Pflichten jetzt klärt, hat bis dahin Zeit für eine saubere Umsetzung statt einer Last-Minute-Reaktion.

Die Pflichten für Provider sind umfangreich und in den Artikeln 9 bis 15 der Verordnung geregelt.

Artikel 9 verlangt ein Risikomanagementsystem, das den gesamten Lebenszyklus des Systems begleitet, kontinuierlich aktualisiert und dokumentiert wird. Es geht nicht um ein einmaliges Dokument, sondern um einen lebenden Prozess.

Artikel 10 regelt Daten und Datenverwaltung: Trainingsdaten müssen bestimmten Qualitätskriterien entsprechen, auf Biases geprüft werden, und ihre Herkunft muss dokumentiert sein.

Artikel 11 verlangt eine technische Dokumentation nach Annex IV der Verordnung, die den Zweck des Systems, seine Designentscheidungen, die verwendeten Methoden und die Performance-Metriken beschreibt.

Artikel 12 schreibt Protokollierungsfunktionen vor: Das System muss Ereignisse automatisch aufzeichnen, damit eine nachträgliche Prüfung und Rückverfolgung möglich ist.

Artikel 13 betrifft Transparenz gegenüber Deployern: Der Provider muss eine verständliche Nutzungsanleitung liefern, die Deployern ermöglicht, ihre eigenen Pflichten zu erfüllen.

Artikel 14 zur menschlichen Aufsicht ist besonders anspruchsvoll: Das System muss technisch so gestaltet sein, dass eine natürliche Person das System überwachen, seine Ausgaben verstehen, und es im Zweifelsfall übersteuern oder abschalten kann. Das ist kein formales Kriterium, sondern ein funktionales.

Artikel 15 regelt Genauigkeit, Robustheit und Cybersicherheit.

Wer ein eigenes KI-System entwickelt, hat also einen erheblichen Dokumentations- und Prüfaufwand vor sich. Artikel 43 verlangt zusätzlich eine Konformitätsbewertung, in vielen Fällen als Selbstbewertung möglich, in bestimmten Bereichen wie Biometrie durch eine anerkannte Prüfstelle.

Was Deployer leisten müssen

Die Pflichten für Deployer sind in Artikel 26 der Verordnung geregelt und weniger umfangreich als die der Provider, aber keineswegs trivial.

Erstens muss das System entsprechend den Anweisungen des Providers genutzt werden. Das klingt selbstverständlich, hat aber praktische Konsequenzen: Wer ein HR-Tool für die Bewerbervorauswahl kauft und es dann auch für die laufende Leistungsbewertung bestehender Mitarbeitender einsetzt, betreibt es außerhalb seiner bestimmungsgemäßen Verwendung. Das erzeugt eigene Haftungsfragen.

Zweitens muss menschliche Aufsicht real sichergestellt sein. Die Verordnung meint das nicht als Checkbox. Jemand muss tatsächlich in der Lage sein, die KI-Entscheidung inhaltlich zu prüfen und sie zu korrigieren. Eine Aufsicht, die faktisch keine Zeit und keinen Zugang hat, um die Entscheidungen wirklich zu beurteilen, erfüllt die Anforderung nicht.

Drittens müssen betroffene Personen informiert werden. Bewerber, Mitarbeitende, Kreditantragsteller haben das Recht zu wissen, wenn eine KI an einer sie betreffenden Entscheidung beteiligt ist. Diese Information muss aktiv erfolgen, nicht auf Nachfrage.

Viertens sind ernsthafte Betriebsvorfälle zu melden. Die Verordnung definiert, was als ernsthafter Vorfall gilt, und verlangt die Meldung an die zuständige nationale Marktüberwachungsbehörde.

Im Beschäftigungskontext kommt fünftens dazu: Arbeitnehmer und Arbeitnehmervertreter müssen über den KI-Einsatz informiert werden. In Deutschland bedeutet das den Betriebsrat, unabhängig vom AI-Act-Stichtag. Was das konkret auslöst, haben wir bereits in Teil 1 dieser Serie vertieft.

Der Sonderfall, der in der Praxis am häufigsten übersehen wird: die KI am Telefon

Ein Kommentar zu Teil 2 hat einen Punkt gesetzt, den ich selbst nicht auf dem Schirm hatte. Björn von Meyenn, der bei onsoft Gesprächsaufzeichnung für Telefonie unter DSGVO und AI Act anbietet, schrieb sinngemäß: Bei Text lässt sich menschliche Aufsicht noch nachbilden, weil ein Protokoll vorliegt. Am Telefon hat die Aufsicht nichts zu lesen, wenn niemand das Gespräch selbst aufbewahrt. Er legt sein eigenes wirtschaftliches Interesse dabei offen. Der Einwand trifft trotzdem einen realen Punkt, er braucht nur eine saubere Abgrenzung, weil sonst eine Pflicht behauptet wird, die es für den Normalfall gar nicht gibt.

Wann ein Voice-Bot überhaupt in diese Pflichten fällt

Nicht jeder Sprachassistent ist ein Hochrisiko-System. Ein Voice-Bot, der Paketstatus durchgibt oder Termine verschiebt, fällt in aller Regel unter begrenztes Risiko. Dort greift Artikel 50, also die Pflicht, dem Anrufer offenzulegen, dass er mit einer KI spricht. Menschliche Aufsicht nach Artikel 26 verlangt der AI Act in diesem Fall gar nicht, weil Artikel 26 ausschließlich für Hochrisiko-Systeme gilt. Wer hier pauschal von Aufsichtspflichten spricht, überdehnt die Verordnung.

Die Schwelle wird an einer anderen Stelle überschritten. Sobald das System die Stimme selbst auswertet, also Emotion oder Stimmung erkennt, fällt es unter Anhang III, Punkt 1(c) und ist hochriskant. Das ist keine Randerscheinung: In Contact-Center-Produkten wird Sentimentanalyse regelmäßig als Komfortfunktion mitverkauft, ohne dass jemand die regulatorische Folge mitliest. Richtet sich dieselbe Analyse auf Beschäftigte statt auf Kunden, ist sie nach Artikel 5 nicht hochriskant, sondern schlicht verboten. Dieselbe Schwelle wird ebenfalls überschritten, wenn der Bot am Telefon an Entscheidungen über Kreditwürdigkeit oder den Zugang zu wesentlichen Leistungen mitwirkt.

Was ab dieser Schwelle fehlt

Ist der Bot hochriskant, greift Artikel 26 vollständig, einschließlich Absatz 6: Der Betreiber muss die automatisch erzeugten Protokolle des Systems mindestens sechs Monate aufbewahren, soweit sie in seinem Verfügungsbereich liegen.

Genau hier liegt die Lücke, die von Meyenn beschreibt. Diese Protokolle sind die Logs des KI-Systems, nicht das Gespräch. Sie halten fest, was das System erkannt zu haben glaubt, etwa eine klassifizierte Absicht mit einem Konfidenzwert und die daraus abgeleitete Weiterleitung. Was der Anrufer tatsächlich gesagt hat, in welchem Tonfall, mit welcher Zwischenfrage, steht dort nicht. Eine Aufsichtsperson, die im Nachhinein prüfen soll, ob die Einordnung richtig war, prüft damit die Selbstauskunft des Systems gegen sich selbst. Formal sind die Protokolle vorhanden, inhaltlich fehlt der Teil, auf den es ankommt.

Wichtig ist, was daraus nicht folgt. Der AI Act verpflichtet nicht zur Audioaufzeichnung. Wer sie einführt, trifft eine eigenständige Entscheidung, die eine eigene datenschutzrechtliche Grundlage braucht. In Deutschland ist das nach Auffassung der Aufsichtsbehörden praktisch die Einwilligung der Anrufer nach Artikel 6 Absatz 1 Buchstabe a DSGVO, weil sich ein berechtigtes Interesse angesichts milderer Mittel wie stichprobenhaftem Mithören meist nicht tragen lässt. In regulierten Bereichen wie dem Wertpapierhandel bestehen daneben ohnehin eigene Aufzeichnungspflichten aus MiFID II.

Das Ergebnis für die Praxis ist damit unbequem, aber klar: Wer einen Voice-Bot mit Stimmungserkennung einkauft, muss vor dem Livegang zwei Dinge zugleich klären, nämlich worauf sich die geforderte menschliche Aufsicht später inhaltlich stützen soll und auf welcher Rechtsgrundlage das dafür nötige Material überhaupt entstehen darf. Diese Entscheidung nach hinten zu schieben heißt, sie faktisch zu treffen.

Ein Ausblick, der einen eigenen Artikel verdient

Sobald die Aufzeichnungen existieren, liegt eine Frage nahe, die weit über die Aufsicht hinausgeht: Was darf man mit diesem Material sonst noch tun? Die Mitschnitte lassen sich inhaltlich auswerten, nach Mustern durchsuchen und im nächsten Schritt dafür verwenden, das eigene Sprachmodell zu verbessern.

Hier laufen die beiden Regelwerke deutlich auseinander. Die Aufzeichnung selbst löst den AI Act nicht aus, sie löst die DSGVO aus. Der AI Act meldet sich erst, wenn aus dem Material etwas gebaut wird, und dann nicht als zusätzliche Pflicht, sondern als Rollenwechsel: Nach Artikel 25 wird aus einem Betreiber ein Anbieter, sobald er ein System wesentlich verändert oder seine Zweckbestimmung so verschiebt, dass es hochriskant wird. Fine-Tuning auf eigenen Gesprächsdaten liegt genau auf dieser Linie, und der Wechsel vollzieht sich automatisch, ohne Meldung und ohne Registrierungsschritt.

Datenschutzrechtlich kommen drei Hürden dazu, die sofort greifen: die Zweckbindung, weil eine Einwilligung für Qualitätssicherung keine Einwilligung für Modelltraining ist, die besonderen Datenkategorien, weil in freier Rede Gesundheits- oder Weltanschauungsdaten anfallen, die niemand ausgewählt hat, und schließlich die Löschung, für die es nach dem Training bis heute keine saubere technische Antwort gibt.

Das ist ein eigenes Thema mit eigener Tiefe. Ich nehme es mir in einem der nächsten Artikel vor.

Eine Risikoanalyse in fünf Schritten

Eine handhabbare Risikoanalyse für ein einzelnes KI-System folgt dieser Struktur.

Schritt 1: Den Nutzungsfall präzise beschreiben. Nicht was das Tool heißt, sondern was es faktisch tut, wessen Daten es verarbeitet, und welche Entscheidungen es beeinflusst oder trifft. “KI-gestützte Bewerberauswahl” ist weniger präzise als “System, das Lebensläufe gegen definierte Kriterien bewertet, einen Score vergibt und eine priorisierte Shortlist für den zuständigen HR-Manager erstellt.”

Schritt 2: Prüfen, ob der Use Case in eine der acht Annex-III-Kategorien fällt. Das ist oft eine klare Ja/Nein-Frage, wenn der Nutzungsfall in Schritt 1 präzise genug formuliert wurde.

Schritt 3: Die eigene Rolle klären. Provider, Deployer, oder beides? Im Zweifel mit dem Datenschutzbeauftragten oder einem spezialisierten Rechtsanwalt abstimmen.

Schritt 4: Die Pflichten je Rolle identifizieren und gegen den aktuellen Stand abgleichen. Was ist bereits erfüllt? Was fehlt? Wer im Unternehmen ist für die Umsetzung zuständig?

Schritt 5: Das Ergebnis dokumentieren. Ein strukturiertes Dokument, das den Nutzungsfall, die Kategorisierung, die eigene Rolle und die abgeleiteten Maßnahmen festhält, ist die Grundlage für alle weiteren Schritte und für eine mögliche Prüfung durch Aufsichtsbehörden.

Der häufigste Fehler dabei: mit Schritt 5 anzufangen. Dokumentation als Reaktion auf eine drohende Prüfung, ohne die inhaltliche Analyse vorher gemacht zu haben. Das Ergebnis sind Dokumente, die formal aussehen, aber bei einer echten Prüfung nicht standhalten.

Zurück zum Beispiel aus Teil 2

Der Mittelständler mit der HR-KI. Nutzungsfall präzise beschrieben: automatische Bewerbervorauswahl durch ein zugekauftes System, das Lebensläufe bewertet und eine Shortlist erstellt. Kategorie klar: Annex III, Punkt 4. Rolle klar: Deployer.

Was nun zu tun ist: Den Anbietervertrag prüfen, ob er die für Provider verpflichtende Dokumentation enthält — technische Doku und Nutzungsanleitung. Die eigene Prozessgestaltung so anpassen, dass eine menschliche Prüfung der KI-Shortlist stattfindet, die tatsächlich funktioniert und nicht nur auf dem Papier steht. Bewerber im Prozessablauf darüber informieren, dass eine KI beteiligt ist. Den Betriebsrat einbinden.

Was dieser letzte Punkt in Deutschland konkret bedeutet, haben wir bereits in Teil 1 dieser Serie geklärt.