Eine Bewerbungssoftware bewertet Menschen mit Behinderung auffällig schlechter, ein Risikomodell benachteiligt bestimmte Altersgruppen oder ein Empfehlungssystem liefert je nach Herkunft systematisch andere Ergebnisse. Um solche Verzerrungen sichtbar zu machen, müssen Teams oft genau jene Merkmale vergleichen, die im Datenschutz besonders geschützt sind. Der neue AI Omnibus schafft dafür mehr rechtlichen Spielraum. Er macht aus sensiblen Daten aber kein frei verfügbares Testmaterial.

Die EU-Kommission meldete am 27. Juli 2026 das Inkrafttreten der Verordnung (EU) 2026/1744. Neben verschobenen Fristen, erweiterten Sandboxes und Erleichterungen für kleinere Unternehmen enthält die Reform eine praktisch wichtige Änderung: Unter engen Voraussetzungen dürfen Anbieter und Betreiber von KI-Systemen besondere Kategorien personenbezogener Daten verarbeiten, um Bias zu erkennen und zu korrigieren. Für österreichische KMU beginnt die Arbeit deshalb nicht mit dem Datensatz, sondern mit einer dokumentierten Notwendigkeitsprüfung.

Warum faire KI manchmal sensible Merkmale braucht

Ein Modell kann Gruppen benachteiligen, obwohl ein geschütztes Merkmal gar nicht als Eingabe vorgesehen ist. Postleitzahl, Berufsverlauf, Sprachmuster oder Nutzungsverhalten können indirekt mit Herkunft, Gesundheit, Religion oder anderen geschützten Eigenschaften zusammenhängen. Wer nur die durchschnittliche Trefferquote misst, übersieht solche Unterschiede leicht.

Ein belastbarer KI-Bias-Test vergleicht deshalb Ergebnisse zwischen sinnvoll definierten Gruppen. Das kann beispielsweise zeigen, ob eine Anwendung qualifizierte Bewerberinnen und Bewerber mit einer bestimmten Behinderung häufiger aussortiert oder ob ein Scoring für eine ethnische Gruppe mehr falsche Alarme produziert. Ohne Vergleichsmerkmal bleibt die Verzerrung unsichtbar. Mit dem Merkmal entsteht jedoch eine besonders risikoreiche Verarbeitung.

Genau diesen Zielkonflikt adressiert der neue Artikel 4a des AI Acts. Die Reform behandelt Bias-Erkennung und -Korrektur als erhebliches öffentliches Interesse, erlaubt die Verarbeitung aber nur ausnahmsweise und unter kumulativen Schutzbedingungen. Die verbindliche Verordnung im Amtsblatt ist dabei wichtiger als vereinfachte Checklisten oder Produktversprechen.

Was der AI Omnibus tatsächlich erweitert

Schon die ursprüngliche Regelung kannte eine spezielle Rechtsgrundlage für Anbieter von Hochrisiko-KI. Neu ist die breitere Reichweite: Auch Betreiber von Hochrisiko-Systemen sowie Anbieter und Betreiber anderer KI-Systeme oder Modelle können besondere Datenkategorien ausnahmsweise verarbeiten, wenn ein relevanter Bias Gesundheit oder Sicherheit gefährden, Grundrechte beeinträchtigen oder zu unionsrechtlich verbotener Diskriminierung führen kann.

Das ist für Unternehmen wichtig, die keine eigenen Basismodelle entwickeln. Ein österreichischer Betrieb kann etwa ein externes Bewerbertool, ein Modell zur Betrugserkennung oder eine KI-gestützte Priorisierung einsetzen und als Betreiber mit Verzerrungen konfrontiert sein. Die Rollenfrage bleibt trotzdem entscheidend: Anbieter, Betreiber, Auftragsverarbeiter und weitere Beteiligte haben nicht automatisch dieselben Pflichten oder dieselben Zugriffsmöglichkeiten.

Die neue Regel schafft außerdem keine allgemeine Pflicht, für jedes KI-Tool sensible Daten zu erheben. Artikel 4a Absatz 2 sagt ausdrücklich, dass daraus keine Verpflichtung zu Bias-Tests entsteht. Ebenso wenig ersetzt die Bestimmung die DSGVO. Die Reform stellt klar, dass das Datenschutzrecht weiterhin gilt. Unternehmen brauchen daher sowohl eine AI-Act-Begründung als auch einen vollständigen Datenschutzprozess.

Sechs Bedingungen, die vor dem Datensatz stehen

Der Verordnungstext formuliert keine unverbindlichen Empfehlungen. Die Bedingungen müssen zusammen erfüllt sein. Für ein Projektbriefing lassen sie sich in sechs Prüffragen übersetzen.

1. Reichen synthetische oder anonymisierte Daten wirklich nicht aus?

