NIS2 und EU AI Act zusammen: wo sich die beiden Pflichten überschneiden

Wie viel von Ihrer NIS2-Arbeit zählt unter dem AI Act?

Sieben von neun Kontrollbereichen sind teilweise wiederverwendbar. Das Risikoregister, das Asset-Inventar, die Protokollierungsplattform, der Vorfallprozess, der Klauselsatz für Lieferanten, die Dokumentenablage und das Schulungsprogramm aus Ihrem BSIG-Projekt tragen unter dem AI Act weiter. Vier Bereiche müssen Sie von null aufbauen, und die Meldewege lassen sich nicht zusammenlegen.

In der Branche kursiert eine Wiederverwendungsquote von 80 Prozent. Wir halten sie für zu hoch, und sie lenkt die Planung in die falsche Richtung. Übertragbar ist das Gerüst: Rollen, Prüfzyklen, Freigabe-Workflow, Format der Verzeichnisse. Der Nachweis selbst kaum. Eine Risikoanalyse zur Informationssicherheit sagt nichts darüber, ob Ihre Trainingsdaten repräsentativ sind, und ein Schwachstellenbericht ersetzt keine Verzerrungsmessung. Die gute Nachricht: das Gerüst zu bauen dauert Monate, es zu füllen dauert Wochen.

Wer fällt gleichzeitig unter NIS2 und den AI Act?

Die beiden Anwendungsbereiche sind voneinander unabhängig. Das BSIG greift nach Sektor und Größe, der AI Act danach, wofür Sie KI einsetzen. Die Schnittmenge ist trotzdem groß: jede Einrichtung ab 50 Beschäftigten aus Anlage 1 oder 2, die Bewerbungen vorsortiert oder Leistung überwacht, fällt unter beides.

Für die deutsche Einordnung zählt § 28 BSIG. Besonders wichtige Einrichtungen beginnen bei 250 Beschäftigten oder über 50 Mio. EUR Umsatz und zugleich über 43 Mio. EUR Bilanzsumme, wichtige Einrichtungen bei 50 Beschäftigten oder bei jeweils über 10 Mio. EUR Umsatz und Bilanzsumme. Betroffen sind rund 30.000 Unternehmen (OpenKRITIS), und die Registrierungsfrist nach § 33 Abs. 1 BSIG ist nach Angaben des BSI bereits abgelaufen (BSI, Abruf 14.08.2026). Anwendungsbereich, Fristen und Bußgeldrahmen haben wir im NIS2-Grundlagenartikel aufgeschlüsselt, hier interessiert nur die Schnittmenge.

Die letzte Zeile verdient eigene Aufmerksamkeit. Die meisten Unternehmen halten den Hochrisiko-Teil des AI Act für ein Thema der Energiewirtschaft und der Kliniken. In der Praxis ist das häufigste Hochrisiko-System ein HR-Werkzeug, das mit einer Recruiting-Suite mitgeliefert wurde und von dem die IT nichts weiß. Fragen Sie im Fachbereich nach, nicht im Rechenzentrum.

Was verlangen BSIG und AI Act bei derselben Kontrolle?

In neun Bereichen verlangen beide etwas Ähnliches. Lieferkette, Betriebskontinuität und Schulung überschneiden sich fast vollständig. Risikomanagement und Dokumentation überschneiden sich im Rahmen, nicht im Inhalt. Die Protokollierung zur Hälfte, weil der AI Act die Entscheidungsspur des Modells verlangt und nicht das Serverlog. Die Vorfallbehandlung überschneidet sich im Prozess und gar nicht im Meldeweg.

Diese Tabelle ist unsere eigene Lesart der beiden Regime. Weder das BSI noch eine Marktüberwachungsbehörde hat bislang eine Handreichung zur Abstimmung der beiden Pflichtenkreise veröffentlicht, und bis August 2026 haben wir dazu keine behördliche Position gefunden. Wer Ihnen eine belastbarere Antwort verspricht, verkauft eine Eigeninterpretation als gesicherte Rechtslage. Die Pflichtbereiche aus § 30 BSIG haben wir in der NIS2-Checkliste für IT-Leiter einzeln aufgeschlüsselt.

Welche Meldewege laufen in Deutschland parallel?

