Art. 49 & 71: Registrierung in der EU-Datenbank für Hochrisiko-KI

Die meisten Pflichten des EU AI Act wirken nach innen: Risikomanagement, Datenqualität, technische Dokumentation, Protokollierung. Sie erzeugen Nachweise, die im Ernstfall gegenüber einer Behörde vorgelegt werden. Artikel 49 in Verbindung mit Artikel 71 der Verordnung (EU) 2024/1689 ist die Ausnahme: Hier wird ein Teil der Compliance-Lage öffentlich sichtbar. Wer ein Hochrisiko-KI-System in der Union in Verkehr bringt oder in Betrieb nimmt, trägt es zuvor in eine von der Kommission betriebene EU-Datenbank ein — und ein wesentlicher Teil dieser Einträge ist für jedermann zugänglich.

Das verändert die Rechnung. Ein unvollständiges Risikomanagementsystem fällt erst bei einer Marktüberwachungsmaßnahme auf. Ein fehlender oder inkonsistenter Datenbankeintrag ist dagegen jederzeit von außen prüfbar — von Aufsichtsbehörden, von Wettbewerbern, von Journalisten, von potenziellen Kunden im Vendor-Assessment.

Was Artikel 71 aufbaut

Artikel 71 verpflichtet die Kommission, in Zusammenarbeit mit den Mitgliedstaaten eine EU-Datenbank für Hochrisiko-KI-Systeme einzurichten und zu pflegen. Erfasst werden die Systeme nach Artikel 6 Absatz 2 — also die in Anhang III gelisteten Hochrisiko-Anwendungsbereiche: Biometrie, kritische Infrastruktur, allgemeine und berufliche Bildung, Beschäftigung und Personalmanagement, Zugang zu wesentlichen privaten und öffentlichen Diensten, Strafverfolgung, Migration und Grenzkontrolle, Rechtspflege und demokratische Prozesse.

Die Datenbank enthält die Angaben, die in Anhang VIII aufgeführt sind. Dazu gehören unter anderem Name und Kontaktdaten des Anbieters, gegebenenfalls des Bevollmächtigten, die Bezeichnung des Systems, seine Zweckbestimmung, der Status (in Verkehr gebracht, in Betrieb genommen, vom Markt genommen), Informationen zur Konformitätsbewertung und zur EU-Konformitätserklärung sowie die Mitgliedstaaten, in denen das System verfügbar ist.

Die Verantwortung für die Richtigkeit dieser Angaben liegt bei der Partei, die sie eingibt. Artikel 71 stellt außerdem klar, dass die Kommission Verantwortlicher im datenschutzrechtlichen Sinne für die Datenbank ist und dass die Daten so wenig personenbezogene Informationen wie möglich enthalten sollen.

Wer eintragen muss — und wann

Artikel 49 verteilt die Registrierungspflicht auf drei Rollen, und diese Verteilung wird in der Praxis regelmäßig verwechselt.

Anbieter (Provider) registrieren sich selbst und ihr Hochrisiko-KI-System nach Anhang III vor dem Inverkehrbringen oder der Inbetriebnahme. Gleiches gilt für Bevollmächtigte von Anbietern ohne Niederlassung in der Union — hier greift der Zusammenhang zu Artikel 22, dessen Bestellungspflicht der Registrierung logisch vorgelagert ist.

Anbieter, die zu dem Ergebnis kommen, dass ihr System trotz Anhang-III-Zugehörigkeit nicht hochriskant ist — also die Ausnahme nach Artikel 6 Absatz 3 in Anspruch nehmen — müssen sich und das System ebenfalls registrieren. Diese Konstellation wird häufig übersehen: Die Ausnahme befreit nicht von der Sichtbarkeit, sie verlagert sie nur. Wer sich auf Artikel 6 Absatz 3 beruft, muss die Bewertung dokumentieren und auf Anforderung vorlegen.

Betreiber (Deployer), die Behörden, Einrichtungen oder Stellen der Union sind — oder in deren Namen handeln —, registrieren sich vor der Inbetriebnahme oder Verwendung ebenfalls und wählen das System aus, dessen Nutzung sie beabsichtigen. Private Betreiber trifft diese Pflicht nicht; für sie gelten die Betreiberpflichten aus Artikel 26.

