KI in kritischer Infrastruktur: AI Act, NIS 2 und Betriebssicherheit verzahnen

Kritisches Unternehmen ist nicht gleich Hochrisikosystem

Anhang III Nummer 2 knüpft an den konkreten Verwendungszweck des KI-Systems an. Erfasst werden Sicherheitskomponenten beim Management oder Betrieb kritischer digitaler Infrastruktur, im Straßenverkehr sowie bei der Versorgung mit Wasser, Gas, Wärme oder Strom, wenn Ausfall oder Fehlfunktion Leben oder Gesundheit gefährden kann. Dass ein Unternehmen einem regulierten Sektor angehört oder wesentliche Dienste erbringt, macht daher nicht jedes Prognose-, Analyse- oder Verwaltungssystem zu einem Hochrisikosystem.

Für die Einordnung müssen Betreiber Systemgrenze, Zweckbestimmung und Fehlerfolgen festlegen. Relevante Fragen sind, ob das Ergebnis direkt auf Steuerung oder Schutzfunktionen wirkt, ob unabhängige Sicherheitsbarrieren bestehen und wie schnell Menschen wirksam eingreifen können. Ein Dashboard kann bloß informieren oder faktisch die einzige Entscheidungsgrundlage für eine sicherheitskritische Handlung liefern. Marketingbegriffe wie Optimierung oder Co-Pilot ersetzen deshalb keine technische und rechtliche Funktionsanalyse.

• Systemgrenze und Einfluss auf OT-Prozesse festlegen.
• Ausfallfolgen für Leben und Gesundheit analysieren.
• Unabhängige Schutzebenen und Eingriffszeiten nachweisen.

Quellen: [1] [2] [6]

Optimierung und Wartung fallbezogen abgrenzen

Lastprognosen, Wartungsplanung, Energieoptimierung, Ticketklassifikation oder Backoffice-Automatisierung können außerhalb des Tatbestands liegen, wenn sie keine Sicherheitskomponente darstellen und ihr Ausfall nicht die genannte Gefährdung auslöst. Diese Aussage ist keine pauschale Ausnahme. Eine Wartungsprognose kann sicherheitsrelevant werden, wenn sie Prüfintervalle für kritische Anlagen verbindlich steuert; eine Lastprognose kann eine Schutzfunktion erhalten, wenn ohne sie gefährliche Betriebszustände nicht rechtzeitig verhindert werden.

Die Bewertung sollte auf Betriebsmodi eingehen: Normalbetrieb, Degradation, Kommunikationsverlust, Notbetrieb und Wiederanlauf. Dokumentiert werden sollten Fail-safe-Verhalten, manuelle Rückfallebene, Alarmgrenzen, Datenqualität, Abhängigkeiten von Cloud- oder Telekommunikationsdiensten und die Folgen fehlerhafter Empfehlungen. Dabei ist auch die tatsächliche Nutzung zu beobachten. Ein zunächst unterstützendes Tool kann durch Prozessänderungen oder Personalmangel zu einer faktisch sicherheitsbestimmenden Komponente werden und eine erneute Klassifikation auslösen.

• Normal- und Notbetrieb getrennt bewerten.
• Faktische Abhängigkeit im laufenden Betrieb überwachen.
• Zweck- und Prozessänderungen als Neuklassifikation behandeln.

Quellen: [1] [5]

Rollen entlang der OT-Lieferkette bestimmen

Der Infrastrukturbetreiber ist beim Einsatz eines fremden Systems regelmäßig Betreiber nach dem AI Act. Wer ein System entwickelt und unter eigenem Namen bereitstellt, kann Anbieter sein. Integratoren, Importeure, Händler und Produkthersteller haben eigene mögliche Rollen. Eigenentwicklung, Rebranding, Zweckänderung oder wesentliche Änderung können die Zuordnung verschieben. Verträge können Aufgaben und Informationsflüsse organisieren, aber eine gesetzliche Rolle nicht beliebig durch eine andere Bezeichnung ersetzen.

In komplexen OT-Projekten sollte eine Verantwortungsmatrix die gesamte Lieferkette abbilden: Modellanbieter, Systemanbieter, Leittechnikhersteller, Integrator, Betreiber und Wartungsunternehmen. Benötigt werden klare Pflichten zu Versionsinformationen, Schwachstellen, Trainings- und Testdaten, Sicherheitsupdates, Subunternehmern, Vorfällen und Änderungen. Ohne vertragliche Zugriffs- und Exit-Rechte kann der Betreiber seine eigene Kontrolle nicht zuverlässig ausüben. Gleichzeitig ersetzt ein Auditrecht keine interne Kompetenz zur Bewertung der gelieferten Nachweise.

• Rollen pro Komponente und Lebenszyklusphase mappen.
• Änderungs- und Sicherheitsinformationen vertraglich absichern.
• Cloud-, Modell- und Integrationsanbieter gemeinsam betrachten.

Quellen: [1] [3]

AI Act und NISG 2026 haben verschiedene Trigger

