KI in kritischer Infrastruktur – Wann Steuerungs-KI Hochrisiko ist

Ein einziger fehlerhafter Steuerbefehl in einem Umspannwerk kann eine halbe Million Haushalte in die Dunkelheit stürzen. Wenn diesen Befehl künftig ein KI-System auslöst oder freigibt, dann ist das keine technische Randnotiz mehr – es ist ein regulatorischer Ernstfall. Beim Thema AI Act kritische Infrastruktur unterschätzen viele Betreiber die Folgen: Der EU AI Act stuft KI, die als Sicherheitsbauteil den sicheren Betrieb Ihrer kritischen Infrastruktur gewährleisten soll, als Hochrisiko-KI ein. Manche gehen bislang davon aus, dass sie mit ein paar Transparenzhinweisen davonkommen. Das ist ein teurer Irrtum. Ausgerechnet Systeme, die Schutz- und Sicherheitsfunktionen im Netzbetrieb übernehmen, lösen ab dem 2. Dezember 2027 den vollen Pflichtenkatalog aus – und die Vorbereitung darauf braucht Zeit.

AI Act und kritische Infrastruktur: Wann KI zur Hochrisiko-KI wird

Der entscheidende Rechtstext steht in Annex III Nr. 2 des AI Act. Erfasst ist dort KI, die als Sicherheitskomponente beim Betrieb und der Verwaltung folgender Bereiche eingesetzt wird:

kritische digitale Infrastruktur
Straßenverkehr
die Versorgung mit Wasser, Gas, Wärme und Strom

Sobald Ihre KI in einem dieser Sektoren eine Sicherheitsfunktion übernimmt, landen Sie in der höchsten regulierten Kategorie unterhalb der verbotenen Praktiken. Diese Einordnung ist kein Ermessensspielraum, sondern ergibt sich unmittelbar aus dem Gesetz. Wie die Annex-III-Systematik insgesamt funktioniert, welche acht Bereiche sie umfasst und wie die Einstufung im Detail abläuft, erklären wir ausführlich im Grundlagenartikel zu Hochrisiko-KI nach Annex III.

Wichtig ist die Abgrenzung: Nicht jede KI in einem Energieversorger oder Wasserwerk ist automatisch Hochrisiko. Entscheidend ist allein, ob die KI eine Sicherheitsfunktion für den Betrieb erfüllt. Die KI, die im Marketing Ihre Kundensegmente clustert, fällt nicht darunter. Die KI, die eine Turbine zum Schutz vor Überlast drosselt oder einen Netzabschnitt trennt, um eine Gefährdung abzuwenden, schon. Seit dem Digital Omnibus (Verordnung (EU) 2026/1744, in Kraft seit 27. Juli 2026) ist diese Grenze enger gezogen – dazu gleich mehr.

Damit Sie Ihre eigene Steuerungs-KI korrekt verorten können, hilft der Blick auf das Gesamtsystem der Regulierung – auf das Zusammenspiel von Risikoklassen, Pflichten und Fristen im Überblick. Erst wenn klar ist, in welche Klasse ein System fällt, lässt sich sagen, welche der folgenden Pflichten überhaupt greifen.

Drei typische Anwendungen zeigen, wie konkret das im AI Act für kritische Infrastruktur wird:

Lastmanagement im Stromnetz: KI, die Erzeugung und Verbrauch in Echtzeit ausbalanciert und Schaltentscheidungen vorbereitet oder auslöst.
Leckerkennung in Wassernetzen: KI, die Druck- und Durchflussdaten auswertet, um Rohrbrüche zu erkennen und Absperrungen zu veranlassen.
KI-gestützte Verkehrssteuerung: Systeme, die Ampelphasen, Tunnelsperrungen oder Geschwindigkeitsvorgaben adaptiv regeln.

In allen drei Fällen kann die Sicherheit der Versorgung – oder von Menschenleben – unmittelbar am korrekten Funktionieren der KI hängen. Ist die KI dazu bestimmt, solche Gefahren abzuwenden, ist sie eine Sicherheitskomponente und damit Hochrisiko im Sinne des Gesetzes. Dient dieselbe Technik nur der Optimierung, etwa einer kostengünstigeren Lastverteilung oder flüssigeren Ampelschaltung ohne Schutzzweck, liegt die Sache anders.