Für bestimmte Hochrisiko-Systeme in den Bereichen Strafverfolgung, Migration, Asyl und Grenzkontrolle sieht Artikel 49 einen gesonderten, nicht öffentlichen Teil der Datenbank vor. Die Registrierung entfällt dort nicht — sie ist nur einem eingeschränkten Kreis zugänglich, praktisch der Marktüberwachungsbehörde und der Kommission.

Warum das ein Datenqualitätsproblem ist, kein Formularproblem

Der Datenbankeintrag ist kein isoliertes Artefakt. Er zieht seine Angaben aus Unterlagen, die an anderer Stelle entstehen: die Zweckbestimmung aus der technischen Dokumentation nach Artikel 11, der Konformitätsstatus aus dem Verfahren nach Artikel 43, die Konformitätserklärung aus Artikel 47, der Verfügbarkeitsstatus aus dem Vertrieb.

Damit entsteht eine öffentlich einsehbare Konsistenzprobe. Wenn die im Eintrag genannte Zweckbestimmung von der in der Gebrauchsanweisung abweicht, wenn ein System laut Datenbank in Verkehr ist, aber intern längst zurückgezogen wurde, oder wenn eine Konformitätsbewertung angegeben wird, deren Grundlage sich seit einer wesentlichen Änderung verschoben hat — dann ist der Widerspruch nicht verborgen, sondern dokumentiert. Und ein dokumentierter Widerspruch ist ein schlechterer Ausgangspunkt als eine Lücke, weil er den Vorwurf der Unrichtigkeit trägt und nicht nur den der Unvollständigkeit.

Praktisch heißt das: Der Registrierungseintrag braucht einen Owner, einen definierten Auslöser für Aktualisierungen (Statuswechsel, wesentliche Änderung nach Artikel 43 Absatz 4, neue Zielmärkte) und eine Rückbindung an die Quelldokumente. Ohne diese Kette wird der Eintrag ein Schnappschuss, der ab dem Tag nach der Eingabe altert.

Wer sich die Anhang-III-Kategorien und ihre Abgrenzungen genauer ansehen will, findet auf hochrisiko-ki.com eine vertiefte Aufarbeitung der einzelnen Anwendungsbereiche.

Was jetzt sinnvoll vorbereitet wird

Mit dem Enforcement-Termin 02.12.2027 (Digital Omnibus) im Blick ist die Registrierung eine der wenigen Pflichten mit einem harten, terminierten Vorher: Sie muss vor Inverkehrbringen oder Inbetriebnahme erfüllt sein. Das macht sie zu einem Gate im Release-Prozess, nicht zu einer nachgelagerten Dokumentationsaufgabe.

Drei Vorarbeiten tragen unabhängig davon, wie die Datenbank technisch ausgestaltet wird:

Erstens die Rollenklärung je System: Ist die Organisation Anbieter, Betreiber oder beides? Der Rollenwechsel nach Artikel 25 — etwa durch wesentliche Änderung oder Anbringen des eigenen Namens — verschiebt auch die Registrierungspflicht.

Zweitens ein belastbares KI-Systeminventar, das für jedes System die Anhang-III-Zuordnung, den Lebenszyklusstatus und die Zielmärkte führt. Ohne dieses Inventar ist die Frage "Welche unserer Systeme sind registrierungspflichtig?" nicht beantwortbar.

Drittens eine Nachweiskette zwischen Eintrag und Quelle: Jedes Feld im Registrierungsdatensatz sollte auf ein versioniertes Dokument zurückführbar sein, damit eine Aktualisierung nicht als manuelle Neuerhebung stattfindet.

Genau an dieser Stelle greift der Gedanke von Trust-Infrastructure: Nicht ein Formular korrekt auszufüllen, sondern die Evidenzkette so zu führen, dass der öffentliche Eintrag jederzeit nachweisbar dem internen Stand entspricht — und beides gemeinsam altert, statt auseinanderzulaufen.

Mehr zur AEGIRA Trust-Platform: aegira.ai