Hochrisiko-KI nach AI Act: Einstufung und Betreiberpflichten.

Der Zeitplan wurde geändert – die Vorarbeit bleibt

Mit der Verordnung (EU) 2026/1744 wurde der Anwendungszeitplan für Hochrisiko-KI angepasst. Die Änderung trat am 27. Juli 2026 in Kraft. Nach der aktuellen Übersicht der Bundesnetzagentur gelten die Anforderungen für die in Anhang III genannten Einsatzbereiche ab dem 2. Dezember 2027; für bestimmte KI-Systeme in regulierten Produkten nach Anhang I beginnt die Anwendung am 2. August 2028.

Die Europäische Kommission hat am 19. Mai 2026 einen Entwurf für Leitlinien zur Hochrisiko-Einstufung veröffentlicht. Die Konsultation endete am 23. Juli 2026. Entwurf und Beispiele sind nicht bindend und nicht abschließend. Unternehmen können daraus eine Arbeitsstruktur ableiten, sollten die endgültigen Leitlinien und nationale Behördenhinweise aber weiter beobachten. Stand dieser fachlichen Einordnung ist der 7. September 2026.

Spätere Anwendungszeitpunkte bedeuten keinen allgemeinen Aufschub für KI-Governance. Datenschutz, Arbeitsrecht, Informationssicherheit, Artikel 4 zur KI-Kompetenz und bereits anwendbare Transparenzpflichten müssen unabhängig davon geprüft werden. Dieser Beitrag dient der betrieblichen Orientierung und ersetzt keine rechtliche Einzelfallberatung.

Die Einstufung beginnt beim Zweck, nicht beim Produktnamen

Dasselbe Basismodell kann in einem internen Recherchewerkzeug, einer Bewerberauswahl oder einem sicherheitsrelevanten Produkt völlig unterschiedliche Aufgaben erfüllen. Entscheidend ist deshalb, wofür der Anbieter das System vorgesehen hat und wie die Organisation es tatsächlich verwendet. Beschaffung, Fachprozess und technische Integration müssen gemeinsam betrachtet werden.

Ein belastbares Einstufungsblatt beschreibt nicht nur das Werkzeug. Es verbindet Geschäftszweck, betroffene Personen, erzeugte Bewertung, nachfolgende Entscheidung und Systemaktion. Dadurch wird sichtbar, ob die KI lediglich Informationen vorbereitet, Menschen priorisiert oder Zugang, Auswahl beziehungsweise Sicherheit wesentlich beeinflusst.

• beabsichtigter Zweck laut Produktunterlagen und Vertrag
• konkrete Aufgabe der KI im eigenen Sollprozess
• Personen oder Produkte, auf die sich das Ergebnis auswirkt
• Eingaben, Ausgaben und verbindliche Datenquellen
• Entscheidung, die nach der Ausgabe getroffen oder ausgelöst wird
• eigene Anpassungen, neue Zwecke und automatisierte Schreibrechte

Zuerst die eigene Rolle pro Einsatz bestimmen

Ein Unternehmen, das ein KI-System unter eigener Verantwortung nutzt, ist im AI Act grundsätzlich Betreiber. Beschäftigte, die das System im Rahmen ihrer Arbeit bedienen, werden dadurch nicht jeweils zu eigenständigen Betreibern. Der Hersteller oder Dienstleister bleibt häufig Anbieter – die Rollen können sich jedoch verschieben.

Wer ein System unter eigenem Namen bereitstellt, dessen Zweck wesentlich verändert oder eine relevante Änderung vornimmt, kann Anbieterpflichten übernehmen. Diese Einordnung sollte vor einer technischen Anpassung erfolgen, nicht erst nach dem Produktivstart. Verträge, Modellkonfiguration und Schnittstellenarchitektur müssen deshalb denselben dokumentierten Zweck widerspiegeln.

Zwei Einstufungswege getrennt prüfen

Der erste Weg betrifft KI, die selbst ein in Anhang I genanntes Produkt ist oder als Sicherheitsbauteil eines solchen Produkts dient. Zusätzlich muss dieses Produkt nach dem einschlägigen Unionsrecht eine Konformitätsbewertung durch eine unabhängige Stelle durchlaufen. Beide Voraussetzungen müssen zusammen betrachtet werden.

