Der blinde Fleck bei KI in NIS2-Compliance-Programmen

Als die NIS2-Richtlinie (EU) 2022/2555 am 16. Januar 2023 in Kraft trat und bis zum 17. Oktober 2024 umzusetzen war (Deutschland hat sie mit dem neuen BSI-Gesetz umgesetzt, das seit dem 6. Dezember 2025 gilt), konzentrierten die meisten DACH-Unternehmen ihre Compliance-Bemühungen auf traditionelle Netzwerk-Perimetersicherheit, Endpoint-Schutz und Meldeworkflows für Vorfälle. Doch eine kritische Dimension wird systematisch übersehen: die Cybersicherheits- und Resilienz-Anforderungen, die NIS2 an alle Netz- und Informationssysteme wesentlicher und wichtiger Einrichtungen stellt, KI-Systeme eingeschlossen.

Die breite Definition von Netz- und Informationssystemen in NIS2 bedeutet, dass KI-Systeme, die zur Dienstleistungserbringung in regulierten Sektoren, Energie, Verkehr, Banken, Gesundheit, digitale Infrastruktur und öffentliche Verwaltung, eingesetzt werden, in den Anwendungsbereich der Richtlinie fallen, auch wenn spezifische KI-Leitlinien von ENISA und nationalen Behörden noch im Entstehen begriffen sind. Für die Einrichtungen, die nun unter dem erweiterten Anwendungsbereich von NIS2 als wesentlich oder wichtig eingestuft werden, bedeutet dies, dass Machine-Learning-Modelle, automatisierte Entscheidungssysteme und KI-abhängige Prozesse dieselben strengen Cybersicherheits-Risikomanagement-, Lieferketten-Überwachungs- und Incident-Response-Fähigkeiten erfordern wie jede andere kritische Systemkomponente.

Viele Unternehmen in kritischen Sektoren haben KI-Systeme eingesetzt, ohne diese explizit in NIS2-Compliance-Frameworks zu integrieren. Diese Lücke schafft erhebliche regulatorische Risiken, insbesondere da nationale Aufsichtsbehörden mit Durchsetzungsmaßnahmen beginnen und die Mitgliedstaaten für wesentliche Einrichtungen Bußgelder mit einem Höchstbetrag von mindestens 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes vorsehen müssen; in Deutschland bis zu 10 Millionen Euro, bei mehr als 500 Millionen Euro Umsatz bis zu 2 Prozent (§ 65 BSIG).

Lieferkettenrisikomanagement erstreckt sich auf Modellherkunft

KI-Modelle von Drittanbietern als kritische Lieferanten stellen möglicherweise die unmittelbarste Compliance-Herausforderung gemäß NIS2 Artikel 21 Abs. 2 Buchst. d dar, der die Sicherheit der Lieferkette einschließlich der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern verlangt. Wenn Unternehmen Foundation-Modelle von Anbietern wie OpenAI, Anthropic oder Cohere einsetzen oder vortrainierte Modelle aus Repositories wie Hugging Face verwenden, führen sie Drittanbieter-Abhängigkeiten ein, die gemäß den Lieferkettenrisiko-Anforderungen von NIS2 bewertet und überwacht werden müssen.

Die Richtlinie verlangt ausdrücklich, dass Einrichtungen alle Lieferanten sicherheitsrelevanter Dienste und Produkte identifizieren und dokumentieren, deren Cybersicherheitspraktiken bewerten und vertragliche Vereinbarungen umsetzen, die angemessene Sicherheitsniveaus in der gesamten Lieferkette gewährleisten. Für KI-Systeme bedeutet dies spezifische Verpflichtungen zur Nachverfolgung der Modellherkunft, die Fähigkeit, Ursprung, Trainingsdatenquellen, Fine-Tuning-Historie und Update-Abstammung jedes in Produktionsumgebungen eingesetzten Modells zu dokumentieren.

Energieunternehmen berichten, dass die Etablierung der Modellherkunft für ihre KI-Systeme zur vorausschauenden Wartung die Implementierung eines Modellregisters mit kryptografischer Signierung, Versionskontrollintegration und automatisiertem Dependency-Scanning erforderte. Unternehmen stellen fest, dass ein erheblicher Anteil ihrer eingesetzten Modelle auf Open-Source-Komponenten mit unklarer Trainingsdaten-Abstammung basiert, was ein umfassendes Audit und in mehreren Fällen einen Modellaustausch erforderlich macht, um die Lieferkettentransparenz-Anforderungen von NIS2 zu erfüllen.