Drei, und sie haben unterschiedliche Fristen, Empfänger und Auslöser. Ein Ransomware-Vorfall mit Datenabfluss löst heute zwei davon gleichzeitig aus. Der dritte kommt am 2. Dezember 2027 dazu, sobald Art. 73 AI Act auf Hochrisiko-Systeme anwendbar wird. Zusammenlegen lässt sich keiner der drei.

Welche Stelle in Deutschland die Marktüberwachung für KI übernimmt, nennen wir hier nicht. Zum Redaktionsschluss lag uns dazu keine zitierfähige Quelle vor, und eine deutsche Zuständigkeit zu raten wäre an dieser Stelle das Gegenteil von hilfreich. Klären Sie den Adressaten mit Ihrer Rechtsberatung, bevor Sie den Eskalationsplan verabschieden. Die 24-Stunden-Uhr aus § 32 BSIG bleibt davon unberührt, und sie ist die einzige der drei, die an einem Sonntagabend wirklich weh tut.

Wo reicht die NIS2-Arbeit allein nicht aus?

In vier Bereichen. Die Grundrechte-Folgenabschätzung, die Datenkontrolle mit Verzerrungsmessung, die Gestaltung der menschlichen Aufsicht und der Nachweis der Genauigkeit verlangen Belege, die ein Informationssicherheitsprogramm nie erzeugt. Dafür brauchen Sie eigene Arbeitspakete mit eigenem Budget, und die Fachkompetenz dafür kommt aus der Datenanalyse und dem Fachbereich, nicht aus dem SOC.

Grundrechte-Folgenabschätzung, Art. 27

Eine FRIA ist keine Risikoanalyse im IT-Sinn. Sie führt durch, welchen konkreten Schaden das System natürlichen Personen und Gruppen zufügen kann, wie häufig und wie lange es läuft, welche Aufsichtsmaßnahmen die Betroffenen schützen und wo sie sich beschweren können. Verpflichtet sind öffentliche Stellen, private Einrichtungen mit öffentlichen Dienstleistungen sowie Betreiber, die Kreditwürdigkeit bewerten oder Risiken in der Lebens- und Krankenversicherung einstufen. Kritische Infrastruktur als solche ist nicht erfasst. Die ausgefüllte Vorlage geht an die Marktüberwachungsbehörde. Auch dieser Termin ist auf den 2. Dezember 2027 gerutscht, weil Art. 27 in Kapitel III Abschnitt 3 steht.

Datenkontrolle und Verzerrungsmessung, Art. 10

Hier gibt es nichts zu übertragen. Art. 10 verlangt, dass Trainings-, Validierungs- und Testdaten relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei sind und dass Verzerrungen untersucht werden. Das erfordert Datenanalyse, Leistungsmessung je Untergruppe und die Dokumentation dessen, was Sie mit den gefundenen Abweichungen gemacht haben. Der Omnibus hat einen Punkt ausgeweitet: die Verarbeitung besonderer Kategorien personenbezogener Daten zum Zweck der Verzerrungserkennung gilt jetzt für alle KI-Systeme, nicht nur für Hochrisiko-Systeme, mit wiederhergestelltem strengem Erforderlichkeitsmaßstab.

Menschliche Aufsicht, Art. 14 und Art. 26

Art. 14 ist eine Gestaltungsanforderung: das System muss so gebaut sein, dass Aufsicht tatsächlich ausgeübt werden kann, einschließlich Eingriff und Abschaltung. Art. 26 verlangt vom Betreiber, diese Aufsicht einer fachkundigen, geschulten und befugten natürlichen Person zu übertragen. Der Informationssicherheitsbeauftragte ist dafür nicht automatisch die richtige Person, weil das Qualifikationsprofil ein anderes ist und die Rollen sich in der Praxis gegenseitig blockieren. Zwei getrennte Rollen, eine gemeinsame Verantwortungsmatrix.

Genauigkeit, Robustheit und Cybersicherheit, Art. 15

Das ist der einzige der vier Bereiche, in dem die BSIG-Arbeit teilweise zählt. Art. 15 Abs. 5 benennt die Widerstandsfähigkeit gegen Datenvergiftung, Modellvergiftung, feindliche Beispiele, Modellumgehung und Angriffe auf die Vertraulichkeit. Ihr Penetrationstest- und Schwachstellenprogramm lässt sich darauf ausdehnen. Was das BSIG nicht liefert, ist die Genauigkeitsmetrik: Sie müssen benennen, auf welchem Leistungsniveau das System arbeitet, das nach Art. 13 in der Betriebsanleitung angeben und laufend messen, ob es gehalten wird. Zur Verzahnung von AI Act und DSGVO haben wir gesondert im Beitrag zu AI Act, DSGVO und KI-Sicherheit geschrieben.