Der zweite Weg führt über Anhang III. Er nennt bestimmte Anwendungen in acht Bereichen: Biometrie, kritische Infrastruktur, Bildung und berufliche Ausbildung, Beschäftigung und Personal, Zugang zu wesentlichen privaten oder öffentlichen Diensten, Strafverfolgung, Migration und Grenzkontrolle sowie Rechtspflege und demokratische Prozesse. Nicht jede KI in diesen Branchen ist automatisch hochriskant; maßgeblich ist die konkret beschriebene Verwendung.

Für ein Unternehmen bedeutet das: Erst Produktbezug und Konformitätsweg prüfen, dann die konkrete Anhang-III-Funktion. Branchenetiketten oder eine pauschale Liste eingesetzter Modelle reichen als Einstufungsnachweis nicht aus.

Die Ausnahme nach Artikel 6 Absatz 3 eng dokumentieren

Ein in Anhang III genannter Einsatz kann ausnahmsweise nicht als hochriskant gelten, wenn er kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte darstellt und das Ergebnis einer Entscheidung nicht wesentlich beeinflusst. Artikel 6 Absatz 3 nennt dafür begrenzte Fallgruppen: eine enge Verfahrensaufgabe, die Verbesserung eines zuvor abgeschlossenen menschlichen Ergebnisses, das Erkennen von Entscheidungsmustern ohne Ersatz oder unzulässige Beeinflussung der menschlichen Bewertung sowie eine vorbereitende Aufgabe.

Eine Beschriftung als Assistenzsystem oder der Satz ‚Ein Mensch entscheidet am Ende‘ genügt dafür nicht. Zu prüfen ist, welche Informationen die Person sieht, ob sie realistisch abweichen kann, ob Zeit- oder Mengendruck zu einer faktischen Übernahme führt und welche Folge das KI-Ergebnis im System auslöst. Sobald Profilbildung natürlicher Personen erfolgt, bleibt ein von Anhang III erfasster Einsatz nach der Verordnung hochriskant.

Wer die Ausnahme nutzt, sollte Zweck, Fallgruppe, Risikobewertung, Entscheidungswirkung und menschliche Kontrollmöglichkeit nachvollziehbar festhalten. Die Dokumentation ist ein Ergebnis der konkreten Prüfung – keine automatisch wirksame Freistellung.

Betreiberpflichten in einen ausführbaren Ablauf übersetzen

Artikel 26 richtet sich an Betreiber von Hochrisiko-KI. Zu den zentralen Aufgaben gehören die Nutzung nach Anleitung, geeignete menschliche Aufsicht, die Qualität der vom Betreiber kontrollierten Eingabedaten, die Überwachung des Betriebs und der Umgang mit Risiken oder schwerwiegenden Vorfällen. Vom System erzeugte Protokolle sind, soweit sie unter der Kontrolle des Betreibers stehen, grundsätzlich mindestens sechs Monate aufzubewahren; andere Rechtsvorgaben können längere oder abweichende Fristen verlangen.

Diese Pflichten sollten an den tatsächlichen Prozessschritten verankert werden. Eine allgemeine KI-Richtlinie sagt noch nicht, wer einen Vorgang stoppt, welche Datenquelle korrigiert wird oder wie ein Fehler an Anbieter, Fachbereich und gegebenenfalls zuständige Stelle gelangt.

• Eingang: zulässige Daten, Datenquelle, Aktualität und Mindestqualität prüfen
• Ausführung: freigegebene Systemversion, Zweckgrenze und Bedienungsanleitung sichern
• Aufsicht: fachkundige und befugte Personen mit echter Korrektur- und Stoppmöglichkeit benennen
• Entscheidung: KI-Ausgabe, menschliche Bewertung und nachfolgende Systemaktion unterscheidbar halten
• Protokollierung: relevante Eingaben, Versionen, Ausgaben, Eingriffe und Statuswechsel zusammenführen
• Monitoring: Fehlermuster, Abweichungen, Übernahmeverhalten und technische Störungen beobachten
• Eskalation: riskante Nutzung aussetzen, Verantwortliche erreichen und Wiederanlauf kontrollieren
• Meldung: mögliche schwerwiegende Vorfälle mit belastbaren Zeit- und Systeminformationen bearbeiten

Ein KI-Fehler ist nicht automatisch ein schwerwiegender Vorfall