KI-Sicherheitskomponente in kritischer Infrastruktur verstehen

Der Begriff der Sicherheitskomponente ist der Dreh- und Angelpunkt der gesamten Einstufung. Der AI Act definiert eine Sicherheitskomponente in Art. 3 Nr. 14 als Bestandteil eines Produkts oder KI-Systems, der eine Sicherheitsfunktion für dieses Produkt oder System erfüllt oder dessen Ausfall oder Fehlfunktion die Gesundheit und Sicherheit von Personen oder Eigentum gefährdet.

Update Juli 2026 – Digital Omnibus in Kraft: Die Definition wurde präzisiert. Eine Sicherheitsfunktion liegt nur vor, wenn die vom Anbieter festgelegte Zweckbestimmung der Komponente darin besteht, Risiken für die Gesundheit und Sicherheit von Personen oder für Eigentum abzuwenden oder zu mindern. Systeme, die ausschließlich der Nutzerunterstützung, Leistungsoptimierung, Effizienz, Automatisierung, dem Bedienkomfort oder einer nicht sicherheitsrelevanten Qualitätskontrolle dienen, sind nach den Erwägungsgründen keine Sicherheitskomponenten. Die bloße Integration in ein Leitsystem reicht nicht.

Übertragen auf kritische Infrastruktur heißt das: Ist Ihre KI dazu bestimmt, Gefahren für Personen oder Eigentum abzuwenden – etwa durch Schutzabschaltungen, Überlastschutz oder Absperrungen bei Rohrbrüchen –, oder würde ihr Ausfall solche Gefahren auslösen, ist sie eine Sicherheitskomponente und damit Hochrisiko. Optimiert sie nur Effizienz oder Kosten, in der Regel nicht.

Was ins Prüfraster gehört

Prüfen Sie insbesondere diese Systemtypen kritisch:

System	Sicherheitsrelevanz	Typische Einordnung
SCADA-/Leitsysteme mit KI-Modulen	Steuern und überwachen den Betrieb direkt	Sicherheitskomponente, wenn das KI-Modul Schutzfunktionen übernimmt; reine Optimierungsmodule nicht
Lastmanagement / Netzstabilisierung	Verhindern Über-/Unterlast und Blackouts	in der Regel Sicherheitskomponente, soweit Schutz der Zweck ist; reine Kostenoptimierung nicht
Leckerkennung / Störfallerkennung	Lösen Schutz- und Abschaltvorgänge aus	in der Regel Sicherheitskomponente
Predictive Maintenance	Hängt vom Einsatzkontext ab	regelmäßig keine Sicherheitskomponente, siehe unten
Reine Büro-/Analyse-KI	Kein Einfluss auf den sicheren Betrieb	in der Regel nicht erfasst

Der schwierigste Fall ist die Predictive-Maintenance-KI. Dient sie der wirtschaftlichen Wartungsplanung, Verfügbarkeit oder Effizienz, ist sie nach der engeren Definition regelmäßig keine Sicherheitskomponente. Löst sie dagegen Abschaltungen aus, weil ein Bauteil unmittelbar auszufallen droht, kann sie sehr wohl eine Sicherheitsfunktion erfüllen. Warum dieselbe Technologie im Fabrikkontext oft anders zu bewerten ist als in der Versorgungsinfrastruktur, beleuchten wir im Detail zu Predictive Maintenance in Industrie und Produktion.

Reine Büro- oder Analyse-KI fällt regelmäßig nicht unter Annex III Nr. 2, weil sie keine Betriebsfunktion mit unmittelbarer Sicherheitsrelevanz hat. Ein Reporting-Dashboard, das historische Verbrauchsdaten visualisiert, gefährdet bei Ausfall niemanden – es erzeugt schlimmstenfalls Unbequemlichkeiten.