Was passiert, wenn ein KI-Agent Zugriff auf ein NIS2-System bekommt?

Ab diesem Moment ist der Agent Teil des Netz- und Informationssystems. Er gehört ins Asset-Inventar, braucht eine eigene Identität mit minimalen Rechten, seine Tätigkeit ist zu protokollieren, und bei einem Schaden läuft die 24-Stunden-Uhr. Wir sehen das in Projekten selten vollständig umgesetzt.

Zugriffsverwaltung

Der häufigste Fehler: der Agent meldet sich unter einem Mitarbeiterkonto an, weil das die schnellste Integration war. Damit brechen Zugriffskontrolle und Protokollierung gleichzeitig, denn im Log steht der Name einer Kollegin auch dann, wenn ein Modell in das System geschrieben hat. Verlangen Sie stattdessen ein eigenes Dienstkonto mit benanntem menschlichem Eigentümer, Leserechte als Standard, Schreibzugriffe ausschließlich über eine enge und widerrufbare Schnittstelle, rotierte Schlüssel und einen Notausschalter, der den Agenten mit einem Klick aus dem System nimmt. Der Notausschalter bedient die schnelle Reaktion nach § 30 BSIG und die menschliche Aufsicht nach Art. 14 AI Act in einem Zug.

Protokollierung

Ein Agent hinterlässt Spuren in drei Schichten, und die klassische NIS2-Protokollierung erfasst nur die erste.

• Infrastrukturebene: Anmeldung, API-Aufruf, Datenbankoperation. Das landet ohnehin im SIEM und deckt den Detektionsteil des § 30 BSIG ab.
• Entscheidungsebene: welcher Prompt ankam, welches Werkzeug das Modell mit welchen Parametern aufgerufen hat und was zurückkam. Das ist der Gegenstand von Art. 12 AI Act, und in ein typisches SIEM kommt es nicht.
• Modellversionsebene: welches Modell, welche Version, welcher Systemprompt, welche Temperatur. Ohne diese Angaben lässt sich eine Entscheidung von vor sechs Monaten nicht rekonstruieren.

Die Aufbewahrung richtet sich nach der strengeren Frist. Der AI Act verlangt nach Art. 19 und Art. 26 Abs. 6 mindestens sechs Monate, branchenspezifische Vorgaben können länger sein. Wie die zweite Schicht werkzeugseitig aussieht, zeigt unser Vergleich von Langfuse und LangSmith.

Die 24-Stunden-Uhr bei einem KI-Vorfall

Hier liegt der rechtlich unsicherste Punkt, und es ist besser, das auszusprechen, als sich souverän zu irren. Art. 23 Abs. 3 der Richtlinie (EU) 2022/2555 knüpft die Erheblichkeit eines Vorfalls an die Wirkung: schwerwiegende Betriebsstörung, finanzieller Verlust oder erheblicher materieller wie immaterieller Schaden bei anderen. Von einem Angreifer ist dort nicht die Rede. Wenn ein Agent falsche Daten in das ERP zurückschreibt und die Auslieferung steht, passt der Wortlaut. Eine behördliche Klarstellung dazu kennen wir nicht.

Unsere praktische Abgrenzung sieht so aus. Hat eine externe Beeinflussung den Vorfall ausgelöst, etwa eine Prompt Injection in einer eingehenden Mail oder einem Dokument, behandeln wir ihn als Sicherheitsvorfall, und die 24 Stunden nach § 32 BSIG laufen. Handelt es sich um einen reinen Modellfehler ohne gegnerisches Zutun, ist es zunächst ein Qualitätsfehler, aus dem ein schwerwiegender Vorfall nach Art. 73 AI Act werden kann, sofern das System als Hochrisiko-System eingestuft ist. Nur ist Art. 73 auf Hochrisiko-Systeme bis zum 2. Dezember 2027 nicht anwendbar. Heute gibt es für die Fehlfunktion eines nicht als Hochrisiko eingestuften Agenten also keine unionsrechtliche KI-Meldepflicht. Das BSIG kann trotzdem greifen.

Was müssen Sie vertraglich von Ihrem KI-Lieferanten verlangen?

