NIS-2 und KI-Systeme – wann Sicherheit zur Pflicht wird

KI-Systeme sind nicht automatisch ein NIS-2-Thema. Relevant wird die Richtlinie dort, wo KI in wesentliche oder wichtige Dienste eingebunden ist, Angriffsflächen vergrößert oder Entscheidungen in sicherheitskritischen Prozessen beeinflusst. Für betroffene Organisationen zählt dann weniger der Hype um Modelle als die Frage, ob Technik, Betrieb und Lieferkette belastbar abgesichert sind.

Warum NIS-2 bei KI nicht am Modell, sondern am Einsatz ansetzt

NIS-2 reguliert nicht „KI“ als Technologie, sondern die Cybersicherheit von Einrichtungen, die für Wirtschaft und Gesellschaft besonders wichtig sind. Wer KI in solche Abläufe einbindet, macht sie damit zu einem Teil des Sicherheits- und Risikomanagements.

Das ist ein wichtiger Unterschied zum EU AI Act. Der AI Act ordnet KI-Systeme nach Risikoklassen ein und stellt je nach Kategorie Anforderungen an Transparenz, Dokumentation oder menschliche Aufsicht. NIS-2 fragt dagegen, ob eine Organisation ihre Netz- und Informationssysteme angemessen schützt, Vorfälle erkennt und ihre Lieferkette beherrscht. Ein Chatbot im Marketing ist daher meist ein anderes Thema als ein KI-Modul in Energieversorgung, Gesundheitswesen, Wasser, Transport, Verwaltung oder digitaler Infrastruktur.

Praktisch bedeutet das: Ein KI-System kann regulatorisch unauffällig wirken und trotzdem unter NIS-2 sicherheitsrelevant sein. Schon ein extern eingebundener Assistent, der interne Wissensdatenbanken, Supportsysteme oder Betriebsinformationen verarbeitet, kann neue Einfallstore schaffen. Dazu zählen fehlerhafte Zugriffsrechte, unsichere Schnittstellen, Abhängigkeiten von Cloud-Diensten oder Manipulationen durch Eingaben, wie sie bei gezielten Eingabeangriffen sichtbar werden.

Anzeige

Für die Praxis im Mittelstand und in öffentlichen Stellen ist daher die Kernfrage nicht, ob ein Modell „intelligent“ ist. Entscheidend ist, ob die Anwendung kritische Prozesse stützt, sensible Daten berührt oder Ausfälle und Fehlentscheidungen in realen Abläufen auslösen kann. Dann wird aus einem Innovationsprojekt ein Sicherheitsgegenstand mit Governance-Pflichten.

Welche KI-Einsätze unter NIS-2 besonders sensibel sind

Nicht jede Automatisierung ist gleich kritisch. Sensibel wird KI vor allem dort, wo sie in Betriebssteuerung, Zugangskontrolle, Sicherheitsüberwachung oder verfügbarkeitskritische Prozesse eingreift.

Typische Beispiele sind Anomalieerkennung in Industrienetzen, KI-gestützte Priorisierung in Leitstellen, automatische Auswertung von Sicherheitsmeldungen, Supportsysteme mit Zugriff auf interne Dokumentation oder generative Assistenten in Verwaltungs- und Fachverfahren. Auch Systeme, die Konfigurationen vorschlagen oder Tickets in IT- und OT-Umgebungen automatisiert bearbeiten, können sicherheitsrelevant sein. Ein Fehler bleibt dann nicht auf dem Bildschirm, sondern kann Produktionslinien, Dienste oder Verwaltungsabläufe treffen.

Hinzu kommt die Lieferkette. Viele Organisationen betreiben KI nicht selbst, sondern nutzen APIs, Cloud-Plattformen, Integratoren oder Fachsoftware mit eingebetteten Modellen. Genau diese Abhängigkeiten sind unter NIS-2 wichtig, weil Sicherheitsprobleme bei Dienstleistern auf den eigenen Betrieb durchschlagen können. Wenn Zugriffe, Logs, Update-Prozesse oder Rollenverteilungen unklar sind, steigt das Risiko, ohne eigene Schwachstelle betroffen zu sein.