Der AI Act verwendet einen engen Begriff. Ein schwerwiegender Vorfall liegt vor, wenn ein Vorfall oder eine Fehlfunktion eines KI-Systems direkt oder indirekt zum Tod oder zu einer schweren gesundheitlichen Schädigung, zu einer schweren und unumkehrbaren Störung kritischer Infrastruktur, zu einer Verletzung unionsrechtlicher Pflichten zum Schutz der Grundrechte oder zu schweren Sach- oder Umweltschäden führt. Eine unzutreffende Antwort, ein Modellabbruch oder eine technische Störung erfüllt diese Schwelle nicht allein.

Die Erstbewertung darf trotzdem nicht bei der Fehlerart stehen bleiben. Entscheidend ist die tatsächliche oder mögliche Wirkung im Prozess: Wurde eine Person benachteiligt, eine sicherheitsrelevante Aktion ausgelöst, ein kritischer Dienst gestört oder ein geschütztes Recht beeinträchtigt? Zusätzlich ist zu prüfen, ob das KI-System den Schaden verursacht haben könnte oder ein solcher Zusammenhang naheliegt. Diese Fragen sollten getrennt dokumentiert werden, weil sich die Bewertung mit neuen Tatsachen ändern kann.

Stand 27. September 2026 gelten die besonderen Regeln für Hochrisiko-Systeme nach dem geänderten Zeitplan noch nicht allgemein: für Anhang-III-Systeme beginnen sie am 2. Dezember 2027, für bestimmte Systeme nach Anhang I am 2. August 2028. Der Ablauf sollte dennoch heute vorbereitet werden. Bereits anwendbare Pflichten, etwa für Anbieter von GPAI-Modellen mit systemischem Risiko, sowie Datenschutz-, Produkt- oder Cybersicherheitsvorgaben können unabhängig davon greifen.

Der Vorfallablauf beginnt mit Eindämmung und Beweissicherung

Die rechtliche Einstufung darf notwendige Schutzmaßnahmen nicht verzögern. Sobald ein KI-System auffällig wirkt, sollte der Betrieb den betroffenen Vorgang sichern, die Wirkung begrenzen und einen eindeutigen Awareness-Zeitpunkt festhalten. Je nach Risiko kann das bedeuten, eine automatische Aktion auszusetzen, Fälle in eine manuelle Prüfung umzuleiten oder eine bestimmte Systemversion kontrolliert zu sperren.

Gleichzeitig muss die Nachweiskette erhalten bleiben. Modell- und Systemversion, Eingaben, referenzierte Daten, Ausgaben, Regeln, menschliche Eingriffe und nachfolgende Systemaktionen gehören unter dieselbe Fall-ID. Eine pauschale Kopie sämtlicher Inhalte ist weder technisch noch datenschutzrechtlich automatisch richtig; gesichert werden die für Ursachenanalyse, Wirkung und Entscheidung erforderlichen Informationen mit geregeltem Zugriff.

Der folgende Ablauf ist ein betriebliches Ordnungsmodell der DAG, keine gesetzlich vorgegebene Reihenfolge. Er trennt Sofortmaßnahmen von den Entscheidungen, die eine fachliche, technische und rechtliche Prüfung benötigen.

• Erkennen: Meldung, Monitoring-Signal oder fachliche Auffälligkeit mit Zeitpunkt und Quelle erfassen
• Begrenzen: riskante Aktionen stoppen, betroffene Fälle sichern und einen kontrollierten Ersatzweg aktivieren
• Belegen: Systemstand, Datenherkunft, Ausgabe, menschliche Entscheidung und Folgeaktion manipulationsgeschützt verbinden
• Bewerten: Wirkung, betroffene Personen oder Systeme, mögliche Kausalität und Wiederholungsrisiko prüfen
• Zuordnen: Anbieter-, Betreiber-, Einführer- und Händlerrollen sowie zuständige interne Stellen bestimmen
• Entscheiden: AI-Act-Meldeweg und weitere Prüfpfade mit eigenen Kriterien, Fristen und Empfängern freigeben
• Beheben: Korrektur testen, Wiederanlauf genehmigen und Monitoring für vergleichbare Fälle nachschärfen

Betreiber informieren – Anbieter melden und untersuchen

Bei einem Hochrisiko-System muss der Betreiber einen erkannten schwerwiegenden Vorfall unverzüglich zuerst dem Anbieter und anschließend dem Einführer oder Händler sowie den zuständigen Marktüberwachungsbehörden mitteilen. Für die eigentliche Meldung nach Artikel 73 ist grundsätzlich der Anbieter verantwortlich. Verträge sollten deshalb erreichbare Sicherheitskontakte, Mindestinformationen, Vertretungen und die Zusammenarbeit bei der Ursachenanalyse festlegen, statt lediglich allgemein auf Support zu verweisen.