Das Team muss zuerst mit weniger eingriffsintensiven Daten arbeiten. Nur wenn Bias-Erkennung und -Korrektur damit nicht wirksam möglich sind, kommt die Ausnahme in Betracht. Eine pauschale Aussage wie „Echte Daten sind genauer“ reicht nicht. Sinnvoll ist ein kurzer Testbericht: Welche synthetischen, aggregierten oder anonymisierten Varianten wurden geprüft, welche Verzerrung blieb damit unmessbar und warum?

2. Ist die Verarbeitung strikt notwendig?

Der Zweck muss enger sein als eine allgemeine Verbesserung des Modells. Es braucht eine konkrete Bias-Hypothese und einen möglichen Schaden: etwa eine erhöhte Falsch-Negativ-Rate bei einer geschützten Gruppe. Daten, die für diese Hypothese nichts beitragen, gehören nicht in den Test. Das gilt auch für historische Merkmale, die „vielleicht später nützlich“ sein könnten.

3. Ist eine Weiterverwendung technisch begrenzt?

Der Testdatensatz darf nicht bequem in Produktanalyse, Marketing oder Training zurückfließen. Die Verordnung verlangt technische Begrenzungen der Wiederverwendung sowie moderne Sicherheits- und Datenschutzmaßnahmen einschließlich Pseudonymisierung. Praktisch heißt das: getrennte Umgebung, getrennte Berechtigungen, klarer Exportstopp und keine ungeprüfte Übernahme in das produktive Datenlager.

4. Sind Zugriffe eng kontrolliert und dokumentiert?

Nur ausdrücklich autorisierte Personen mit passenden Vertraulichkeitspflichten sollen Zugriff erhalten. Ein gemeinsam genutztes Teamkonto oder eine offene Cloud-Freigabe widerspricht diesem Ziel. Zugriffe müssen nachvollziehbar sein. Das Protokoll sollte zeigen, wer wann auf welche Daten zugegriffen und welche Auswertung durchgeführt hat.

5. Bleiben die Daten bei den verantwortlichen Stellen?

Artikel 4a verlangt, dass die besonderen Daten nicht an andere Parteien übermittelt, übertragen oder für sie zugänglich werden. Das ist bei SaaS- und Cloud-Setups ein kritischer Punkt. Bevor Daten hochgeladen werden, muss geklärt sein, ob der KI-Anbieter, ein Supportteam, ein Unterauftragnehmer oder eine Telemetriekomponente technisch zugreifen könnte. Eine Vertragsklausel allein beseitigt einen faktischen Zugriff nicht.

6. Gibt es einen kurzen, durchsetzbaren Löschplan?

Die Daten sind zu löschen, sobald der Bias korrigiert ist oder die festgelegte Speicherdauer endet, je nachdem, was früher eintritt. „Bis zum Projektende“ ist zu ungenau, wenn das Projekt keinen festen Endpunkt hat. Besser sind ein verantwortlicher Owner, ein konkretes Ereignis, ein spätestes Datum und ein überprüfbarer Löschbeleg.

Ein Praxisablauf für österreichische Unternehmen

Die Ausnahme wird beherrschbar, wenn das Unternehmen den Test als eigenes, begrenztes Vorhaben behandelt. Folgender Ablauf eignet sich für KMU, die eine KI-Lösung einkaufen oder selbst anpassen.

  1. Anwendungsfall und Entscheidung erfassen: Dokumentieren Sie, wofür die KI eingesetzt wird, welche Personen betroffen sind und ob das Ergebnis eine Entscheidung vorbereitet, priorisiert oder automatisiert.
  2. Bias-Hypothese formulieren: Benennen Sie die vermutete Verzerrung, das geschützte Merkmal, die relevante Kennzahl und den möglichen Schaden. Ohne Hypothese wächst der Datensatz schneller als der Erkenntnisgewinn.
  3. Rollen und Datenwege klären: Halten Sie fest, wer Anbieter, Betreiber und technischer Dienstleister ist. Prüfen Sie Speicherorte, Supportzugriffe, Protokollierung, Unterauftragnehmer und Exporte.
  4. Alternativen testen: Beginnen Sie mit anonymisierten, synthetischen oder ausreichend aggregierten Daten. Bewahren Sie den Nachweis auf, weshalb diese Variante gegebenenfalls nicht genügt.
  5. Freigabe vor Zugriff: Datenschutz, Fachverantwortliche und IT-Sicherheit sollen Zweck, Datenumfang, Umgebung, Berechtigungen und Löschregel bestätigen, bevor echte sensible Merkmale verarbeitet werden.
  6. Getrennt messen und korrigieren: Führen Sie den Test in einer isolierten Umgebung durch. Halten Sie Kennzahlen, Schwellenwerte, Änderungen am Modell oder Prozess und die erneute Messung fest.
  7. Löschen und nachweisen: Entfernen Sie die besonderen Daten nach der Korrektur oder spätestens zum festgelegten Termin. Schließen Sie den Vorgang mit Zugriffsprotokoll, Ergebnis und Löschbestätigung ab.

