Kritische Infrastruktur: Hochrisiko-KI nach Annex III Nr. 2

In der öffentlichen Debatte über den EU AI Act dominieren Anwendungsfälle, die unmittelbar Menschen betreffen: Recruiting, Kreditvergabe, Bildung. Eine andere Hochrisiko-Kategorie bleibt dabei oft im Hintergrund, obwohl ihr Ausfall ganze Versorgungssysteme treffen kann — die kritische Infrastruktur. Wenn KI den Verkehr steuert, das Stromnetz balanciert oder die Wasserversorgung überwacht, entscheidet ihre Zuverlässigkeit nicht über eine einzelne Bewerbung, sondern über die Funktionsfähigkeit eines Versorgungsnetzes. Annex III Nr. 2 der Verordnung (EU) 2024/1689 zieht daraus eine klare Konsequenz und ordnet solche Systeme dem Hochrisiko-Bereich zu. Für Betreiber heißt das: Die Pflichtenkette muss bis zum Forcing Event 02.12.2027 (Digital Omnibus) in eine prüfbare Form gebracht sein.

Was Annex III Nr. 2 genau erfasst

Der Wortlaut ist präziser, als viele Leser zunächst annehmen. Annex III Nr. 2 erfasst KI-Systeme, die als Sicherheitskomponenten in der Verwaltung und im Betrieb kritischer digitaler Infrastruktur, des Straßenverkehrs sowie der Versorgung mit Wasser, Gas, Wärme und Elektrizität eingesetzt werden sollen. Zwei Begriffe begrenzen den Anwendungsbereich entscheidend.

Erstens der Begriff der Sicherheitskomponente. Art. 3 Nr. 14 der Verordnung definiert sie als Komponente, deren Ausfall die Gesundheit und Sicherheit von Personen oder von Sachwerten gefährdet. Nicht jede KI, die in einem Energieunternehmen läuft, ist damit Hochrisiko. Ein Chatbot im Kundenservice oder ein Tool zur Rechnungsklassifizierung fällt nicht unter Annex III Nr. 2. Erst wenn die KI eine Funktion übernimmt, deren Versagen den sicheren Betrieb der Infrastruktur unmittelbar beeinträchtigt, greift die Einstufung.

Zweitens der Bezug auf Verwaltung und Betrieb. Es geht um Systeme, die in den laufenden Betrieb eingebunden sind — etwa Lastflusssteuerung im Stromnetz, vorausschauende Wartung sicherheitsrelevanter Anlagen oder Verkehrsleitsysteme. Die Einordnung folgt der Funktion im Betrieb, nicht der Branche an sich.

Diese Trennschärfe ist kein juristisches Detail, sondern der erste praktische Schritt jeder Vorbereitung: Betreiber müssen ihre KI-Landschaft daraufhin durchsehen, welche Systeme tatsächlich Sicherheitskomponenten sind. Genau diese Abgrenzung ist häufig die größte Unsicherheit — und sie lässt sich nur belegen, wenn Funktion und Wirkung eines Systems dokumentiert vorliegen.

Warum die Einstufung im Sektor besonders schwer wiegt

Kritische Infrastruktur ist bereits ohne den EU AI Act stark reguliert. Die CER-Richtlinie (Richtlinie (EU) 2022/2557) zur Resilienz kritischer Einrichtungen und die NIS-2-Richtlinie (Richtlinie (EU) 2022/2555) zur Cybersicherheit stellen eigene Anforderungen an Betreiber. Der EU AI Act tritt nicht an deren Stelle, sondern legt eine zusätzliche Schicht über die KI-gestützten Sicherheitsfunktionen.

Für Betreiber entsteht damit eine Überlagerung von Pflichtenregimen, die aufeinander abgestimmt sein muss. Ein Risikomanagement, das die Cybersicherheit nach NIS 2 abdeckt, aber die spezifischen KI-Risiken des AI Act nicht erfasst, bleibt unvollständig — und umgekehrt. Wer die Anforderungen getrennt behandelt, produziert doppelte Arbeit und widersprüchliche Nachweise. Wer sie zusammenführt, braucht eine gemeinsame Evidenzbasis, auf die sich beide Regime stützen.

Hinzu kommt, dass viele dieser Sicherheitskomponenten zugekauft sind. Ein Netzbetreiber entwickelt seine Steuerungs-KI selten selbst, sondern bezieht sie von einem Anbieter — möglicherweise aus den USA, dem Vereinigten Königreich oder der Schweiz. Damit verschiebt sich ein Teil der Verantwortung auf den Vendor-Layer: Der Anbieter ist Provider im Sinne der Verordnung, der Betreiber Deployer. Beide tragen unterschiedliche Pflichten, und beide müssen ihren Teil nachweisbar erfüllen. Für Betreiber heißt das, dass sie die Provider-Konformität ihrer Lieferanten nicht voraussetzen, sondern prüfen müssen.