Artikel 73 nennt für Anbieter eine Obergrenze von 15 Tagen ab Kenntnis des Anbieters oder gegebenenfalls des Betreibers. Bei einem weitverbreiteten Verstoß oder einer schweren und unumkehrbaren Störung kritischer Infrastruktur beträgt die Obergrenze zwei Tage; bei einem Todesfall zehn Tage. In allen Fällen verlangt die Verordnung unverzügliches Handeln, sobald der kausale Zusammenhang oder dessen naheliegende Wahrscheinlichkeit festgestellt beziehungsweise beim Todesfall vermutet wird. Wenn für eine rechtzeitige Meldung nötig, kann zunächst ein unvollständiger Bericht und später ein vollständiger Bericht folgen.

Nach der Meldung untersucht der Anbieter den Vorfall, bewertet das Risiko und ergreift Korrekturmaßnahmen. Bevor das betroffene System so verändert wird, dass eine spätere Ursachenbewertung beeinträchtigt werden könnte, muss die zuständige Behörde über diese Maßnahme informiert werden. Für Unternehmen folgt daraus eine praktische Trennung: Schutzmaßnahmen dürfen sofort greifen, während Veränderungen an Beweislage und Systemzustand kontrolliert und nachvollziehbar erfolgen.

AI Act, Datenschutz und Cybersicherheit getrennt prüfen

Derselbe Sachverhalt kann mehrere Regelwerke berühren, ohne dass deren Kriterien oder Fristen identisch sind. Werden personenbezogene Daten offengelegt, verändert oder unzugänglich, ist zusätzlich eine Datenschutzverletzung zu prüfen; Artikel 33 DSGVO nennt für eine gegebenenfalls erforderliche Behördenmeldung grundsätzlich 72 Stunden ab Bekanntwerden. Ein Sicherheitsereignis, ein Produktfehler oder eine Betriebsstörung kann daneben eigene Meldewege nach anwendbarem Cyber-, Produkt- oder Sektorrecht auslösen.

Eine zentrale Fallakte kann gemeinsame Tatsachen halten, sollte die Entscheidungen aber nicht vermischen. Jeder Prüfpfad braucht einen eigenen Status: anwendbare Rolle, Auslösekriterium, Awareness-Zeitpunkt, Frist, Empfänger, Freigabe und Meldungsreferenz. So bleibt erkennbar, warum ein Vorgang nach einem Regelwerk gemeldet wurde und nach einem anderen nicht.

Auch Beschwerden und Vorfallmeldungen sind verschieden. Das seit 2026 verfügbare AI-Act-Beschwerdeverfahren ermöglicht Personen und Organisationen, mögliche Verstöße an zuständige Stellen zu geben. Es ersetzt weder den internen Incident-Prozess noch die besonderen Meldepflichten von Anbietern und Betreibern. Dieser Beitrag ordnet betriebliche Abläufe ein und ersetzt keine rechtliche Einzelfallberatung.

Ein Tabletop-Test zeigt, ob der Meldeweg wirklich funktioniert

Ein dokumentierter Prozess ist erst belastbar, wenn er unter Zeitdruck durchgespielt wurde. Ein geeignetes Szenario beginnt mit einer fachlichen Meldung außerhalb der Kernzeit, unvollständigen Informationen und einer KI-Ausgabe, die bereits eine Folgeaktion ausgelöst hat. Das Team muss Systemversion, betroffene Fälle und Ansprechpartner finden, ohne Beweise zu überschreiben oder den produktiven Betrieb unkontrolliert weiterlaufen zu lassen.

Der Test sollte mindestens Fachverantwortung, technischen Betrieb, Informationssicherheit, Datenschutz beziehungsweise Compliance und eine entscheidungsbefugte Vertretung einbeziehen. Gemessen werden nicht nur Minuten bis zur Reaktion, sondern auch die Qualität der gesicherten Informationen, die Eindeutigkeit der Rollen und die kontrollierte Rückkehr in den Betrieb.

