AI Act: Hochrisikosysteme in der Praxis (HR, Finanzen, Scoring)

Ein Unternehmen baut ein Tool für die Rekrutierung, das Kandidaten anhand von Lebensläufen rankt. Oder eine Kredit-Pipeline, die Anträge vorbewertet. Oder ein Scoring-System für B2B-Kunden, das Leads priorisiert. Jedes dieser Tools tut genau das, worauf der AI Act besonders achtet: Es beeinflusst die Situation eines konkreten Menschen in einer Weise, die ihm Vorteile bringen oder schaden kann.

2026 ist das keine Theorie mehr. Ab August 2026 haben die Aufsichtsbehörden ein Durchsetzungsmandat, und die Strafen betragen bis zu 3 % des globalen Umsatzes für Verstöße gegen Hochrisikosysteme. Im Folgenden beschreiben wir, welche Systeme diesem Regime unterliegen, welche Pflichten sich daraus ergeben und wie man sie so gestaltet, dass Compliance den Geschäftswert nicht blockiert.

Anhang III des AI Act listet Hochrisikobereiche direkt auf. Für polnische Unternehmen sind vier relevant:

Die Grenze zwischen „begrenztem Risiko“ und „hohem Risiko“ verläuft entlang einer Frage: Bewertet oder klassifiziert das System einen Menschen in einer Weise, die eine konkrete Entscheidung über ihn beeinflusst? Ein Chatbot, der Fragen aus einer Wissensdatenbank beantwortet, stellt ein begrenztes Risiko dar. Derselbe Chatbot, der während des Gesprächs die Kreditwürdigkeit eines Kunden bewertet und auf dieser Grundlage das Angebot ändert, fällt unter hohes Risiko.

Wenn ein System als Hochrisikosystem eingestuft wird, legt der AI Act sechs konkrete Pflichten fest. Es handelt sich nicht um Empfehlungen.

1. Technische Dokumentation. Bevor das System in Betrieb geht, muss der Anbieter eine Dokumentation erstellen, die beschreibt: Zweck und Umfang des Systems, die für Training oder Kalibrierung verwendeten Daten, Qualitäts- und Genauigkeitsmetriken, bekannte Einschränkungen und Grenzfälle sowie Logging-Pfade. Die Dokumentation muss den Aufsichtsbehörden auf Anfrage zur Verfügung stehen.

2. Menschliche Aufsicht. Jede für einen Menschen relevante Entscheidung muss durch eine menschliche Bestätigung gehen oder technisch umkehrbar sein. Muster: Die KI empfiehlt, der Mensch genehmigt oder lehnt ab, das System protokolliert beide Aktionen. Der Human-Gate ist nicht optional.

3. Transparenz gegenüber der betroffenen Person. Die Person, die vom System betroffen ist, hat das Recht zu wissen, dass die Entscheidung durch KI unterstützt wurde, und kann eine Erklärung der Logik verlangen. Diese Anforderung muss technisch umgesetzt werden, nicht nur in den AGB erwähnt werden.

4. Risikomanagement. Ein kontinuierlicher Zyklus: Risikoidentifikation vor der Implementierung, Monitoring nach der Implementierung, Aktualisierung der Dokumentation bei Modell- oder Datenänderungen. Mindestens einmal jährlich; häufiger bei wesentlichen Änderungen.

5. Systemregistrierung. Anbieter von Hochrisikosystemen müssen ihre Produkte in der EU-Datenbank für KI registrieren. Für intern genutzte Systeme (Deployer) liegt die Registrierungspflicht beim Anbieter des Systems, aber der Deployer muss sicherstellen, dass das System registriert ist.

6. DPIA bei der Verarbeitung personenbezogener Daten. Wenn das System personenbezogene Daten verarbeitet (was fast immer der Fall ist), gilt parallel die DSGVO. Eine Datenschutz-Folgenabschätzung ist erforderlich, wenn ein hohes Risiko besteht. In der Praxis: Kandidaten-Scoring, Kreditscoring und Kundenprofiling erfordern immer eine DPIA.