Vertragliche Sicherheitsanforderungen für KI-Dienstleister müssen spezifische technische und organisatorische Maßnahmen adressieren. NIS2-konforme Verträge benötigen Bestimmungen zu Modellsicherheitstests, Verfahren zur Offenlegung von Schwachstellen, Zeitplänen für Vorfallsmeldungen (die Richtlinie verlangt eine Frühwarnung binnen 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls, eine Meldung binnen 72 Stunden und einen Abschlussbericht binnen eines Monats) und dem Recht zur Prüfung von Sicherheitskontrollen. Um die Lieferkettenmaßnahme nach Art. 21 Abs. 2 Buchst. d zu erfüllen, können Verträge mit KI-Anbietern Verpflichtungen zu Datenresidenz, Modellisolierung zwischen Kunden und der Möglichkeit zum Abruf oder zur Löschung von Trainingsdaten auf Anfrage enthalten.

KI-Systemausfälle als meldepflichtige Sicherheitsvorfälle

Vorfallserkennungs- und Meldepflichten gemäß NIS2 Artikel 23 schaffen neue Überwachungsanforderungen für KI-Systeme. Die Richtlinie definiert Vorfälle breit als Ereignisse, die die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter, übertragener oder verarbeiteter Daten oder damit verbundener Dienste beeinträchtigen. Für KI-Systeme umfasst diese Definition nicht nur traditionelle Cybersicherheitsereignisse wie unbefugten Zugriff oder Datenexfiltration, sondern auch KI-spezifische Ausfallmodi einschließlich Modelldegradation, Adversarial Attacks, Data Poisoning und unerwartete Verhaltensänderungen, die die Dienstleistungserbringung beeinträchtigen.

Eine KI-Störung ist meldepflichtig, wenn sie ein erheblicher Sicherheitsvorfall ist, also schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht oder verursachen kann oder andere erheblich schädigt (Art. 23 Abs. 3).

Überwachung von KI-Systemen als Sicherheitstelemetrie erfordert Fähigkeiten, die über traditionelles Application Performance Monitoring hinausgehen. NIS2-Compliance erfordert die Erkennung anomalen KI-Verhaltens, das auf eine Sicherheitskompromittierung oder Systemdegradation hinweisen könnte. Führende Finanzinstitute haben kontinuierliche Modellüberwachung für ihre KI-Systeme implementiert und verfolgen Prediction Drift, Confidence-Score-Verteilungen, Feature-Importance-Verschiebungen und Inference-Latenz als sicherheitsrelevante Metriken. Ihre Security Operations Center korrelieren nun KI-Systemtelemetrie mit Netzwerksicherheitsereignissen und behandeln unerwartete Modellverhaltensänderungen als potenzielle Kompromittierungsindikatoren, die eine Untersuchung erfordern.

Die technische Herausforderung liegt darin, legitime Modellanpassung von böswilliger Manipulation oder Degradation zu unterscheiden, die eine Vorfallsmeldung erfordert. Forschungsinstitutionen wie DLR und Fraunhofer erforschen Ansätze, die Basis-Verhaltenskorridore für KI-Systeme etablieren und Sicherheitsüberprüfungen auslösen, wenn Systeme außerhalb definierter Parameter operieren. Dieser Ansatz ermöglicht die Identifikation echter Sicherheitsvorfälle, darunter Fälle von Trainingsdatenmanipulation und Adversarial-Input-Versuche.

Resilienz-Anforderungen erfordern Degradationspfade

Business-Continuity- und Disaster-Recovery-Verpflichtungen gemäß NIS2 Artikel 21 verlangen von Einrichtungen, die Kontinuität kritischer Funktionen während und nach Vorfällen sicherzustellen. Für KI-abhängige Prozesse schafft dies architektonische Anforderungen, die viele aktuelle Implementierungen nicht erfüllen. Die Betonung der Resilienz durch die Richtlinie bedeutet, dass kritische Dienste nicht einfach ausfallen dürfen, wenn KI-Systeme nicht verfügbar werden, Unternehmen müssen Degradationspfade entwerfen und testen, die wesentliche Funktionalität durch alternative Mittel aufrechterhalten.

Ein Logistikbetreiber könnte sein KI-gestütztes Routenoptimierungssystem neu konzipieren, um NIS2-Resilienz-Anforderungen zu erfüllen, und eine dreistufige Degradationsarchitektur einführen. Im Normalbetrieb liefern Deep-Learning-Modelle optimale Routenführung unter Berücksichtigung von Echtzeit-Verkehr, Wetter und Nachfragemustern. Wenn die Verfügbarkeit des KI-Systems unter definierte Schwellenwerte fällt, wechselt das System automatisch zu einfacheren heuristischen Algorithmen, die akzeptable Routenführung mit gecachten Daten bieten. Wenn sowohl KI- als auch heuristische Systeme ausfallen, werden manuelle Routenprotokolle mit vorberechneten Backup-Routen aktiviert. Ein Test dieser Architektur im Rahmen der NIS2-Arbeit würde zeigen, ob der Betrieb bei vollständigem KI-Systemausfall mit reduzierter, aber akzeptabler Effizienz weiterläuft.

