NIS2 und KI-Systeme: Warum Ihr Chatbot Teil der Lieferkette ist
NIS2 erwähnt KI mit keinem Wort und erfasst sie trotzdem - über Risikomanagement und Lieferkettensicherheit. Was das für Architekturentscheidungen bedeutet.
NIS2 und KI Systeme: Warum Ihr Chatbot Teil der Lieferkette ist
<p data speakable NIS2 erwähnt künstliche Intelligenz an keiner Stelle und erfasst sie trotzdem. Nicht über einen KI Paragrafen, sondern über zwei allgemeine Anforderungen: Risikomanagement für Netz und Informationssysteme und Sicherheit der Lieferkette. Ein Sprachmodell, das über eine fremde API läuft, ist damit kein Werkzeug wie ein Texteditor. Es ist ein Lieferant. Dieser Artikel beschreibt, was daraus für Architekturentscheidungen folgt. Er ist keine Rechtsberatung; den Umsetzungsstand und Ihre Einordnung klären Sie mit Ihrer Rechtsabteilung.</p
Die Lücke, die keine ist
Wer NIS2 nach „KI" durchsucht, findet nichts. Daraus wird gelegentlich geschlossen, KI Systeme seien nicht betroffen.
Der Schluss ist falsch, und zwar aus demselben Grund, aus dem die DSGVO funktioniert, ohne einzelne Technologien zu benennen: Die Anforderungen sind an Funktionen geknüpft, nicht an Produktkategorien.
Zwei Anknüpfungspunkte genügen.
Risikomanagement für Netz und Informationssysteme. Ein KI System, das in Ihre Prozesse eingebunden ist, gehört dazu. Es verarbeitet Daten, es hat Schnittstellen, es kann ausfallen, es kann kompromittiert werden. Damit gehört es in dieselbe Betrachtung wie jedes andere System.
Sicherheit der Lieferkette. Das ist der Teil, der in der Praxis unterschätzt wird. Sobald ein externer Anbieter beteiligt ist, ist er Teil Ihrer Lieferkette und deren Sicherheit ist ausdrücklich Gegenstand der zu treffenden Maßnahmen.
Was das praktisch verschiebt
In den meisten Organisationen wird KI beschafft wie Software: Die Fachabteilung findet ein Werkzeug, testet es, führt es ein. Ein Vertrag wird geschlossen, vielleicht ein Auftragsverarbeitungsvertrag, und damit gilt die Sache als geregelt.
Unter NIS2 trägt dieser Weg nicht mehr, aus drei Gründen.
Die Lieferkette ist länger als der Vertrag
Ihr Anbieter sitzt in Europa. Sein Modell Backend möglicherweise nicht. Dessen Infrastruktur wiederum liegt bei einem Dritten. Sie haben einen Vertrag mit dem ersten Glied und eine Verantwortung für die Kette.
Die praktische Frage lautet nicht „habe ich einen Vertrag?", sondern „kann ich die Kette benennen?". Bei den meisten KI Diensten endet die belastbare Auskunft nach dem ersten Glied.
Meldefristen laufen in Stunden
Bei erheblichen Sicherheitsvorfällen sind kurze Fristen vorgesehen eine erste Meldung binnen weniger Stunden, eine ausführlichere binnen weniger Tage. Diese Fristen laufen ab Kenntnis.
Und genau da sitzt das Problem: Bei einem externen Dienst hängt Ihre Kenntnis daran, dass der Anbieter Sie informiert. Wenn dessen Meldeprozess drei Tage braucht, ist Ihre eigene Frist bereits abgelaufen, bevor Sie überhaupt wissen, dass etwas passiert ist.
Diese Kette gehört vertraglich geregelt und technisch überwacht. Der zweite Teil fehlt fast immer.
Die Leitung haftet persönlich
NIS2 nimmt die Geschäftsleitung in die Pflicht, inklusive persönlicher Verantwortung für die Umsetzung der Risikomanagementmaßnahmen. Das verschiebt die Entscheidung über KI Beschaffung nach oben.
Für die Technik heißt das: Die Architektur muss so beschaffen sein, dass jemand ohne technischen Hintergrund die Verantwortung dafür übernehmen kann. Ein Datenflussdiagramm, das auf eine Seite passt, ist unter dieser Bedingung kein Nice to have.
Vier Fragen an jedes KI Vorhaben
Was ich mit Kunden durchgehe, bevor über Technik gesprochen wird.
1. Wer kann auf die Inhalte zugreifen? Nicht wer darf. Wer kann. Die Antwort ist eine Liste von Parteien. Wenn die Liste länger als zwei Einträge ist oder Namen enthält, die Sie nicht kennen, haben Sie ein Lieferkettenproblem und noch kein KI Projekt.
2. Wie erfahren Sie von einem Vorfall beim Lieferanten, und wie schnell? Wenn die Antwort „per E Mail, irgendwann" lautet, ist Ihre Meldefrist nicht haltbar.
3. Was passiert, wenn der Dienst morgen nicht mehr verfügbar ist? Nicht als Untergangsszenario, sondern als Verfügbarkeitsfrage. Wenn ein Prozess ohne den Dienst stillsteht und es keinen Rückfallpfad gibt, ist das ein Risiko, das in die Bewertung gehört.
4. Können Sie das alles belegen? Nicht behaupten, belegen. Datenflussplan, Zugriffsprotokolle ohne Klartextinhalte, dokumentierte Verschlüsselung, nachvollziehbare Lieferantenbewertung.
Diese vier Fragen entscheiden häufiger über die Architektur als jede technische Präferenz.
Wo Self Hosting hilft, und wo nicht
Self Hosting ist unter NIS2 nicht vorgeschrieben und macht ein System auch nicht automatisch sicherer. Ein selbst betriebener Dienst, den niemand patcht, ist schlechter als ein gepflegter fremder.
Der Gewinn liegt woanders: in der Verkürzung der Kette .
Bei einem selbst betriebenen System hat die Lieferkette ein Glied, und über dieses Glied haben Sie vollständige Auskunft. Sie wissen, wer Zugriff hat, weil Sie die Zugänge vergeben. Sie erfahren von einem Vorfall, weil Ihr eigenes Monitoring ihn meldet, nicht weil ein Anbieter sich meldet. Und der Nachweis gegenüber einer Prüfung ist ein Blick in Ihre eigenen Systeme statt eine Anfrage bei einem Dritten, der in einer anderen Zeitzone sitzt.
Dafür tauschen Sie Aufwand ein: Patch Management, Wiederherstellungstests, Zertifikate, Monitoring, Aufbewahrungsfristen. Das ist echte Arbeit und der ehrliche Preis.
Die Rechnung geht auf, wenn die Alternative eine Kette ist, die Sie nicht schließen können. Sie geht nicht auf, wenn Sie den Betriebsaufwand nicht tragen können dann ist ein gut gewählter Dienstleister mit belastbaren Zusagen die bessere Wahl.
Was ich baue, wenn NIS2 der Treiber ist
Der technische Kern unterscheidet sich nicht grundlegend von dem, was ich für Berufsgeheimnisträger baue die Begründung ist eine andere, die Anforderungen überschneiden sich stark:
Der Datenpfad endet im eigenen Verantwortungsbereich, kein Dritt Dienst dazwischen Zugriffe werden protokolliert, Inhalte nicht; Identifikatoren gehasht Monitoring meldet Auffälligkeiten an das eigene Team, ohne Umweg über einen Anbieter Ein Datenflussplan, der auf eine Seite passt und den auch die Leitung versteht Wiederherstellungstests dokumentiert, nicht nur Backups konfiguriert
Wie das im Detail aussieht, habe ich in der Case Study zur Art. 9 Plattform aufgeschrieben. Die dort beschriebene Datenklasse ist eine andere, die Architekturfragen sind dieselben.
Für Berufsgeheimnisträger gilt zusätzlich § 203 StGB, was die Anforderungen noch einmal verschärft.
Der pragmatische Einstieg
Wenn NIS2 gerade auf Ihrem Tisch liegt und KI Teil des Themas ist:
Erst inventarisieren. Welche KI Dienste sind heute im Einsatz, offiziell und inoffiziell? Die inoffizielle Hälfte ist meist die größere und für die Lieferkettenbetrachtung die relevantere.
Dann die Kette benennen. Für jeden Dienst: Wer sind die Beteiligten, wo liegen die Daten, wie läuft die Vorfallmeldung? Was Sie hier nicht beantworten können, ist Ihr eigentliches Ergebnis.
Erst dann bauen. Die Architekturentscheidung fällt viel leichter, wenn die ersten beiden Schritte erledigt sind und manchmal stellt sich heraus, dass gar kein neues System nötig ist, sondern nur eine geordnete Ablösung von drei ungeregelten.
Wenn Sie an dieser Stelle stehen: Ich baue KI Systeme für regulierte Umgebungen, bei denen die Lieferkette ein Glied hat und der Nachweis Teil der Lieferung ist. Im Erstgespräch klären wir zuerst, ob das in Ihrem Fall überhaupt nötig ist.