Besonders heikel sind hybride Szenarien: Ein Sprachmodell greift auf Wissensdatenbanken zu, erzeugt Handlungsempfehlungen für Mitarbeitende und ist gleichzeitig mit Ticketsystemen oder Identitätsdiensten verbunden. Dann entstehen kombinierte Risiken aus Datenabfluss, Fehlbedienung, Manipulation und Ausfall. Aus Sicht von Aufsicht und IT-Sicherheit ist das keine bloße Komfortfunktion mehr, sondern Teil der digitalen Betriebsfähigkeit.

• Greift das System auf interne Betriebs-, Personen- oder Sicherheitsdaten zu?
• Beeinflusst es Verfügbarkeit, Integrität oder Vertraulichkeit wesentlicher Dienste?
• Kann es durch externe Inhalte, Prompts oder Datenquellen manipuliert werden?
• Besteht eine Abhängigkeit von Cloud-, API- oder Modell-Anbietern?
• Sind menschliche Freigaben nur formal vorhanden, aber praktisch wirkungslos?
• Fehlen Nachvollziehbarkeit, Protokollierung oder klare Eskalationswege bei Vorfällen?

Was verlangt NIS-2 organisatorisch von betroffenen Einrichtungen?

NIS-2 verlangt kein Spezialkapitel nur für KI, aber sie zwingt betroffene Organisationen zu belastbarer Sicherheitssteuerung. Wenn KI-Systeme relevant für den Betrieb sind, müssen sie in Governance, Risikoanalyse und Vorfallsprozesse integriert werden.

Dazu gehört zunächst ein systematisches Risikomanagement. Organisationen müssen erkennen, welche Systeme kritisch sind, welche Abhängigkeiten bestehen und welche Schäden bei Ausfall, Missbrauch oder Manipulation entstehen können. Für KI bedeutet das: Datenquellen, Modellzugriffe, Schnittstellen, Rollen, Protokollierung und Update-Prozesse dürfen nicht als Black Box behandelt werden. Gerade bei generativen Systemen ist zu klären, wer Ausgaben freigibt, wie Fehlverhalten erkannt wird und wann ein Fallback ohne KI möglich ist.

Ein zweiter Kernpunkt ist die Verantwortung auf Leitungsebene. NIS-2 stärkt die Pflicht, Cybersicherheit nicht als reine IT-Aufgabe zu behandeln. Wenn eine Einrichtung KI in sensible Abläufe einführt, ist das deshalb auch ein Thema für Geschäftsführung, Behördenleitung oder Vorstand. Entscheidungen über Anbieter, Risiken, Mindestkontrollen und Eskalationen müssen nachvollziehbar sein. Das ähnelt dem Gedanken aus dem strukturierten Folgenblick, ist unter NIS-2 aber stärker auf Resilienz und Incident Response ausgerichtet.

Anzeige

Drittens verlangt der Rahmen eine funktionierende Reaktion auf Sicherheitsvorfälle. Bei KI ist das anspruchsvoll, weil Vorfälle nicht nur klassische Kompromittierungen sein müssen. Auch manipulierte Ausgaben, vergiftete Eingabedaten, missbrauchte Berechtigungen oder Fehlentscheidungen durch automatisierte Priorisierung können melde- und dokumentationsrelevant werden, wenn sie erhebliche Auswirkungen auf Dienste oder Sicherheit haben.

Welche Unterlagen in der Praxis oft fehlen

Viele Probleme entstehen nicht durch fehlende Absicht, sondern durch fehlende Dokumentation. Ohne aktuelle Systemübersicht, Verantwortlichkeiten, Datenflüsse und Lieferanteninformationen lässt sich kaum belegen, dass ein KI-Einsatz kontrolliert betrieben wird.

Oft fehlen insbesondere Freigaberegeln, Modell- und Versionsstände, Testprotokolle, Abnahmeentscheidungen, Rollenprofile und technische Grenzen des Systems. Wer nicht sauber dokumentiert, erkennt Vorfälle später, reagiert langsamer und kann Abhängigkeiten schlechter bewerten. Für Organisationen, die zusätzlich unter den AI Act oder Datenschutzpflichten fallen, vervielfacht sich dieses Problem, weil dieselben Lücken auch dort relevant werden.

Wie unterscheiden sich KI-Risiken unter NIS-2 von klassischen IT-Risiken?