Ein bestehendes KI-Inventar ist dafür die richtige Ausgangsbasis. Der AdSimple-Beitrag „KI-Tools starten mit dem Inventar“ zeigt, welche Anwendungen, Datenflüsse und Verantwortlichkeiten zuerst sichtbar werden müssen. Ein Bias-Test ist dann kein isoliertes Statistikexperiment, sondern eine kontrollierte Änderung an diesem Inventar.

Drei Szenarien für eine saubere Abgrenzung

Bewerbervorauswahl: Ein Unternehmen stellt fest, dass ein Ranking für technisch gleich qualifizierte Personen mit Behinderung seltener eine Empfehlung abgibt. Die passende Messfrage lautet nicht, ob das Modell „insgesamt fair“ ist, sondern ob sich Fehlerquoten bei vergleichbarer Qualifikation systematisch unterscheiden. Bevor Gesundheitsdaten einbezogen werden, sind vorhandene Qualitätsdaten, synthetische Profile und anonymisierte Auswertungen zu testen. Bleibt die Abweichung nur mit dem geschützten Merkmal messbar, braucht der begrenzte Test eine eigene Freigabe. Die finale Personalentscheidung sollte weiterhin von befugten Menschen nachvollziehbar getroffen werden.

Priorisierung im Kundenservice: Eine KI sortiert Beschwerden nach Dringlichkeit. Dialekt, ungewöhnliche Grammatik oder Hinweise auf eine Behinderung könnten indirekt zu einer niedrigeren Priorität führen. Hier ist zunächst zu prüfen, ob Qualitätskennzahlen nach neutralen, nicht sensiblen Merkmalen bereits eine systematische Lücke zeigen. Ein pauschaler Import sämtlicher Kundendaten wäre unverhältnismäßig. Sinnvoller ist eine kleine, zweckgebundene Stichprobe mit klarer Hypothese, getrennten Prüfcodes und einem festen Löschzeitpunkt. Ergibt sich ein Bias, kann oft schon eine Änderung der Eingaberegeln oder der menschlichen Eskalation helfen.

Risikobewertung in einem digitalen Dienst: Ein Modell erzeugt mehr Fehlalarme für eine bestimmte Gruppe und sperrt dadurch legitime Vorgänge. Der Test muss zwischen Betrugsprävention und Diskriminierungsrisiko unterscheiden. Besondere Datenkategorien dürfen nicht zu neuen Risikomerkmalen im Produkt werden. Sie dienen ausschließlich der begrenzten Kontrolle und Korrektur. Nach der Messung sollte das Unternehmen dokumentieren, welche Schwelle, Gewichtung oder Prozessregel geändert wurde und ob ein erneuter Test die Abweichung tatsächlich reduziert hat, ohne andere Gruppen schlechterzustellen.

Diese Beispiele zeigen einen gemeinsamen Grundsatz: Der Testdatensatz ist kein zweites Kundenprofil. Er ist ein zeitlich und technisch begrenztes Prüfmittel. Je genauer Zweck, Vergleich und Abbruchkriterium definiert sind, desto weniger Daten braucht das Team und desto leichter lässt sich die Notwendigkeit später erklären.

Welche Datenschutzdokumente angepasst werden können

Der neue Artikel 4a verlangt ausdrücklich, die Gründe für die strikte Notwendigkeit und für das Scheitern weniger eingriffsintensiver Alternativen im Verzeichnis von Verarbeitungstätigkeiten festzuhalten. Je nach Risiko können außerdem eine Datenschutz-Folgenabschätzung, eine Interessen- und Rechtsgrundlagenprüfung, technische Schutzkonzepte sowie Informationen für betroffene Personen relevant werden.

Eine DSFA ist keine automatisch passende Antwort auf jedes KI-Projekt. Wenn sensible Daten, systematische Bewertungen oder folgenreiche Entscheidungen zusammenkommen, sollte das Team die Schwellenfrage jedoch ernsthaft prüfen. Der Beitrag zum EDPB-Template für Datenschutz-Folgenabschätzungen hilft dabei, Zweck, Risiken, Maßnahmen und Restunsicherheiten strukturiert zu erfassen.

Auch die öffentlich sichtbare Datenschutzerklärung muss zur tatsächlichen Website-Verarbeitung passen. Werden über Bewerbungsformular, Kundenportal oder Supportsystem Daten an ein KI-gestütztes Verfahren übergeben, dürfen interne Projektnotiz und Website-Text nicht auseinanderlaufen. Mit dem AdSimple Datenschutz Generator lassen sich passende Datenschutztexte für zahlreiche Website-Dienste erstellen und laufend aktualisieren. Er ersetzt weder die Klassifizierung nach AI Act noch die projektspezifische Prüfung des Bias-Tests, unterstützt aber die konsistente Dokumentation der Website-Dienste.