Backup- und Wiederherstellungsfähigkeiten für KI-Systeme stellen technische Herausforderungen dar, die sich von traditionellen Datenbackups unterscheiden. Modelle selbst erfordern versionierte Backups, aber effektive Wiederherstellung erfordert die Bewahrung des gesamten operativen Kontexts einschließlich Trainingsdaten-Snapshots, Hyperparameter-Konfigurationen, Feature-Engineering-Pipelines und Kalibrierungsdaten. Betreiber kritischer Infrastrukturen sollten KI-Systeme innerhalb der Recovery Time Objectives, die ihre Business-Impact-Analysen festlegen, in bekanntermaßen gute Zustände wiederherstellen können.

KI-Systeme für NIS2-Compliance architektonisch gestalten

Model-Governance-Frameworks müssen die Risikomanagement-Anforderungen von NIS2 durch formelle Prozesse für KI-System-Genehmigung, -Deployment, -Überwachung und -Stilllegung adressieren. Die Richtlinie schreibt vor, dass Einrichtungen Richtlinien und Verfahren für Risikoanalyse und Informationssystemsicherheit implementieren, die für KI-Systeme einzigartige Risiken wie Adversarial Attacks, Model Inversion, Membership Inference und Training-Data-Extraction umfassen müssen.

Ein Versicherer könnte eine Modellrisiko-Komitee-Struktur einführen, die alle KI-Systeme vor dem Produktionseinsatz gegen NIS2-Anforderungen evaluiert. Das Bewertungsframework untersucht Lieferkettenherkunft, Sicherheitstestergebnisse, Überwachungsfähigkeiten, Degradationspfade, Incident-Response-Verfahren und Business-Continuity-Integration. Systeme, die definierte Kriterien nicht erfüllen, können nicht in Produktion gehen, und eingesetzte Systeme durchlaufen vierteljährliche Compliance-Reviews. Diese Governance-Struktur verhinderte das Deployment mehrerer KI-Systeme, die keine angemessenen Sicherheitskontrollen aufwiesen, und identifizierte Compliance-Lücken in bestehenden Systemen, die Abhilfemaßnahmen erforderten.

Sicherheitstests speziell für KI-Systeme müssen gemäß der NIS2-Anforderung, die Wirksamkeit der Risikomanagementmaßnahmen zu bewerten (Art. 21 Abs. 2 Buchst. f), zur Standardpraxis werden. Traditionelle Penetrationstests und Schwachstellenscans bieten unzureichende Abdeckung für KI-spezifische Angriffsvektoren. Forschungsinstitutionen wie DLR und Fraunhofer arbeiten an KI-Sicherheitstestprotokollen, die Adversarial-Robustness-Tests, Model-Extraction-Versuche, Training-Data-Reconstruction-Attacks und Backdoor-Erkennung umfassen.

Ihre NIS2-KI-Compliance-Bereitschaftsdiagnose

Die Schnittstelle zwischen NIS2-Anforderungen und KI-Systemarchitektur erfordert sofortige Aufmerksamkeit von DACH-Unternehmen in regulierten Sektoren. Compliance-Verpflichtungen rund um Lieferkettenrisikomanagement, Vorfallserkennung und -meldung sowie Resilienz-Anforderungen verändern grundlegend, wie KI-Systeme entworfen, eingesetzt und betrieben werden müssen. Unternehmen, die KI-Systeme als von NIS2-Cybersicherheitsframework ausgenommen behandeln, riskieren sowohl regulatorische Strafen als auch operative Risiken, da Aufsichtsbehörden ihre Durchsetzungsaktivitäten verstärken.

Die NIS2 AI Compliance Diagnostic von Remote Native bietet eine strukturierte Bewertung Ihrer KI-Systeme gegen Richtlinienanforderungen und identifiziert Lücken bei Modellherkunftsverfolgung, Sicherheitsüberwachung, Incident-Response-Integration und Resilienz-Architektur. Unsere Praktiker arbeiten mit Ihren Sicherheits-, Compliance- und KI-Teams zusammen, um Ihre aktuelle KI-Landschaft auf NIS2-Verpflichtungen abzubilden, Abhilfemaßnahmen zu priorisieren und Implementierungs-Roadmaps zu entwickeln, die regulatorische Anforderungen adressieren und gleichzeitig KI-Systemleistung und Geschäftswert aufrechterhalten.

Starten Sie Ihre NIS2-KI-Compliance-Diagnose →

Artikel basierend auf NIS2-Richtlinie (EU) 2022/2555, ENISA-NIS2-Implementierungsleitlinien, BSI-KI-Sicherheitsframeworks und dokumentierten Compliance-Implementierungen bei DACH-Betreibern kritischer Infrastrukturen.

Rechtsstand: 13. Oktober 2026. Keine Rechtsberatung.