KI erweitert bekannte Cyberrisiken, ersetzt sie aber nicht. Neu ist vor allem, dass Systeme probabilistisch arbeiten, sich schwerer vorhersagen lassen und durch Inhalte beeinflusst werden können, nicht nur durch Schadcode.

Klassische IT-Sicherheit denkt in Schwachstellen, Berechtigungen, Patches und Netzsegmentierung. Das bleibt wichtig. Bei KI kommen jedoch Risiken hinzu, die zwischen Sicherheit, Qualität und Governance liegen: manipulierte Eingaben, unbemerkte Fehlklassifikationen, unerwartete Modellantworten, Datenabfluss über Kontexteingaben oder unklare Grenzen zwischen Test- und Produktivbetrieb. Begriffe wie Prompt Injection oder Datenvergiftung beschreiben genau solche Angriffe auf die Funktionslogik statt auf den Server allein.

Ein weiteres Merkmal ist die schwierige Nachvollziehbarkeit. Bei regelbasierten Systemen ist oft klar, warum eine Entscheidung fiel. Bei KI-Systemen kann ein Fehler dagegen aus Trainingsdaten, Konfiguration, Kontextdaten oder Benutzerinteraktion stammen. Das erschwert Forensik, Meldebewertung und Ursachenanalyse. Für NIS-2 ist das relevant, weil wirksames Vorfallmanagement nicht nur Reaktion, sondern auch belastbare Rekonstruktion voraussetzt.

Schließlich verändern KI-Systeme die Bedrohungslage selbst. Angreifer nutzen generative Modelle für Social Engineering, Täuschung, Recherche und Automatisierung. Verteidiger setzen ebenfalls KI ein, etwa für Erkennung und Priorisierung. Gerade dadurch steigt aber die Gefahr, dass übermäßig vertraute Automatisierung Fehlalarme übersieht oder falsche Prioritäten setzt. Sicherheitsgewinn entsteht also nicht durch KI an sich, sondern durch kontrollierten Einsatz mit klaren Grenzen.

Wer ist betroffen, wenn die KI nur eingekauft wird?

Auch bei zugekauften KI-Diensten bleibt die Verantwortung nicht einfach beim Anbieter. NIS-2 schaut auf die Sicherheit der betroffenen Einrichtung – und damit auf Auswahl, Einbindung und Überwachung externer Leistungen.

Das ist für viele Häuser ungewohnt, weil KI häufig als fertiger Cloud-Dienst beschafft wird. Vertrag, Zertifizierungen oder Marketingaussagen ersetzen jedoch kein eigenes Risikobild. Wer ein Modell über eine API nutzt, muss dennoch wissen, welche Daten wohin fließen, wie Authentifizierung und Protokollierung funktionieren, welche Subunternehmer beteiligt sind und wie auf Störungen reagiert wird. Je kritischer der Prozess, desto weniger tragfähig ist das Argument, man habe nur eine Standardlösung verwendet.

Besonders relevant ist die Abgrenzung von Rollen. Der Anbieter des Modells, der Integrator, der Fachsoftware-Hersteller und die nutzende Organisation können jeweils unterschiedliche Beiträge zum Risiko leisten. Unter dem AI Act spielen solche Rollen ebenfalls eine große Rolle, etwa bei Betriebspflichten für Risikosysteme. Unter NIS-2 geht es jedoch stärker um Lieferantensteuerung, Sicherheitsmaßnahmen und Meldefähigkeit im laufenden Betrieb.

In der Praxis heißt das: Externe KI entlastet nicht von interner Verantwortung. Wer Sicherheitsrelevanz an einen Dienst auslagert, braucht Vertragsklarheit, Exit-Szenarien, Mindestanforderungen an Transparenz und technische Kontrollen auf der eigenen Seite. Sonst bleibt im Ernstfall zwar der Anbieter sichtbar, aber die Einrichtung selbst regulatorisch verwundbar.

Was sollten Organisationen vor dem Einsatz konkret prüfen?

Vor dem produktiven Einsatz von KI in relevanten Prozessen sollten Organisationen wenige, aber präzise Fragen beantworten. Das Ziel ist nicht Vollständigkeit auf dem Papier, sondern eine belastbare Entscheidung darüber, ob das System sicher und steuerbar betrieben werden kann.

Anzeige