Ein 90-Minuten-Workshop vor dem ersten KI-Bias-Test

Für ein kleines Team genügt zunächst ein konzentrierter Termin mit Fachbereich, Datenschutz und IT. Das Ziel ist keine vollständige rechtliche Endbewertung, sondern eine belastbare Stop-or-Go-Entscheidung.

  • 0 bis 15 Minuten: Anwendung, betroffene Personen, Entscheidung und vermuteten Schaden beschreiben.
  • 15 bis 30 Minuten: Anbieter- und Betreiberrollen sowie alle technischen Datenempfänger aufzeichnen.
  • 30 bis 45 Minuten: geschütztes Merkmal, Vergleichsgruppen, Kennzahlen und gewünschte Korrektur definieren.
  • 45 bis 60 Minuten: synthetische, anonymisierte und aggregierte Alternativen bewerten und dokumentieren.
  • 60 bis 75 Minuten: isolierte Umgebung, Pseudonymisierung, Berechtigungen, Zugriffskontrolle und Exportstopp festlegen.
  • 75 bis 90 Minuten: Löschereignis, Verantwortliche, Nachweise sowie nötige Datenschutzdokumente bestimmen.

Fehlt nach diesem Termin eine klare Bias-Hypothese, ist der Test noch nicht bereit. Fehlt die Kontrolle über Drittzugriffe, ist die gewählte technische Plattform möglicherweise ungeeignet. Fehlt ein Löschereignis, ist der Datensatz zu früh angefordert.

Typische Fehlentscheidungen nach der Reform

„Der AI Act erlaubt sensible Daten jetzt generell.“ Falsch. Die Erlaubnis ist zweckgebunden, ausnahmsweise, strikt notwendig und an alle Schutzbedingungen geknüpft.

„Ein Dienstleister übernimmt den Test, also sind wir nicht betroffen.“ Zu kurz gedacht. Gerade die Rollen, Weisungen und technischen Zugriffe müssen geklärt werden. Die Beschränkung gegenüber anderen Parteien kann ein übliches SaaS-Setup unbrauchbar machen.

„Pseudonymisiert bedeutet anonym.“ Nein. Pseudonymisierte Daten bleiben grundsätzlich personenbezogen, wenn die Zuordnung mit Zusatzinformationen möglich ist. Pseudonymisierung ist eine Schutzmaßnahme, kein Ausstieg aus dem Datenschutzrecht.

„Mehr Daten machen den Fairness-Test automatisch besser.“ Nicht zwingend. Relevante Gruppen, geeignete Kennzahlen und saubere Vergleichsbedingungen sind wichtiger als ein möglichst großer Datensatz. Unklare Merkmale können neue Verzerrungen erzeugen.

„Die verschobenen Hochrisiko-Fristen machen das Thema später relevant.“ Die aktualisierte AI-Act-Zeitleiste gibt Unternehmen mehr Vorbereitungszeit für bestimmte Hochrisikoregeln. Der neue Artikel 4a und die laufende DSGVO-Verantwortung sind dennoch kein Grund, unkontrollierte Datenpools anzulegen.

Fazit: Fairness braucht einen engeren Datenraum

Der AI Omnibus löst einen echten Widerspruch: Verzerrungen lassen sich manchmal nur erkennen, wenn geschützte Merkmale sichtbar werden. Die Lösung ist aber nicht mehr Datensammlung, sondern ein enger, begründeter und überprüfbarer Datenraum. Unternehmen müssen Alternativen testen, Zugriffe begrenzen, Drittzugriffe ausschließen, die Notwendigkeit im Verzeichnis dokumentieren und früh löschen.

Für österreichische KMU ist der beste erste Schritt ein Inventar aus Anwendung, Rollen, Datenwegen und Entscheidungen. Danach folgt die Bias-Hypothese, erst dann der Datensatz. Wenn im Zuge dessen neue Website-Dienste oder Datenübermittlungen sichtbar werden, sollten auch die öffentlichen Hinweise nachgezogen werden. Der Datenschutz Generator unterstützt bei aktuellen Website-Datenschutztexten; die spezielle AI-Act- und DSGVO-Bewertung des Bias-Tests bleibt eine eigene fachliche Aufgabe.

Dieser Beitrag bietet eine allgemeine Orientierung und keine individuelle Rechtsberatung. Bei sensiblen Daten, Beschäftigtenentscheidungen oder Hochrisiko-KI sollte der konkrete Anwendungsfall fachlich und rechtlich geprüft werden.

Quellen und weiterführende Informationen