• Ist ein 24/7 erreichbarer interner Eingang für kritische KI-Auffälligkeiten benannt?
• Kann das Team betroffene System-, Modell-, Prompt-, Regel- und Datenversionen eindeutig bestimmen?
• Sind Anbieter, Einführer, Händler und zuständige interne Freigaben mit Vertretung erreichbar?
• Laufen AI-Act-, Datenschutz- und Sicherheitsprüfung aus derselben Faktenbasis, aber mit getrennten Entscheidungen?
• Verhindert der Wiederanlauf, dass unbearbeitete Fälle oder dieselbe fehlerhafte Version erneut wirken?

Menschliche Aufsicht braucht Information, Zeit und Befugnis

Menschliche Aufsicht ist nur wirksam, wenn die zuständige Person Zweck, Grenzen und Signale des Systems versteht. Sie muss die konkrete Ausgabe in ihrem Kontext bewerten, eine Übernahmeverzerrung erkennen und das Ergebnis ignorieren, korrigieren oder den Prozess stoppen können. Dafür braucht sie nicht nur Schulung, sondern auch eine passende Oberfläche und organisatorische Rückendeckung.

In einem integrierten Ablauf sollte die Prüfoberfläche die maßgeblichen Eingaben, das KI-Ergebnis, relevante Referenzdaten, Unsicherheiten und die vorgesehene Folgeaktion zusammen anzeigen. Wenn ein Klick bereits eine schwer umkehrbare Entscheidung in ERP, HR- oder Fachsystem auslöst, müssen Freigabe, Berechtigung und technische Bestätigung entsprechend streng ausgelegt sein.

Die Nachweiskette endet nicht an der Modell-API

Viele Fehler entstehen nicht im Modell allein, sondern an Systemgrenzen: veraltete Stammdaten, falsch zugeordnete Personen, abgeschnittene Dokumente, unklare Berechtigungen oder wiederholte Schreibversuche. Die Hochrisiko-Vorbereitung muss deshalb Datenquellen, Modellservice, Regelwerk, Prüfoberfläche und Zielsystem als einen zusammenhängenden Ablauf behandeln.

Vom Anbieter werden mindestens Zweckbeschreibung, Gebrauchsanweisung, Leistungsgrenzen, notwendige Eingabedaten, Protokollzugang, bekannte Risiken, Änderungsinformationen und Unterstützungswege benötigt. Das Unternehmen ergänzt eigene Rollen, Berechtigungen, Datenquellen, Prozessregeln und Vorfallwege. Nur beide Seiten zusammen ergeben einen im Betrieb nutzbaren Nachweis.

• Welche System- und Modellversion war aktiv?
• Welche Daten stammten aus welchem führenden System und welchem Stand?
• Welche Ausgabe, Regel und menschliche Entscheidung führten zur Folgeaktion?
• Wer konnte korrigieren, aussetzen und den Wiederanlauf freigeben?
• Wie werden Anbieteränderungen erkannt, bewertet und kontrolliert ausgerollt?

Ein schlanker Umsetzungsplan bis 2027 und 2028

Der sinnvollste Startpunkt ist ein gemeinsames Inventar aus Fachprozess, Produktinformationen und technischer Integration. Anschließend werden eindeutige Hochrisiko-Fälle, begründete Nicht-Hochrisiko-Fälle und offene Einstufungen getrennt. So konzentriert sich die vertiefte Arbeit auf Anwendungen mit hoher Wirkung, ohne die übrige KI-Landschaft aus dem Blick zu verlieren.

Für Systeme, die bereits vor dem 2. Dezember 2027 eingesetzt wurden, nennt die Bundesnetzagentur eine Übergangsregel: Die Hochrisiko-Pflichten greifen grundsätzlich dann, wenn das System ab diesem Zeitpunkt in seiner Auslegung erheblich verändert wird. Ob eine Änderung erheblich ist und welche weiteren Vorschriften schon vorher gelten, muss fallbezogen geprüft werden. Ein vorsorgliches Änderungsregister verhindert, dass Zweck- oder Integrationsänderungen unbemerkt bleiben.

• 0–30 Tage: KI-Inventar, Zwecke, Rollen und offene Einstufungen konsolidieren
• 30–90 Tage: Anhang-I- und Anhang-III-Prüfung samt Artikel-6-Absatz-3-Begründungen abschließen
• 90–180 Tage: Betreiberkontrollen, Anbieterunterlagen und technische Lücken priorisieren
• danach: Aufsicht, Protokollierung, Monitoring, Stopp- und Vorfallwege im echten Prozess testen
• vor dem jeweiligen Stichtag: Rechtsstand, finale Leitlinien, Systemversion und Nachweise erneut prüfen