Eine erste Frage betrifft die Kritikalität: Welche Geschäfts-, Verwaltungs- oder Infrastrukturprozesse hängen von dem System ab? Danach folgt die Datenfrage: Welche Informationen verarbeitet die KI, welche davon sind sensibel, und wohin verlassen sie die eigene Umgebung? Drittens ist zu prüfen, ob das System in Entscheidungen eingreift oder nur unterstützt. Diese Unterscheidung entscheidet oft darüber, wie streng Freigaben, Protokolle und menschliche Kontrolle ausgestaltet sein müssen.

Ebenso wichtig ist die technische Einbindung. APIs, Plug-ins, Retrieval-Komponenten, Wissensdatenbanken und Identitätsdienste erhöhen Nutzen und Risiko zugleich. Wer hier sauber trennt, Berechtigungen begrenzt und Logs auswertbar hält, reduziert Angriffsflächen. Das passt auch zu datenschutzrechtlichen Anforderungen, die bei personenbezogenen KI-Einsätzen oft parallel zu prüfen sind.

• Ist dokumentiert, in welchem Prozess die KI eingesetzt wird und welche Ausfälle spürbar wären?
• Ist bekannt, welche Datenquellen, Modelle, APIs und Dienstleister beteiligt sind?
• Gibt es technische und organisatorische Grenzen für Zugriffe, Ausgaben und Aktionen?
• Wer bewertet Sicherheitsvorfälle, und wann werden Leitung und Fachbereiche eingebunden?
• Ist ein Betrieb ohne KI oder mit reduziertem Funktionsumfang vorübergehend möglich?
• Werden Modelländerungen, neue Funktionen und Schnittstellen vor Freigabe getestet?
• Ist klar, ob neben NIS-2 auch DSGVO, Fachrecht oder der EU AI Act relevant sind?

Bleiben trotz NIS-2 wichtige Fragen offen?

NIS-2 setzt einen klaren Rahmen für Sicherheitsorganisation, beantwortet aber nicht jede Detailfrage zu KI. Offen bleibt oft, wie weit Transparenz von Anbietern reicht, wie tief Audits technisch gehen können und wann ein KI-bezogener Vorfall genau die Schwelle zur Meldung überschreitet.

Diese Unsicherheit ist nicht ungewöhnlich. Regulierung entwickelt sich im Zusammenspiel von Aufsichtsbehörden, nationaler Umsetzung und Praxisfällen. Für Deutschland werden Stellen wie das BSI, branchenspezifische Aufsichten und europäische Akteure wie ENISA wichtig sein, wenn es um Auslegung, Mindeststandards und Erwartungshaltungen geht. Parallel konkretisieren AI Office, Datenschutzaufsichten und Gerichte das Umfeld, in dem KI betrieben wird.

Für betroffene Einrichtungen ist deshalb eine nüchterne Einordnung sinnvoll: NIS-2 ist kein KI-Spezialgesetz, aber ein scharfes Sicherheitsregime für Organisationen, die digital besonders relevant sind. Wer KI in kritische Abläufe bringt, erhöht Komplexität, Abhängigkeiten und potenzielle Auswirkungen von Vorfällen. Genau deshalb sollte der Einsatz nicht nur nach Nutzen, sondern auch nach Lieferkettenrisiko, Meldefähigkeit und betrieblicher Resilienz bewertet werden.

Unterm Strich verschiebt KI unter NIS-2 nicht die Grundlogik, sondern den Prüfmaßstab. Sicherheit wird weniger an Werbeversprechen und mehr an dokumentierten Kontrollen, klarer Verantwortung und realistischen Notfallabläufen gemessen. Für Organisationen mit wesentlichen oder wichtigen Diensten ist das keine Sonderfrage der Innovation, sondern Teil ihrer Pflicht zur digitalen Betriebsfähigkeit.

Hinweis: Dieser Beitrag bietet allgemeine Information zu KI-Risiken und Regulierung und ersetzt keine Rechtsberatung. Konkrete Pflichten, Bußgeldhöhen und Geltungstermine können sich ändern und im Einzelfall abweichen. Für verbindliche Auskünfte ist eine fachkundige Prüfung durch Anwält:innen oder Datenschutzbeauftragte erforderlich. Der Artikel wurde mit KI-Unterstützung erstellt und redaktionell geprüft.

Anzeige