Selbsteinstufung: Greift die Ausnahme nach Art. 6 Abs. 3?

Der AI Act enthält in Art. 6 Abs. 3 eine wichtige Ausnahme: Ein System, das grundsätzlich unter Annex III fällt, gilt nicht als Hochrisiko, wenn es kein signifikantes Risiko für Gesundheit, Sicherheit oder Grundrechte darstellt. Das ist etwa der Fall, wenn die KI nur eine eng begrenzte Verfahrensaufgabe erfüllt, ein zuvor abgeschlossenes menschliches Ergebnis lediglich verbessert oder rein vorbereitende Tätigkeiten übernimmt.

Warum die Ausnahme bei Infrastruktur praktisch nie greift

Hier liegt die zentrale Warnung dieses Artikels: Bei Sicherheitskomponenten kritischer Infrastruktur greift die Ausnahme praktisch nie. Der Grund ist logisch zwingend. Eine Sicherheitskomponente ist per Definition ein System, das Gefahren für Personen oder Eigentum abwenden soll oder dessen Fehlfunktion solche Gefahren auslöst. Genau das ist das Gegenteil eines „nicht signifikanten Risikos”. Wer argumentiert, seine Netzsteuerungs-KI sei ungefährlich, widerspricht damit der eigenen Einordnung als Sicherheitskomponente.

Der AI Act selbst schließt die Ausnahme zudem aus, wenn die KI ein Profiling natürlicher Personen vornimmt – in der Infrastruktursteuerung selten relevant, aber ein weiterer Riegel. Entscheidend bleibt: Sobald die Sicherheitsfunktion feststeht, ist der Weg über Art. 6 Abs. 3 versperrt. Die genauen Voraussetzungen und die typischen Fehleinschätzungen behandeln wir in unserer Analyse der Hochrisiko-Ausnahme nach Art. 6 Abs. 3.

Beachten Sie außerdem: Auch wenn Sie zu dem Ergebnis kommen, dass kein Hochrisiko vorliegt, müssen Sie diese Selbsteinstufung dokumentieren. Die Verneinung ist keine formlose Entscheidung, sondern eine begründungspflichtige Bewertung, die Sie den Behörden auf Verlangen vorlegen können müssen. Eine nicht dokumentierte „Das ist bei uns unkritisch”-Annahme ist im Zweifel wertlos.

Hochrisiko-KI in kritischer Infrastruktur: Diese Pflichten kommen auf Sie zu

Steht die Hochrisiko-Einordnung fest, greift der volle Pflichtenkatalog. Für den Anbieter eines Hochrisiko-Systems bedeutet das insbesondere:

Risikomanagementsystem: ein kontinuierlicher, über den gesamten Lebenszyklus laufender Prozess zur Identifikation und Minderung von Risiken.
Data Governance: Anforderungen an Qualität, Repräsentativität und Fehlerfreiheit der Trainings-, Validierungs- und Testdaten.
Technische Dokumentation: eine vollständige, prüffähige Beschreibung des Systems, seiner Architektur und seiner Grenzen.
Aufzeichnungspflichten (Logging): automatische Protokollierung von Ereignissen über die Lebensdauer, um Rückverfolgbarkeit sicherzustellen.
Menschliche Aufsicht: das System muss so gestaltet sein, dass Menschen es wirksam überwachen und im Notfall eingreifen können – bei einer Netzsteuerung etwa durch einen jederzeit möglichen manuellen Override.
Transparenz und Betreiberinformation: klare Gebrauchsanweisungen, die den sicheren Einsatz ermöglichen.

Cybersicherheit: der kritischste Punkt bei Infrastruktur

Besonders scharf wirken die Anforderungen an Genauigkeit, Robustheit und Cybersicherheit. Ein Hochrisiko-System muss über seinen Lebenszyklus ein angemessenes Maß an Genauigkeit erreichen, gegenüber Fehlern und Störungen robust sein und gegen Manipulationsversuche geschützt werden.