Ein Rekrutierungssystem ist ein klassisches Beispiel für ein Hochrisikosystem nach dem AI Act. Der entscheidende Ablauf sieht so aus: Das Modell liest den Lebenslauf, extrahiert Merkmale, klassifiziert den Kandidaten und reiht die Bewerbungen ein. Jeder dieser Schritte ist erlaubt. Das Problem entsteht, wenn das Ranking-Ergebnis ohne Überprüfung durch den Personalverantwortlichen angewendet wird.

Drei technische Anforderungen, die erfüllt sein müssen, bevor ein solches System in Produktion geht:

• Der Klassifikator muss mit anonymisierten Merkmalen arbeiten. Name (Hinweis auf Geschlecht und Ethnizität), Alter und Wohnadresse müssen vor der Weitergabe an das Bewertungsmodell entfernt werden. Nicht durch Richtlinien, sondern durch PII-Masking auf Code-Ebene.
• Jede Empfehlung muss ein Erklärungs-Log haben. Welche Merkmale haben die Platzierung dieses Kandidaten entschieden? Ohne dieses Log kann weder Diskriminierungsfreiheit nachgewiesen noch die Frage des Kandidaten nach der Entscheidungsgrundlage beantwortet werden.
• Human-Gate vor der Kommunikation mit dem Kandidaten. Keine automatische Ablehnungsnachricht wird ohne Genehmigung des Personalverantwortlichen versendet. Die KI schlägt vor, der Mensch genehmigt.

Mehr zur Architektur einer Rekrutierungspipeline und Trainingsdaten behandelt der Artikel KI in HR und Rekrutierung.

Kreditscoring und Versicherungsrisikobewertung sind Bereiche, in denen der AI Act die strengsten Pflichten auferlegt. Der Grund ist einfach: Die Entscheidung über die Gewährung oder Ablehnung eines Kredits kann die Lebenssituation eines Menschen radikal verändern.

Spezifische Anforderungen für Finanzsysteme:

• Erklärbarkeit jeder Entscheidung. Ein Kunde, dem ein Kredit mit Hilfe eines KI-Systems verweigert wurde, hat das Recht auf eine Erklärung der Hauptfaktoren der Entscheidung. SHAP-Werte, LIME oder ein anderer Erklärbarkeitsmechanismus muss produktiv implementiert sein, nicht nur im analytischen Notebook.
• Testbarkeit auf Diskriminierung. Das Scoring-Modell muss regelmäßig an Kontrolldatensätzen getestet werden, ob sich die Genehmigungsraten systematisch zwischen geschützten Gruppen unterscheiden. Ein Unterschied, der nicht durch finanzielle Variablen erklärt werden kann, ist ein regulatorisches Problem.
• Menschliche Aufsicht bei Grenzentscheidungen. Anträge, deren Score im Unsicherheitsbereich liegt, sollten zur Überprüfung durch einen Analysten gehen, nicht automatisch durch den Algorithmus abgelehnt werden.
• Datenisolierung und Data Residency. Finanzdaten von Kunden sollten die kontrollierte Infrastruktur des Instituts nicht ohne Verschlüsselung und Datenverarbeitungsverträge verlassen. Self-Hosting der Inference-Schicht für besonders sensible Daten ist Standard, kein Luxus.

In Polen hat die Finanzaufsichtsbehörde (KNF) 2025 Leitlinien für KI in Finanzdienstleistungen herausgegeben, die den AI Act um sektorspezifische Anforderungen ergänzen. Jedes Scoring-System für von der KNF regulierte Institute muss hinsichtlich beider Anforderungskataloge auditiert werden.

Nicht jedes Lead-Scoring ist ein Hochrisiko. Die Klassifizierung von B2B-Leads nach Passgenauigkeit zum ICP (Branche, Unternehmensgröße, Aktivität auf der Website) stellt ein begrenztes Risiko dar, solange das Ergebnis nicht über den Zugang zu einer Dienstleistung entscheidet.

