NIS2 und Hochrisiko-KI: Pflichten, Umsetzung und Handlungsempfehlungen

Dies ist Teil 2 unserer Serie zu NIS2 und Hochrisiko-KI. Teil 1 erklärt, wer betroffen ist und warum. Hier geht es um konkrete Pflichten, Umsetzungsstrategien und priorisierte Schritte für die Praxis.

Pflichten und Anforderungen der NIS2-Richtlinie für Unternehmen mit Hochrisiko-KI

NIS2 verschiebt den Fokus weg von abstrakten Sicherheitsversprechen hin zu konkret nachweisbaren Maßnahmen. Für Betreiber von Hochrisiko-KI bedeutet das: Policies sind der Anfang, belastbare Evidenz zu Ihrer Infrastruktur, Ihrem Vorfallsmanagement und Ihrem Risikoprozess ist das Ziel.

Sicherheitsanforderungen: Technische und organisatorische Maßnahmen

NIS2 verlangt ein strukturiertes Sicherheitsniveau über die gesamte Wertschöpfungskette. Die folgende Tabelle zeigt die Pflichtfelder und ihre besondere Bedeutung für Hochrisiko-KI:

Für Hochrisiko-KI reicht eine textliche Beschreibung dieser Maßnahmen nicht aus. Prüfende Stellen erwarten maschinenlesbare, reproduzierbare Evidenz über den Infrastrukturzustand zum Zeitpunkt der Prüfung. Genau hier liefert ein technischer Infrastruktur-Nachweis wie von CERTavia einen klar abgegrenzten Baustein für Ihr NIS2-Dossier.

Vorfallsmanagement und Meldepflichten

NIS2 verschärft die Anforderungen an den Umgang mit Sicherheitsvorfällen. Relevant sind insbesondere:

• Ein formalisierter Incident-Response-Prozess mit definierten Rollen, Eskalationswegen und Entscheidungskriterien
• Fristen und Schwellenwerte für Meldungen an zuständige Behörden, abgestimmt mit branchenspezifischer Regulierung
• Die Fähigkeit, technisch zu belegen, was zum Zeitpunkt des Vorfalls in Ihrer Infrastruktur konfiguriert war

Gerade bei KI-Vorfällen, etwa Fehlfunktionen durch manipulierte Trainingsdaten oder kompromittierte Modelle, müssen Sie nachvollziehbar darstellen, ob die zugrunde liegende Infrastruktur die geforderten Kontrollen eingehalten hat. Ein sauberer Infrastruktur-Nachweis verhindert das sonst unvermeidliche Interpretationsproblem im Audit.

Risikobewertung und Governance für Hochrisiko-KI

NIS2 verlangt einen systematischen Risikomanagement-Prozess. Für Hochrisiko-KI sollte dieser mindestens folgende Elemente enthalten:

1. Risikoinventar für KI-spezifische Bedrohungen, etwa Modellmanipulation, Datenvergiftung oder Fehlkonfiguration von Cloud- und API-Schnittstellen
2. Bewertungsmethode mit klar definierten Bewertungskriterien und einem dokumentierten Entscheidungspfad
3. Verknüpfung mit technischen Kontrollen, das heißt eindeutige Zuordnung, welche Infrastruktur-Maßnahmen welches Risiko adressieren
4. Regelmäßige Re-Validierung der Risiken und der dazugehörigen Kontrollen, insbesondere nach größeren Änderungen an KI-Modellen oder Infrastruktur

Für Compliance-Teams ist entscheidend, dass sich dieser Prozess in ein prüffähiges Dossier übersetzen lässt. Das gelingt nur, wenn neben Prozessdokumenten eine strukturierte, kryptografisch verifizierbare Infrastruktur-Evidenz vorliegt. Wie sich diese Evidenz als fester Bestandteil von AI-Act- und NIS2-Dokumentation nutzen lässt, beschreibt das Mapping unter CERTavia im AI-Act-Audit-Dossier.

Ohne technischen Nachweis bleibt NIS2-Compliance eine Behauptung auf Papier. Mit reproduzierbarer Evidenz wird sie zu einem belastbaren Argument gegenüber Aufsicht, Auditoren und dem eigenen Vorstand.

Umsetzungsstrategien und Compliance-Maßnahmen in Deutschland

NIS2-Compliance entsteht in Ihren bestehenden Sicherheits- und Governance-Strukturen, nicht im Paralleluniversum. Der Engpass liegt fast immer bei fehlender, prüffähiger Evidenz.

Schritt 1: NIS2-Scope und Verantwortlichkeiten klären

Startpunkt ist eine klare Zuordnung, welche Dienste und Infrastrukturen unter NIS2 fallen:

1. Identifikation der NIS2-relevanten Services, zum Beispiel Zahlungsplattform, Patientenportal, HR-Plattform oder SaaS-Kernprodukt
2. Mapping dieser Services auf konkrete Systeme, Domains, Cloud-Konten und Netzsegmente
3. Festlegung eines verbindlichen Owner-Modells zwischen Fachbereich, IT, Informationssicherheit und Compliance

In Deutschland kommt eine besondere Dimension dazu: Je nach Sektor haben Sie es mit unterschiedlichen Aufsichtsbehörden zu tun, die NIS2-Vorgaben zusammen mit bestehenden Fachgesetzen auslegen. Das macht ein sauberes Scope-Dokument umso wichtiger.

Schritt 2: NIS2-Anforderungen in bestehende Frameworks integrieren

Die meisten regulierten Unternehmen arbeiten bereits mit etablierten Standards wie ISMS oder branchenspezifischen Sicherheitskatalogen. Statt ein zusätzliches NIS2-Framework zu bauen, sollten Sie:

• eine Mapping-Tabelle aufsetzen, die NIS2-Anforderungen bestehenden Kontrollen zuordnet
• Lücken identifizieren, bei denen eine Policy existiert, der technische Nachweis jedoch fehlt
• Kontrollen priorisieren, die Hochrisiko-KI und geschäftskritische Services gleichzeitig betreffen

Genau an dieser Stelle wird ein deterministischer Infrastruktur-Nachweis wirksam, zum Beispiel mit dem Sovereign Validation Protocol, der klar zeigt, ob Ihre Live-Infrastruktur definierte Anforderungen zum Zeitpunkt des Scans erfüllt.

Schritt 3: Deutscher Fokus auf Nachweisführung und Dokumentation

In Deutschland werden Sie gefragt: Zeigen Sie mir, wo das dokumentiert ist. Für NIS2 heißt das konkret:

• Auditfähige Protokolle zu Änderungen an kritischen Systemen und KI-relevanten Komponenten
• Standardisierte Reports, die sich direkt in NIS2-, AI-Act- und branchenspezifische Dossiers einfügen
• Lieferanten-Nachweise für IKT-Drittdienstleister, die in Ihre NIS2-kritische Kette eingebunden sind

Wer hier früh eine Vorlage für Prüfberichte, Infrastruktur-Nachweise und Risikoentscheidungen definiert, reduziert den Aufwand pro Audit erheblich.

Schritt 4: Operative Verankerung im Tagesgeschäft

NIS2 muss im Betrieb ankommen. Praktisch bedeutet das:

1. Integration von NIS2-Kontrollen in Change- und Release-Prozesse für KI-Systeme
2. Regelmäßige, deterministische Infrastruktur-Validierungen für produktive Domains und Services
3. Verankerung von Meldewegen und Dokumentationspflichten im Incident-Management

Je mehr Sie diese Schritte automatisieren und mit maschinenlesbarer Evidenz unterlegen, desto weniger Zeit verlieren Sie im Audit mit manueller Datensuche. Genau an diesem Punkt ergänzt CERTavia Ihren bestehenden Governance-Prozess mit kryptografisch verifizierbarer Infrastruktur-Evidenz präzise. Für IT-Leiter und CTOs gibt es den technischen Einstieg über das Validierungsverfahren.

Technologische und organisatorische Herausforderungen

Datensicherheit und Infrastrukturkomplexität

Hochrisiko-KI-Systeme arbeiten meist auf stark verteilten Architekturen. Typische Herausforderungen:

• Unklare Datenflüsse zwischen Trainings-, Test- und Produktivumgebung, oft ohne saubere Trennung von Rollen und Rechten
• Fragmentiertes Logging, das im Vorfall Daten produziert, jedoch keine konsistente Geschichte des Infrastrukturzustands erzählt
• Abhängigkeit von IKT-Drittdienstleistern, deren Sicherheitsniveau Sie nach NIS2 mitverantworten

Zur Entschärfung braucht es ein technisches Inventar aller NIS2-relevanten Assets und eine standardisierte Validierung, ob definierte Sicherheitsanforderungen zum Zeitpunkt der Prüfung wirklich erfüllt sind.

Transparenz der KI-Algorithmen und Infrastrukturabhängigkeit

Viele Organisationen fokussieren sich bei Hochrisiko-KI auf Modellkarten, Fairness und Erklärbarkeit. Für NIS2 reicht das nicht. Der Audit fragt:

• Auf welcher Infrastruktur liefen diese Modelle – und in welchem Zustand?
• Welche Kontrollen waren zum Deployment-Zeitpunkt aktiv und nachweisbar?
• Kann ich als Prüfer einen konsistenten Faden von der Modellentscheidung bis zum geprüften Unterbau ziehen?

Der praktikable Ansatz: Jede relevante KI-Deployment-Version mit einem konkreten Infrastruktur-Snapshot verknüpfen – maschinenlesbar und kryptografisch verifizierbar.