Für kritische Infrastruktur ist das keine Formalität, sondern existenziell. Ein manipuliertes Lastmanagement kann ein ganzes Netz destabilisieren. Eine kompromittierte Wassernetz-KI kann Sicherheitsfunktionen unterlaufen. Die KI muss deshalb gegen Data Poisoning, Model Poisoning, adversariale Angriffe und Ausnutzung von Modellschwächen abgesichert sein. Warum diese drei Eigenschaften rechtlich verzahnt sind und wie Sie sie nachweisen, erläutern wir zu Genauigkeit, Robustheit und Cybersicherheit nach Art. 15.

Hinzu kommen die prozeduralen Pflichten: die Durchführung der Konformitätsbewertung, das Anbringen der CE-Kennzeichnung und die Registrierung vor dem Inverkehrbringen oder der Inbetriebnahme. Für kritische Infrastruktur (Anhang III Nr. 2) gilt dabei eine Besonderheit: Registriert wird nicht in der öffentlichen EU-Datenbank, sondern auf nationaler Ebene (Art. 49 Abs. 5). In Deutschland führt die Bundesnetzagentur dafür ein nicht-öffentliches Register (§ 20 KI-MIG). Mehr zum deutschen Durchführungsgesetz lesen Sie im Beitrag zum AI-Act-Durchführungsgesetz.

Anbieter oder Betreiber? Ihre Rolle bestimmt Ihre Pflichten

Der AI Act unterscheidet strikt zwischen dem Anbieter (wer das System entwickelt oder unter eigenem Namen in Verkehr bringt) und dem Betreiber (wer das System unter eigener Verantwortung einsetzt). Die schwerste Last – Konformitätsbewertung, technische Dokumentation, Registrierung – trägt der Anbieter. Der Betreiber muss unter anderem die menschliche Aufsicht sicherstellen, die Gebrauchsanweisung einhalten, den Betrieb überwachen und Vorfälle melden.

Eigenentwicklung vs. Einkauf

Zwei Szenarien sind zu unterscheiden:

Eigenentwicklung: Entwickelt Ihr Versorgungsunternehmen die Netzsteuerungs-KI selbst, sind Sie zugleich Anbieter und Betreiber – und tragen beide Pflichtenpakete vollständig.
Einkauf externer Steuerungs-KI: Kaufen Sie ein SCADA-Leitsystem mit KI-Modul zu, ist zunächst der Hersteller Anbieter. Sie sind Betreiber – zunächst mit den geringeren Pflichten.

Die Falle der wesentlichen Änderung

Achtung: Nehmen Sie an einem eingekauften System eine wesentliche Änderung vor – etwa indem Sie das Modell mit eigenen Betriebsdaten grundlegend nachtrainieren oder den Zweck verändern – oder bringen Sie es unter Ihrem eigenen Namen in Verkehr, werden Sie selbst zum Anbieter und übernehmen dessen volle Pflichten. Das ist einer der am häufigsten übersehenen Mechanismen des AI Act.

Praktisch heißt das: Sichern Sie sich vertraglich entlang der Lieferkette ab. Vereinbaren Sie, wer Konformität, Dokumentation und Updates verantwortet, wer die Registrierung übernimmt und wie mit sicherheitsrelevanten Vorfällen umgegangen wird. Die genaue Abgrenzung der Rollen und ihrer Pflichten behandeln wir in unserem Beitrag zur Abgrenzung von Anbieter- und Betreiberpflichten.

Fristen: Was bis wann erledigt sein muss

Der AI Act gilt seit dem 1. August 2024, entfaltet seine Pflichten aber gestaffelt. Für Hochrisiko-Systeme nach Annex III – und damit für Ihre Infrastruktur-Steuerungs-KI – sind die Pflichten ab dem 2. Dezember 2027 anwendbar. Der Digital Omnibus hat diesen Termin als festes Datum gesetzt; der ursprünglich vorgesehene 2. August 2026 gilt für Hochrisiko-KI nicht mehr. Seit dem 2. August 2026 durchsetzbar sind dagegen bereits die Verbote (Art. 5), die Transparenzpflichten (Art. 50), die KI-Kompetenz (Art. 4) und die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck. Die Details finden Sie in unserer Übersicht zu den Fristen für Hochrisiko-KI.