Das Problem entsteht, wenn das Scoring beginnt, Preise, die Verfügbarkeit von Angeboten oder die Behandlung von Kunden zu beeinflussen. Dann kann das System je nach Bereich in das Hochrisikoregime fallen oder zumindest eine DPIA erfordern.

Eine praktische Regel für die Systemgestaltung:

Lead-Scoring, das auf anonymer Aktivität (Websites, UTM, Unternehmenstyp) basiert, ist sicher. Scoring, das Finanzdaten, Daten aus sozialen Medien und das Verhalten einer bestimmten Person kombiniert, fällt in den regulierten Bereich.

Die Einhaltung des AI Act für Hochrisikosysteme ist keine Schicht, die am Ende des Projekts hinzugefügt wird. Sechs Elemente, die von der ersten Codezeile an designed werden:

Log jedes Schritts. Jeder Modellaufruf, jede Generierung einer Empfehlung, jede Genehmigung oder Ablehnung durch einen Menschen wird mit Zeitstempel, Sitzungs-ID und ID der betroffenen Person protokolliert. Das Log ist unveränderlich und wird für Finanzsysteme mindestens 5 Jahre, für Rekrutierungssysteme mindestens für die Dauer der Beschwerdebearbeitung aufbewahrt.

Human-Gate als technische Sperre. Human-Gate ist keine Erinnerung „denk daran, zu prüfen“. Es ist die technische Unmöglichkeit, ein Ergebnis an den Endnutzer zu senden, ohne die Bestätigung einer berechtigten Person. Es wird als Bedingung in der Pipeline implementiert, nicht als Bitte in der Dokumentation.

Guardrails mit Ablehnungs-Log. Jede Anfrage, die das System aufgrund von Guardrails ablehnt (z. B. außerhalb des Geltungsbereichs, Versuch, eine Entscheidung außerhalb der Systemkompetenzen zu erzwingen), wird protokolliert. Das Ablehnungs-Log dient als Nachweis, dass das System wie vorgesehen funktioniert.

Erklärungsmodul. Jede Entscheidung, die einen Menschen betrifft, muss technisch nachvollziehbar sein: Was hat das Modell gesehen, welche Merkmale waren relevant, was war das Ergebnis. Strukturierter Output mit einem obligatorischen Feld reasoning erleichtert den Aufbau dieses Moduls.

Diskriminierungstests vor der Produktion. Vor der Implementierung wird der Klassifikator auf einem Testdatensatz mit kontrollierter Verteilung geschützter Merkmale ausgeführt, und die Unterschiede in den positiven Raten werden gemessen. Die Ergebnisse fließen in die technische Dokumentation ein.

Modelländerungsmanagement. Eine Änderung des Basismodells, der Daten oder des Entscheidungsschwellenwerts erfordert eine erneute Validierung und Aktualisierung der Dokumentation. Stille Modellwechsel in der Produktion sind nicht erlaubt.

Mehr zum Monitoring der Qualität von KI-Systemen nach der Implementierung behandelt ein dedizierter Artikel.

Die Datenschutz-Folgenabschätzung (DPIA) ist nach der DSGVO erforderlich, wenn die Verarbeitung ein hohes Risiko darstellen kann. In der Praxis erfordert jedes Hochrisikosystem des AI Act, das personenbezogene Daten verarbeitet, eine DPIA. Also fast immer.

Minimaler Inhalt einer DPIA für ein KI-System:

• Beschreibung des Verarbeitungszwecks und der Eingabedaten
• Bewertung der Notwendigkeit: Kann das Ziel mit weniger Daten erreicht werden?
• Risikoidentifikation: Unbefugter Zugriff, algorithmische Diskriminierung, fehlerhafte Entscheidung
• Abhilfemaßnahmen: Verschlüsselung, PII-Masking, Datenisolierung, Human-Gate, Logging
• Überprüfung nach 12 Monaten oder bei wesentlichen Systemänderungen