Die Pflichtenkette für Hochrisiko-KI im Überblick

Ist ein System nach Annex III Nr. 2 als Hochrisiko eingestuft, greift die volle Pflichtenkette der Verordnung. Im Kern verlangt sie sieben Bausteine, die jeweils nicht nur umgesetzt, sondern belegt werden müssen:

• Risikomanagementsystem (Art. 9): ein kontinuierlicher Prozess zur Identifikation und Minderung von Risiken über den gesamten Lebenszyklus.
• Daten-Governance (Art. 10): relevante, repräsentative und möglichst fehlerfreie Datensätze für Training, Validierung und Test.
• Technische Dokumentation (Art. 11, Annex IV): die nachvollziehbare Beschreibung von Aufbau, Funktionsweise und Konformität.
• Protokollierung (Art. 12): automatische Aufzeichnung von Ereignissen, die spätere Rückverfolgbarkeit erst möglich macht.
• Transparenz und Betreiberinformation (Art. 13): Anweisungen, die einen sicheren und sachgerechten Einsatz erlauben.
• Menschliche Aufsicht (Art. 14): die Fähigkeit, das System zu überwachen und im Bedarfsfall einzugreifen.
• Genauigkeit, Robustheit und Cybersicherheit (Art. 15): technische Belastbarkeit auch unter Stör- und Angriffsbedingungen.

Gerade der letzte Punkt verzahnt sich im Sektor kritischer Infrastruktur eng mit den NIS-2-Anforderungen. Robustheit und Cybersicherheit sind hier keine abstrakten Qualitätsmerkmale, sondern die Bedingung dafür, dass eine Sicherheitskomponente ihren Zweck erfüllt. Ein Verkehrsleitsystem, das unter Last unzuverlässig wird, ist kein Compliance-Problem zweiter Ordnung — es ist ein Betriebsrisiko.

Vom Nachweis her gedacht

Der gemeinsame Nenner aller dieser Pflichten ist nicht die Existenz einer Maßnahme, sondern ihr Beleg. Eine Aufsichtsbehörde fragt im Ernstfall nicht, ob ein Betreiber sein Risikomanagement für ausreichend hält, sondern ob er die getroffenen Maßnahmen, ihre Begründung und ihre Wirksamkeit dokumentiert vorlegen kann — lückenlos und reproduzierbar. Trust entsteht hier nicht aus der Behauptung von Sicherheit, sondern aus nachweisbarer Evidenz. Das gilt im Sektor kritischer Infrastruktur in besonderem Maße, weil die Folgen eines Fehlers sichtbar und überprüfbar sind.

Praktisch lässt sich diese Evidenz strukturiert aufbauen. Das Maturity-Modell AIMS (ISO 42001 × CMMI v3) verbindet die Managementanforderungen der ISO/IEC 42001 mit einer Reifegradlogik, die zeigt, ob Prozesse nur definiert oder auch gelebt und gemessen werden. Für Betreiber kritischer Infrastruktur, die ohnehin etablierte Managementsysteme betreiben, ist das ein anschlussfähiger Rahmen: Die KI-Governance wird nicht als Fremdkörper aufgesetzt, sondern in die bestehende Betriebsführung integriert — mit dem Ziel, dass jede Pflicht eine prüfbare Spur hinterlässt.

Wer tiefer in die Abgrenzung und die Pflichten von Hochrisiko-Systemen einsteigen möchte, findet weiterführende Einordnungen auf hochrisiko-ki.com.

Fazit

Annex III Nr. 2 macht KI-Sicherheitskomponenten in Verkehr, Energie- und Wasserversorgung sowie kritischer digitaler Infrastruktur zu Hochrisiko-Systemen — aber nur dort, wo sie tatsächlich sicherheitskritische Funktionen übernehmen. Die Kunst der Vorbereitung liegt zuerst in der sauberen Abgrenzung und dann im konsequenten Aufbau einer Evidenzbasis, die den überlagernden Anforderungen aus AI Act, CER und NIS 2 zugleich standhält. Bis zum 02.12.2027 ist genug Zeit, das strukturiert zu tun — aber nur, wenn jetzt mit der Bestandsaufnahme begonnen wird.

Mehr dazu, wie sich Hochrisiko-KI von der Einstufung bis zum belastbaren Nachweis führen lässt, erfahren Sie über die AEGIRA Trust-Platform: aegira.ai.