- Published on
Biometrische Fernidentifizierung — Hochrisiko nach Annex III
- Authors

- Name
- Tails Azimuth
Use-Case-Definition
Gegenstand dieser Page sind KI-Systeme zur biometrischen Fernidentifizierung: Systeme, die eine Person aus der Distanz — ohne deren aktive Mitwirkung — durch Abgleich biometrischer Merkmale wie Gesicht, Gang oder Stimme gegen eine Referenzdatenbank identifizieren. Charakteristisch ist die Eins-zu-viele-Abfrage: Ein erfasstes Merkmal wird gegen viele gespeicherte Identitäten geprüft, um zu bestimmen, um welche Person es sich handelt. Abzugrenzen ist dieser Use-Case scharf von der biometrischen Verifikation (Eins-zu-eins-Abgleich, etwa Entsperren eines Geräts oder Bestätigung an einer Zugangsschranke), bei der die Person aktiv behauptet, eine bestimmte Identität zu haben. Die Verifikation ist ausdrücklich vom Hochrisiko-Tatbestand ausgenommen. Ebenfalls zu trennen ist die biometrische Kategorisierung (Ableitung von Attributen wie Alter oder Geschlecht) und die Emotionserkennung — beides eigene Use-Cases mit eigenem Pflichtenprofil.
Annex-III-Verortung
Der Use-Case ist in Annex III Nr. 1 Buchstabe a des EU AI Act (Verordnung (EU) 2024/1689) verortet, im Bereich „Biometrik". Erfasst sind dort Systeme zur biometrischen Fernidentifizierung; ausdrücklich ausgenommen werden Systeme, deren einziger Zweck die biometrische Verifikation ist, also die Bestätigung, dass eine Person diejenige ist, die sie zu sein vorgibt.
Entscheidend ist die Abgrenzung zum Verbotstatbestand: Der Einsatz von Systemen zur Echtzeit-Fernidentifizierung in öffentlich zugänglichen Räumen zu Strafverfolgungszwecken ist nach Art. 5 grundsätzlich untersagt und nur unter eng begrenzten, im Gesetz aufgeführten Ausnahmen und mit Genehmigung zulässig. Die Hochrisiko-Einstufung nach Annex III greift dagegen für die übrigen zulässigen Konstellationen — insbesondere die nachträgliche (post) Fernidentifizierung und Einsätze außerhalb des verbotenen Kernbereichs. Die Zuordnung eines konkreten Systems hängt damit an drei Fragen: Echtzeit oder nachträglich, öffentlich zugänglicher Raum oder nicht, Strafverfolgung oder anderer Zweck.
Warum Hochrisiko
Biometrische Fernidentifizierung greift tief in Grundrechte ein, weil sie Personen ohne deren Wissen und ohne aktive Mitwirkung erfassen und individualisieren kann. Betroffen sind das Recht auf Achtung des Privatlebens, der Schutz personenbezogener Daten und — bei flächigem Einsatz — die Freiheit, sich unbeobachtet im öffentlichen Raum zu bewegen, zu versammeln und zu äußern. Schon das Bewusstsein möglicher Identifizierung kann rechtmäßiges Verhalten hemmen (Chilling-Effekt).
Der zentrale technische Risiko-Mechanismus ist die Fehlidentifikation. Kein Abgleichsystem arbeitet perfekt: Falsch-Positive führen dazu, dass eine unbeteiligte Person mit einer gesuchten verwechselt wird; Falsch-Negative lassen Treffer unentdeckt. Erkennungsgenauigkeit variiert nachweislich mit Bildqualität, Blickwinkel, Beleuchtung und Alter der Referenzdaten — und sie ist über demografische Gruppen hinweg nicht gleich verteilt. Schlechtere Trefferqualität bei bestimmten Hauttönen, Geschlechtern oder Altersgruppen kann zu systematisch ungleicher Fehlerbelastung führen. Weil an eine Identifizierung erhebliche Konsequenzen geknüpft sein können — von der Ansprache durch Behörden bis zu freiheitsentziehenden Maßnahmen — wiegt jeder Fehler schwer.
Betroffen sind damit mehrere Schutzgüter zugleich: Privatsphäre, Datenschutz, Diskriminierungsverbot und die Ausübung von Versammlungs- und Meinungsfreiheit. Genau diese Kombination begründet die Hochrisiko-Einstufung — unabhängig von der Leistungsfähigkeit des eingesetzten Modells.
Pflichten für Provider
Wer ein solches System entwickelt und in der EU in Verkehr bringt, trägt die Provider-Pflichten aus Kapitel III des EU AI Act. Vor dem Inverkehrbringen ist ein Risikomanagementsystem über den gesamten Lebenszyklus einzurichten (Art. 9), das die spezifischen Fehlidentifikations- und Diskriminierungsrisiken adressiert. Die Trainings-, Validierungs- und Testdaten unterliegen den Data-Governance-Anforderungen aus Art. 10, einschließlich der Prüfung auf Verzerrungen und der Repräsentativität der Referenzpopulation.
Weiter sind technische Dokumentation (Art. 11), automatische Protokollierung (Art. 12), Transparenz und Gebrauchsanweisung (Art. 13), wirksame menschliche Aufsicht durch Design (Art. 14) sowie ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit (Art. 15) sicherzustellen. Für Systeme dieses Bereichs verlangt Art. 14 ausdrücklich, dass eine Identifizierung nicht ohne getrennte Bestätigung durch mindestens zwei kompetente Personen zu einer Maßnahme führt. Das System durchläuft eine Konformitätsbewertung, erhält die CE-Kennzeichnung und wird in der EU-Datenbank registriert. Die Gebrauchsanweisung muss den Deployer über Erkennungsgenauigkeit, bekannte Fehlerquellen und die Grenzen des Systems in Kenntnis setzen.
Pflichten für Deployer
Die einsetzende Stelle ist Deployer und trägt die Pflichten aus Art. 26. Das System ist entsprechend der Gebrauchsanweisung zu betreiben, mit geeigneten Eingabedaten zu versorgen und laufend zu überwachen; automatisch erzeugte Logs sind aufzubewahren. Ein Treffer darf nicht ungeprüft in eine Maßnahme übersetzt werden: Die menschliche Aufsicht muss eine gemeldete Identifizierung eigenständig verifizieren können, bevor Konsequenzen folgen.
Setzt eine Behörde oder eine im öffentlichen Auftrag handelnde Stelle das System ein, ist regelmäßig eine Grundrechte-Folgenabschätzung nach Art. 27 durchzuführen. Unabhängig davon greifen die datenschutzrechtlichen Vorgaben, im Strafverfolgungskontext die Regelungen der einschlägigen Datenschutzrichtlinie für Behörden. Über die Rechtsräume hinweg gilt: Für Deployer in DE, den übrigen EU27-Staaten sowie — bei EU-Marktbezug — in UK und CH treten nationale Vorgaben zu Videoüberwachung, polizeilicher Datenverarbeitung und Datenschutz hinzu. Wer als Deployer ein System zu Zwecken einsetzt, die in den Verbotsbereich des Art. 5 fallen, kann sich nicht auf die Hochrisiko-Regeln berufen — dann greift das Verbot.
Was Audits prüfen
- Zweck- und Zulässigkeitsnachweis: Dokumentation, dass Einsatzart (Echtzeit/nachträglich), Ort und Zweck außerhalb des Verbots nach Art. 5 liegen und die Rechtsgrundlage tragfähig ist.
- Genauigkeits- und Fairness-Evidenz: Erkennungsraten, Falsch-Positiv- und Falsch-Negativ-Quoten, aufgeschlüsselt nach relevanten demografischen Gruppen.
- Referenzdaten-Governance: Herkunft, Rechtsgrundlage, Aktualität und Repräsentativität der Vergleichsdatenbank sowie Löschkonzepte.
- Menschliche Aufsicht in der Praxis: Belege, dass Treffer durch qualifizierte Personen verifiziert werden, inklusive der von Art. 14 geforderten getrennten Bestätigung vor einer Maßnahme.
- Logging und Rückverfolgbarkeit: lückenlose Protokolle, die eine einzelne Identifizierung auf Eingabe, Modellversion, Schwellenwert und Zeitpunkt zurückführen.
- Grundrechte-Folgenabschätzung: bei öffentlichen Stellen der Nachweis der Bewertung nach Art. 27.
Konforme Architektur
Eine konforme Implementierung trennt Treffer und Maßnahme strikt: Das System liefert einen Kandidaten-Treffer samt Konfidenzwert, die Entscheidung über eine Konsequenz bleibt bei qualifizierten Menschen und wird als eigener, dokumentierter Schritt erfasst — mit der von Art. 14 geforderten Doppelbestätigung, wo eine Maßnahme folgen soll. Konfigurierbare Schwellenwerte, eine bewusst niedrig gehaltene Automatisierung und klare Eskalationspfade begrenzen das Risiko, dass ein statistischer Treffer als Gewissheit missverstanden wird. Ein manipulationssicheres Evidenz- und Protokoll-Layer hält Eingabebild, Referenzquelle, Schwellenwert, Modellversion, Treffer und menschliche Entscheidung revisionssicher zusammen.
Konzeptionell bildet ein solches Design den Kern von Trust-Infrastructure: Nicht das Erkennungsmodell allein, sondern die nachweisbare Kette aus Datenherkunft, Genauigkeitsprüfung, menschlicher Verifikation und lückenloser Protokollierung macht den Einsatz audit-ready. Compliance ist dann die Folge dieser Nachweisbarkeit, nicht das Ziel für sich.
Zur Einordnung, wann Biometrik verboten (Art. 5) und wann hochrisiko ist, siehe die Risikoklassen im Überblick: ki-risikostufe.de. Gesamtkontext zum EU AI Act: Leitfaden auf eu-ai-verordnung.de.
AEGIRA AI Navigator unterstützt die Risikoklassifizierung und Pflicht-Ableitung für Annex-III-Use-Cases — aegira.ai.