Die DPIA ist ein Arbeitsdokument, keine Formalität. Wenn sie sorgfältig erstellt wird, wird sie zur besten technischen Projektdokumentation und verkürzt die Reaktionszeit auf Anfragen der Aufsichtsbehörden von Wochen auf Stunden. Die Methodik der DPIA wird im Artikel AI Act und DSGVO 2026 detaillierter beschrieben.

Beschreiben Sie Ihr System (HR, Scoring, Finanzen) und den Umfang der verarbeiteten Daten, und das Modell bewertet vorläufig, welche AI-Act-Pflichten gelten könnten – als Ausgangspunkt für das Gespräch mit einem Juristen, nicht als Ersatz (Playground: PII maskiert, keine Speicherung):

Nicht immer. Scoring basierend auf Firmendaten (Branche, Größe, Aktivität) ohne Einfluss auf den Zugang zu einer Dienstleistung stellt in der Regel ein begrenztes Risiko dar. Ein hohes Risiko entsteht, wenn das Scoring natürliche Personen in den im AI Act genannten Bereichen betrifft – Beschäftigung, Finanzen, Versicherungen, öffentliche Dienstleistungen. Wenn das Scoring Entscheidungen über Einzelunternehmer als natürliche Personen betrifft (z. B. Mikrokredite), können die AI-Act-Pflichten gelten. Es ist immer ratsam, dies vor der produktiven Implementierung mit einem Juristen zu klären.

Durch Log und Test. Das Log muss für jede Empfehlung enthalten: welche Merkmale mit welcher Gewichtung entscheidend waren. Vor der Implementierung wird der Klassifikator auf einem Datensatz mit kontrollierter Verteilung geschützter Merkmale (Geschlecht, Alter, Ethnizität durch Namen angezeigt) ausgeführt, und es wird gemessen, ob die positiven Empfehlungsraten zwischen den Gruppen vergleichbar sind. Ein Unterschied von mehr als einigen Prozentpunkten erfordert eine Korrektur des Modells oder der Daten. Die Testergebnisse fließen als Nachweis in die technische Dokumentation ein, nicht als bloße Erklärung.

Der AI Act unterscheidet zwischen Anbieter und Deployer, befreit aber kleine Unternehmen nicht von den Pflichten für Hochrisikosysteme. Mikrounternehmen und kleine Firmen profitieren von einem vereinfachten Format der technischen Dokumentation, aber die inhaltlichen Pflichten bleiben bestehen: menschliche Aufsicht, Logging, Transparenz, DPIA, sofern relevant. Die Größe des Systems und die Ressourcen beeinflussen die Art der Implementierung, nicht ob die Anforderungen gelten.

Wenn die Änderung die Entscheidungslogik oder die Eingabedaten beeinflusst. Ein Wechsel des Basismodells (neue Version des LLM, anderer Embedding), Änderung der Trainingsdaten, Änderung des Entscheidungsschwellenwerts über einen festgelegten Margen, Hinzufügen neuer Eingabemerkmale – jede dieser Änderungen erfordert einen erneuten Diskriminierungstest, eine Aktualisierung der Dokumentation und einen Eintrag im Änderungsprotokoll. Eine Änderung des System-Prompts ohne Änderung der Entscheidungslogik erfordert in der Regel keine vollständige Neuvalidierung, aber einen Eintrag im Änderungsprotokoll und einen Smoke-Test.

Nein. Guardrails blockieren unautorisierte Anfragen und begrenzen den Antwortumfang des Systems – das ist eine notwendige Sicherheitsebene. Der AI Act verlangt jedoch, dass ein Mensch die Möglichkeit hat, jede für eine Person relevante Entscheidung zu überprüfen und abzulehnen. Guardrails sind keine menschliche Entscheidung – sie sind ein Filter vor der Entscheidung. Beide Ebenen müssen vorhanden sein und werden separat protokolliert.