Interne Kontrollmechanismen und Nachweisführung

Organisatorisch scheitert NIS2 oft an Zersplitterung der Verantwortung – IT, Data Science, Informationssicherheit und Compliance arbeiten auf unterschiedlichen Listen und Tools. Drei Maßnahmen helfen:

1. Kontrollkatalog harmonisieren: NIS2, EU AI Act und Branchenvorgaben auf ein gemeinsames Set an Infrastrukturkontrollen konsolidieren
2. Nachweisformat standardisieren: Binäre, maschinenlesbare Validierungsergebnisse je Domain und Service als verbindliches Format definieren
3. Verantwortung klären: Feste Zuständigkeit für das regelmäßige Einholen, Archivieren und Auditieren des technischen Nachweises – inklusive Lieferanten-Scans

Ausblick: Wohin sich Cybersicherheit und KI-Regulierung entwickeln

Aus heutiger Sicht zeichnen sich vier klare Tendenzen ab:

• Stärkere Verzahnung von NIS2 und EU AI Act – insbesondere bei Hochrisiko-Systemen mit kritischer Infrastrukturrelevanz werden Anforderungen zusammengeführt
• Mehr Fokus auf Lieferketten – von Cloud-Plattformen bis zu spezialisierten KI-Dienstleistern werden Drittanbieter stärker in die Nachweispflicht einbezogen
• Verlagerung hin zu technischer Evidenz – Selbstauskünfte und unstrukturierte PDF-Policies verlieren Gewicht gegenüber maschinenlesbaren, verifizierbaren Nachweisen
• Höhere Erwartung an Automatisierung – Risikoanalysen, Infrastructure as Code und kontinuierliche Validierung werden zum Standard, nicht zur Ausnahme

Für deutsche Unternehmen mit Hochrisiko-KI bedeutet das: Wer Infrastruktur, Governance und Nachweisführung heute noch getrennt organisiert, produziert Reibungsverluste, Medienbrüche und Angriffsflächen im Audit. Wer sie zusammenführt, spart Zeit und reduziert Haftungsdruck im Vorstand.

Fazit und Handlungsempfehlungen

NIS2 verschärft die Erwartung an Ihre digitale Infrastruktur, besonders wenn Sie Hochrisiko-KI betreiben. Papier reicht nicht mehr. Gefragt sind prüffähige, technische Nachweise, die zeigen, in welchem Zustand sich Ihre Netze und Systeme zum Zeitpunkt der Prüfung befanden.

Priorisierte Schritte für Ihre Praxis

• Scope klären und Hochrisiko-KI zuordnen Welche Dienste fallen unter NIS2? Wo ist Hochrisiko-KI im Einsatz? Annex-III-Screening mit Zuordnung auf konkrete Domains, Systeme und Cloud-Konten.
• Gemeinsamen Kontrollkatalog definieren NIS2, EU AI Act und Branchenvorgaben in einem konsistenten Infrastrukturkontroll-Set zusammenführen. Kennzeichnen, welche Kontrollen zwingend technischen Nachweis benötigen (IAM, Netzwerk, Logging, Deployment-Pfade).
• Standardisiertes Nachweisformat einführen Maschinenlesbar, binär auswertbar, mit Zeitstempel und kryptografischer Verifizierbarkeit. Direkt in NIS2- und AI-Act-Dossiers einbettbar.
• Regelmäßige Validierung in Prozesse einbauen Infrastruktur-Checks in Change-, Release- und Incident-Prozesse verankern. Jede Änderung an Hochrisiko-KI löst automatisch einen Infrastruktur-Check aus.
• Lieferkette und Vendor-Risiko technisch absichern Kritische IKT-Drittdienstleister erfassen und sowohl Verträge als auch den nachweisbaren Infrastrukturzustand prüfen. CERTavia Vendor Scan ergänzt klassische Fragebögen um technische Evidenz.

NIS2 wird beherrschbar, wenn Ihr Leitsatz lautet: Erst Kontrolle definieren, dann Nachweis spezifizieren. CERTavia setzt genau dort an und liefert maschinenlesbare, kryptografisch verifizierbare Evidenz als Baustein Ihrer NIS2- und AI-Act-Dokumentation. Für Vorstände und Entscheider erklärt eine eigene Seite, wie dieser Nachweis im Prüfgespräch wirkt.

CERTavia analysiert technische Infrastruktursignale. Das Ergebnis ist ein maschinenlesbarer Befund, kein Rechtsgutachten und keine Zertifizierung im Sinne der EU AI Act Konformitätsbewertung nach Artikel 43. Für rechtsverbindliche Compliance-Bewertungen wenden Sie sich an eine zugelassene Konformitätsbewertungsstelle.