Der Dezember 2027 ist kein Grund zum Abwarten: Risikomanagement, technische Dokumentation und Qualitätsmanagement brauchen erfahrungsgemäß zwölf bis achtzehn Monate Vorlauf. Wer jetzt beginnt, liegt im realistischen Zeitfenster.

Bestandssysteme und Übergangsregelungen

Für Bestandssysteme gilt nach Art. 111 Abs. 2 eine Übergangsregel: Hochrisiko-Systeme, die vor dem 2. Dezember 2027 in Verkehr gebracht oder in Betrieb genommen wurden, fallen nur dann unter den AI Act, wenn sie ab diesem Datum wesentlich geändert werden. Ausnahme: Hochrisiko-Systeme, die von Behörden genutzt werden sollen, müssen bis zum 2. August 2030 konform sein. Wer sein Leitsystem also grundlegend modernisiert, holt es damit in der Regel in den vollen Pflichtenkatalog.

Praktischer Fahrplan zur Konformität

Ein realistischer Weg zur Konformität umfasst:

Inventarisierung: Erfassen Sie alle KI-Komponenten in Ihren Steuerungs-, Überwachungs- und Wartungssystemen.
Klassifizierung: Prüfen Sie für jedes System die Sicherheitskomponenten-Eigenschaft und die Annex-III-Zugehörigkeit – und dokumentieren Sie das Ergebnis, auch bei Verneinung.
Rollenklärung: Bestimmen Sie je System, ob Sie Anbieter, Betreiber oder beides sind.
Gap-Analyse: Gleichen Sie den Ist-Zustand mit dem Pflichtenkatalog ab, mit besonderem Fokus auf Cybersicherheit und menschliche Aufsicht.
Umsetzung und Nachweis: Richten Sie Risikomanagement, Logging und Dokumentation ein, führen Sie die Konformitätsbewertung durch und registrieren Sie das System.
Lieferkette absichern: Schließen Sie die vertraglichen Lücken zu Ihren KI-Zulieferern.

Fazit

KI in kritischer Infrastruktur ist kein Grenzfall der Regulierung, sondern ihr Kernanwendungsbereich. Annex III Nr. 2 erfasst KI als Sicherheitskomponente in den Sektoren Straßenverkehr, digitale Infrastruktur sowie Versorgung mit Wasser, Gas, Wärme und Strom – und zwar genau die Systeme, deren Zweck der Schutz von Personen oder Eigentum im laufenden Betrieb ist. Der entscheidende Begriff ist damit die Sicherheitsfunktion: Soll die KI Gefahren abwenden oder würde ihr Ausfall Personen oder Eigentum gefährden, ist sie Hochrisiko. Seit dem Digital Omnibus gilt dabei eine engere Definition: Reine Effizienz-, Optimierungs- oder Automatisierungs-KI ist keine Sicherheitskomponente. Die Ausnahme nach Art. 6 Abs. 3 hilft bei echten Sicherheitskomponenten nicht weiter, weil ein signifikantes Risiko dort definitionsgemäß vorliegt – und selbst die Verneinung des Hochrisikos müssen Sie dokumentieren.

Daraus folgt der volle Pflichtenkatalog von Risikomanagement über Data Governance, technische Dokumentation, Logging und menschliche Aufsicht bis zur besonders kritischen Trias aus Genauigkeit, Robustheit und Cybersicherheit, ergänzt um Konformitätsbewertung und Registrierung. Ob diese Lasten Sie als Anbieter oder Betreiber treffen, hängt von Eigenentwicklung, Einkauf und vor allem von der Frage der wesentlichen Änderung ab. Die Pflichten aus Annex III gelten ab dem 2. Dezember 2027. Bei zwölf bis achtzehn Monaten Vorlauf für Risikomanagement, Dokumentation und Qualitätsmanagement ist jetzt der richtige Zeitpunkt, von der Bestandsaufnahme zur belastbaren, dokumentierten Umsetzung entlang jedes einzelnen Steuerungssystems überzugehen.