Der AI Act klassifiziert hier einen bestimmten sicherheitsbezogenen KI-Anwendungsfall. Das zur Umsetzung der NIS-2-Richtlinie kundgemachte NISG 2026 knüpft demgegenüber insbesondere an erfasste wesentliche oder wichtige Einrichtungen, Größen- und Sektorkriterien an. Ein Unternehmen kann in den Anwendungsbereich des NISG 2026 fallen, obwohl seine eingesetzte KI nicht hochriskant ist. Umgekehrt beantwortet eine Hochrisikoeinstufung nicht, ob die Organisation nach §§ 24 bis 26 NISG 2026 erfasst ist.

Gemeinsame Kontrollen sind dennoch sinnvoll. Asset- und KI-Inventar, Lieferkettenprüfung, Identitäts- und Zugriffsmanagement, Protokollierung, Schwachstellenmanagement, Incident Response, Business Continuity und Übungen können gemeinsame Evidenz liefern. Die rechtliche Zuordnung muss getrennt bleiben: Ein schwerwiegender Vorfall nach dem AI Act ist nicht automatisch ein erheblicher Sicherheitsvorfall nach dem NISG 2026 oder ein Ereignis nach sektoralem Recht. Für erfasste Einrichtungen gelten ab 1. Oktober 2026 insbesondere Leitungsorganpflichten nach § 31, Risikomanagementmaßnahmen nach § 32 sowie der gestufte Meldeprozess nach §§ 34 und 35.

• Gemeinsame Kontrollen mit getrennten Rechtsnachweisen führen.
• Vorfallbegriffe und Meldefristen nicht gleichsetzen.
• Anwendungsbereich und Pflichten des NISG 2026 gesondert prüfen.

Quellen: [1] [3] [5] [4]

Betriebssicherheit in den KI Lebenszyklus integrieren

Für Hochrisikosysteme werden unter anderem Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierung, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit zentral. Infrastrukturbetreiber sollten diese Themen an bestehende OT-Safety- und Security-Prozesse anbinden. Konkret gehören Modellgrenzen, sichere Zustände, Alarmierung, Override, Berechtigungen, Tests gegen Datenverschiebung, Wiederherstellungsverfahren und kontrollierte Updates in ein abgestimmtes Assurance-Konzept. Die Fachdisziplinen behalten dabei ihre eigenen Methoden und Verantwortlichkeiten.

Besondere Aufmerksamkeit verdient das Änderungsmanagement. Neue Sensoren, veränderte Lastprofile, Modellupdates, geänderte Schwellenwerte oder eine Migration in die Cloud können Leistung und Risikoprofil verändern. Für jede Änderung sollte vorab geklärt werden, ob Validierung, erneute Klassifikation, Lieferantenfreigabe oder regulatorische Meldung erforderlich ist. Laufende Leistungskennzahlen müssen sicherheitsrelevante Fehler sichtbar machen, ohne sich auf einen einzigen Genauigkeitswert zu reduzieren. Tests unter seltenen, aber kritischen Betriebsbedingungen sind oft aussagekräftiger als Durchschnittswerte.

• Safety, Security und Modellrisiko in einem Change-Prozess verbinden.
• Seltene kritische Szenarien gezielt testen.
• Abschaltung, Degradation und Wiederanlauf praktisch üben.

Quellen: [1] [3] [5]

Bis Dezember 2027 belastbare Nachweise schaffen

Rechtsstand 16. September 2026: Die spezifischen Anforderungen aus Kapitel III Abschnitte 1 bis 3 für gelistete Fälle kritischer Infrastruktur nach Artikel 6 Absatz 2 und Anhang III gelten ab 2. Dezember 2027. Für Produktfälle nach Artikel 6 Absatz 1 und Anhang I gilt grundsätzlich der 2. August 2028. Die beiden Fristen dürfen nicht vermischt werden. Bereits geltende Verbote, Artikel 4, Datenschutz-, Produkt-, Sicherheits- und Cybersicherheitsrecht bleiben unberührt.

Das Vorbereitungsprogramm sollte Inventar, Kritikalitätsmapping, Rollenmatrix, Gap-Analyse, Lieferantennachweise, Human Override, Notbetrieb und Vorfalltriage umfassen. Für das NISG 2026 ist der gestufte Geltungsbeginn zu beachten: § 51 gilt seit 24. Dezember 2025, die §§ 1 bis 50 und die Anlagen ab 1. Oktober 2026. Zuständige Stelle, Meldeweg und sektorspezifische Vorgaben sind vor einer konkreten Meldung aktuell zu prüfen. Finale Hochrisikoleitlinien können die Bewertung nach dem AI Act verändern.

• Anhang III bis 2. Dezember 2027 vorbereiten.
• Anhang-I-Produktfälle separat bis 2. August 2028 planen.
• NISG-2026-Anwendungsbereich, Meldeweg und Leitlinien aktuell verifizieren.

Quellen: [1] [2] [6] [3] [4]

Häufige Fragen