EU AI Act: Wann KI-Systeme als hochriskant gelten – Artikel 6 und Anhang III

Der EU AI Act legt präzise fest, wann KI-Systeme als hochriskant einzustufen sind – und damit das strenge Pflichtenregime der Artikel 8 bis 15 auslösen. Praktisch entscheidend ist Artikel 6: Er öffnet zwei Einstufungspfade und eine enge Ausnahme für bestimmte Anwendungsfälle des Anhangs III. Gerade in HR-, Bildungs- und Kreditkontexten ist die Abgrenzung knifflig, weil dort Grundrechte und Lebensentscheidungen berührt sind. Vertiefende Hintergründe zu Lernpfaden finden sich unter EU AI Act Schulung und Compliance-Trainings.

Zwei Einstufungspfade nach Artikel 6

Erstens gilt ein KI-System als hochriskant, wenn es als Sicherheitsbauteil oder als Produkt einem der in Anhang I genannten Harmonisierungsrechtsakte unterliegt und eine Dritt-Konformitätsbewertung erforderlich ist (z. B. Maschinen, Medizinprodukte, Fahrzeuge). Zweitens sind eigenständige Systeme hochriskant, wenn sie in einem der in Anhang III beschriebenen Anwendungsfelder eingesetzt werden. Dieser Katalog bündelt sensible Entscheidungskontexte wie Biometrie, kritische Infrastrukturen, Bildung, Beschäftigung und Personalmanagement, Zugang zu grundlegenden Diensten, Strafverfolgung, Migration/Asyl/Grenzkontrolle sowie Rechtspflege und demokratische Prozesse.

Anhang III und die enge Negativabgrenzung

Der Anhang III macht die Einstufung über den Nutzungskontext greifbar: Erfasst sind etwa CV-Screening und Bewerberbewertung, leistungs- und verhaltensbezogene HR-Systeme, die Bewertung von Lernergebnissen oder Bildungszugang, Kreditwürdigkeitsprüfung und Versicherungsrisiko-/Preisbildung sowie Systeme zur Beeinflussung von Wahlergebnissen oder Wahlverhalten. Gleichwohl kennt Artikel 6 Absatz 3 eine enge Negativabgrenzung: Ein dort genanntes System ist ausnahmsweise nicht hochriskant, wenn es kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte birgt und nur eine eng umrissene Funktion erfüllt – etwa eine reine Verfahrensaufgabe, eine Ergebnisverbesserung nach menschlicher Entscheidung, eine Mustererkennung ohne substanzielle Einflussnahme oder eine vorbereitende Tätigkeit.

Wichtig ist die Rückausnahme: Sobald ein Annex-III-System Profiling natürlicher Personen betreibt, greift die Ausnahme nicht – es bleibt hochriskant. Wer sich auf die Negativabgrenzung stützt, muss die Nicht-Hochrisiko-Bewertung dokumentieren und registrieren; bis zum 2. Februar 2026 sollen Leitlinien und Praxisbeispiele der Kommission Orientierung bieten.

Pflichtenarchitektur (Art. 8–15) – was praktisch zählt

Mit der Hochrisiko-Einstufung wird ein Pflichtenbündel scharf geschaltet: ein risikobasierter Lebenszyklusprozess (Art. 9), belastbare Daten-Governance und Bias-Management (Art. 10), technische Dokumentation mindestens nach Anhang IV (Art. 11), automatische Protokollierung relevanter Ereignisse (Art. 12), Transparenz und Betriebsanleitungen mit Leistungsgrenzen (Art. 13), wirksame menschliche Aufsicht inklusive Override (Art. 14) sowie Anforderungen an Genauigkeit, Robustheit und Cybersicherheit (Art. 15). Für Betrieb und Technik bedeutet das, Logging, Post-Market-Monitoring und Sicherheitsmaßnahmen als Compliance-Themen zu begreifen – ein Feld, das sich an der Schnittstelle von Entwicklung und Betrieb bewegt; Hinweise dazu liefert IT-Teams: Logging, Security und Deployment.

Konsequenzen für Trainings, Checklisten und Rollen

Für Anbieter und Betreiber verändern sich Schulungen spürbar. Statt eines reinen „Go-live“-Fokus ist ein belastbares Lifecycle-Setup gefragt – mit klaren Rollen, Dokumentation und Überprüfbarkeit. Projektleitungen sollten die Abgrenzung nach Art. 6 früh methodisch begleiten; Anregungen liefert Projektleitung: Lifecycle- und Oversight-Methoden.

• Lifecycle-Denken verankern: Risikomanagement als kontinuierlicher Prozess von Design über Betrieb bis Decommissioning, inklusive vorhersehbarer Fehlanwendung.
• Daten-Governance-Modul: Herkunft, Repräsentativität und Bias-Minderung; sensible Daten nur unter Schutzvorkehrungen zur Bias-Korrektur.
• Logging- und Override-Übungen: Ereignisprotokolle lesen, Vorfälle rekonstruieren, Automatisierungsbias erkennen und Entscheidungen übersteuern.
• Security- und Red-Team-Perspektive: Schutz gegen data/model poisoning und adversarial inputs; klare Zuständigkeiten für Incident Response.
• Abgrenzungsentscheidung dokumentieren: Bei Nicht-Hochrisiko-Einstufung Begründung, Kontext, Funktionsumfang und Risikoanalyse nachvollziehbar festhalten und registrieren.

Gerade in HR-, Bildungs- und Kreditprozessen wirkt die Gestaltung der Nutzeroberfläche und der Präsentation (Score, Ranking, Empfehlung) stark auf die Frage, ob Ergebnisse „wesentlich beeinflusst“ werden – und damit auf die Einstufung. Das spricht für interdisziplinäre Reviews, bevor Systeme skaliert werden.

Schluss: Die Formel für Sorgfalt lautet Kontext plus Lebenszyklus. Wer die zwei Einstufungspfade, die eng gefasste Ausnahme und die Pflichtenarchitektur zusammen denkt, reduziert Rechtsunsicherheit – und schafft die Basis für verantwortliche KI in sensiblen Entscheidungen.