§ 30 BSIG macht die Sicherheit der Lieferkette zu Ihrem Problem, einschließlich der Beziehungen zu unmittelbaren Anbietern, und § 38 BSIG belässt die Verantwortung bei der Geschäftsleitung. Der Vertrag ist deshalb keine Formalie. Er ist Ihr einziges durchsetzbares Instrument gegenüber dem Lieferanten.

Im deutschen Einkauf ist die letzte Zeile meist die erste Frage. Der Auftragsverarbeitungsvertrag wird geprüft, bevor irgendjemand über Architektur spricht. Bitkom hat Datenschutzanforderungen in einer Befragung von 604 Unternehmen ab 20 Beschäftigten als größte externe Hürde für den KI-Einsatz gemessen, genannt von 77 Prozent (Bitkom, 11.03.2026). Ein KI-Anbieter, der ohne AVV und ohne Unterauftragnehmerliste erscheint, kommt in die technische Diskussion gar nicht erst hinein.

Umgekehrt gilt dasselbe, und das ist der am wenigsten genutzte Kanal im Markt. Zehntausende Zulieferer, die selbst nicht unter § 28 BSIG fallen, bekommen dieselben Anforderungen über den Vertrag. Wenn Sie Software oder KI-Systeme liefern, legt Ihnen früher oder später jemand diesen Klauselsatz vor. Besser, Sie bringen ihn selbst mit.

Wie sieht ein gemeinsamer Compliance-Plan aus?

Ein Inventar, ein Risikoregister, eine Protokollierungsrichtlinie, ein Vorfallprozess mit getrennten Meldewegen, ein Lieferantenpaket und ein Schulungsprogramm. Darauf kommen die vier KI-eigenen Arbeitspakete. Der Zeitplan unten setzt voraus, dass die BSIG-Grundlagen stehen und dass Sie zum 2. Dezember 2027 AI-Act-fähig sein wollen.

Eines sollten Sie nicht aufschieben. Die Transparenzpflichten aus Art. 50 gelten seit dem 2. August 2026, die Bußgeldvorschriften aus Art. 99 sind seit dem 2. August 2025 anwendbar. Läuft auf Ihrer Website ein Chatbot, ohne dass die Besucherin erfährt, dass sie mit einer Maschine spricht, ist das heute ein Verstoß und kein künftiges Risiko. Der Aufwand liegt bei wenigen Stunden.

Zusammenfassung und häufige Fragen

Quellen

• EUR-Lex: Richtlinie (EU) 2022/2555 (NIS2), Art. 23 zur Meldepflicht
• BSIG in der Fassung des NIS2UmsuCG, gesetze-im-internet.de
• § 30 BSIG: Risikomanagementmaßnahmen besonders wichtiger und wichtiger Einrichtungen
• § 32 BSIG: Meldepflichten bei erheblichen Sicherheitsvorfällen
• OpenKRITIS: NIS2-Umsetzungsgesetz und neues BSIG, rund 30.000 betroffene Unternehmen
• BSI: NIS-2-regulierte Unternehmen, Registrierung und Meldewesen
• EUR-Lex: Verordnung (EU) 2026/1744 (Digital Omnibus on AI)
• Future of Privacy Forum: die AI-Act-Zeitleiste nach dem Omnibus (28.07.2026)
• Europäische Kommission: Regulatory framework for AI, mit den geänderten Daten
• AI Act Art. 73: Meldung schwerwiegender Vorfälle
• AI Act Art. 99: Bußgeldrahmen
• Art. 33 DSGVO: Meldung einer Verletzung des Schutzes personenbezogener Daten
• Art. 28 DSGVO: Auftragsverarbeitung und die Pflichtinhalte des AVV
• Bitkom: Digitalisierung der Wirtschaft, 604 Unternehmen, 11.03.2026

Dieser Beitrag ist eine Information und keine Rechtsberatung. Die Fundstellen geben den Stand vom 14. August 2026 wieder, und an mehreren Punkten haben wir markiert, wo die behördliche Praxis fehlt. Die Einstufung eines konkreten Systems und die daraus folgende Pflichtenliste gehören in die Hand einer Kanzlei, die das System kennt.

Wenn Sie jetzt anfangen: unser NIS2-Compliance-Programm deckt die Cybersicherheitsseite ab, die EU-AI-Act-Umsetzung übernimmt Einstufung, Dokumentation und FRIA. Planen Sie beides als ein Projekt, weil Inventar, Risikoregister und Lieferantenpaket in beiden Fällen dieselben sind.