Kurzfassung: NIS2-fähiger KI-Betrieb entsteht nicht dadurch, dass ein KI-Assistent in SOC, NOC oder IT-Betrieb integriert wird. Entscheidend ist ein Betriebsmodell, das automatisch belastbare Nachweise erzeugt: Jede KI-Empfehlung muss auf Telemetriedaten zurückführbar sein, jede Lieferantenaktion braucht begrenzte Berechtigungen, und jede Netzwerkänderung muss über einen nachvollziehbaren Freigabepfad laufen.
Dieser Beitrag ist technische Umsetzungsorientierung und keine Rechtsberatung. Ob Ihr Unternehmen als wesentliche oder wichtige Einrichtung betroffen ist und welche nationale Umsetzung im Einzelfall gilt, sollte qualifiziert juristisch geprüft werden. Der technische Punkt ist enger: Wenn Sie KI im Betrieb einsetzen, muss das System Risikomanagement, Incident-Nachweise, Lieferantensteuerung und Management-Verantwortung besser belegbar machen – nicht intransparenter.
Warum NIS2 die Architektur für KI-Betrieb verändert
Die Europäische Kommission beschreibt NIS2 als einheitlichen Rechtsrahmen für Cybersicherheit in 18 kritischen Sektoren. Die Richtlinie bringt Anforderungen an Risikomanagement, Meldepflichten, Lieferkettensicherheit, Aufsicht und Verantwortung der Geschäftsleitung. Für Engineering-Teams bedeutet das: KI-gestützter Betrieb darf nicht als informeller Chat-Prozess organisiert sein, sondern muss auditierbare Workflows erzeugen.
Das typische Risiko ist praktisch: Ein KI-Agent fasst Alarme zusammen, empfiehlt eine Firewall-Regel, öffnet ein Lieferantenticket oder formuliert einen Incident-Bericht. Die Empfehlung kann technisch sinnvoll sein. Problematisch wird es, wenn später nicht belegbar ist, welche Daten verwendet wurden, wer die Maßnahme freigegeben hat, ob Lieferantenzugriff erforderlich war und wie die Entscheidung zur Incident-Zeitachse passt.
Referenzarchitektur: erst Nachweise, dann Automatisierung
Ein praktikabler NIS2-fähiger KI-Betrieb besteht aus fünf Schichten. Erstens: unveränderbare Telemetrie aus SIEM, EDR, Netzwerkgeräten, Identity-Systemen, Ticketing und Cloud-Kontrollflächen. Zweitens: ein Incident-Arbeitsraum mit Asset-Kritikalität, Lieferantenbezug, betroffenem Geschäftsprozess und Schweregrad. Drittens: KI für Klassifikation, Zusammenfassung, Korrelation und Empfehlungen – aber mit Quellenverweisen und Schwellenwerten. Viertens: Human-in-the-Loop-Freigaben für riskante Aktionen. Fünftens: ein Evidence Pack mit Zeitachse, Datenquellen, Modellausgaben, Freigaben, Änderungen, Lieferantenkontakten und Nachmaßnahmen.
Der Grundsatz: Die KI-Schicht darf nie der einzige Ort sein, an dem Incident-Wissen existiert. Sie darf Triage und Dokumentation beschleunigen. Der verbindliche Nachweis gehört jedoch in Systeme, die Security, Betrieb, Compliance und Geschäftsleitung prüfen können.
Kontrollmatrix für NIS2-fähigen KI-Betrieb
| Bereich | Was die KI tun darf | Erforderliche Kontrolle | Aufzubewahrender Nachweis |
|---|---|---|---|
| Incident-Triage | Alarme clustern, Auswirkungen zusammenfassen, Schweregrad begründen | Quellenereignisse zitieren, Prompts und Ausgaben speichern, Analystenentscheidung dokumentieren | Zeitachse, Alert-IDs, betroffene Assets, Entscheidung |
| Netzwerkkontrollen | Segmentierung, Firewall-, Identity- oder Rate-Limit-Änderungen vorschlagen | Menschliche Freigabe vor Produktionsänderung, Rollback-Plan, Änderungsfenster | Change Request, Freigabe, Diff, Deployment-Ergebnis, Rollback-Nachweis |
| Lieferantensteuerung | Zuständigen Lieferanten identifizieren, Tickettext vorbereiten | Vertragsgebundener Zugriff, Least Privilege, benannter Kontakt, Scope-Begrenzung | Lieferantenticket, Zugriffsfreigabe, Ablaufdatum, ausgeführte Maßnahmen |
| Reporting-Unterstützung | Management- und Behördenzusammenfassungen entwerfen | Rechts-/Compliance-Prüfung vor externer Meldung | Entwurfsversionen, Reviewer-Kommentare, Übermittlungszeitpunkt |
| Nachbereitung | Lessons Learned und Kontrollverbesserungen generieren | Verantwortliche und Fristen im Backlog | Maßnahmenliste, Kontrolltest, Management-Freigabe |
Incident Evidence: Der Audit Trail sollte langweilig sein
Das Evidence Pack sollte laufend entstehen und nicht erst unter Zeitdruck nach dem Vorfall zusammengesucht werden. Mindestens erforderlich sind Incident-ID, Startzeit, Erkennungsquelle, Änderungen des Schweregrads, betroffene Assets, angenommene Geschäftsauswirkung, KI-Empfehlungen, menschliche Entscheidungen, ausgeführte Maßnahmen, Lieferanteninteraktionen und Remediation-Status.
Für KI-Ausgaben sollten Sie Prompt-Template-Version, Modell oder Anbieter, Retrieval-Kontext oder zitierte Event-IDs, Ausgabetext, Confidence- oder Evaluationswert, freigebende Person und Ablehnungsgrund speichern. Das ist keine Bürokratie um ihrer selbst willen. Es trennt „die KI hat das gesagt“ von „eine verantwortliche Person hat eine belegte Empfehlung auf Basis dieser Telemetrie freigegeben“.
Lieferantenrisiko: KI macht Drittparteien-Grenzen sichtbar
NIS2 betont Lieferketten- und Lieferantensicherheit. Im KI-Betrieb entsteht Lieferantenrisiko an zwei Stellen: externe Anbieter erhalten Incident-Daten, oder Lieferanten sind Teil des Remediation-Pfads. Beide Fälle brauchen technische Begrenzungen.
Nutzen Sie kurzlebige Zugriffe, eng definierte Rollen, ticketgebundene Freigaben, Redaction für nicht erforderliche Personen- oder Kundendaten und automatische Ablauffristen. Wenn ein KI-Agent Lieferantentickets formuliert, kann er klassifizieren, welche Informationen relevant sind. Die Freigabe sensibler Informationen sollte jedoch menschlich erfolgen. Lieferantenportale und Managed-Service-Accounts gehören als eigene Akteure in die Incident-Zeitachse, nicht in informelle Nebenkanäle.
Netzwerkkontrollen: Der Agent darf nicht zum Change-System werden
Netzwerkänderungen sind der Punkt, an dem KI-Betrieb von nützlich zu gefährlich wechseln kann. Lassen Sie den Agenten Blast Radius analysieren, vorgeschlagene Regeln gegen Policies prüfen, fehlende Segmentierung erkennen und Rollback-Schritte entwerfen. Erlauben Sie keine unbeaufsichtigten Produktionsänderungen, solange eine Maßnahme nicht risikoarm, vorab genehmigt, reversibel und überwacht ist. Die meisten deutschen B2B-Umgebungen sollten mit Lesezugriff, Empfehlungen und Ticket-Erstellung starten.
Ein belastbares Muster lautet: empfehlen, simulieren, freigeben, ausführen, verifizieren. Der Agent empfiehlt eine Kontrolle, das System simuliert oder prüft Policy-Auswirkungen, eine verantwortliche Person gibt frei, vorhandene Automatisierung setzt über den etablierten Change-Pfad um, und eine Verifikation bestätigt die Wirkung ohne unerwartete Nebeneffekte.
Umsetzungscheckliste
1. Klären Sie, ob KI-Betrieb NIS2-relevante Prozesse, Lieferanten oder kritische Services berührt. Trennen Sie juristische Betroffenheitsprüfung von technischer Bereitschaft.
2. Definieren Sie, welche KI-Aktionen nur lesend, nur als Entwurf, freigabepflichtig oder verboten sind. Dokumentieren Sie das als Betriebsregel, nicht nur im Code.
3. Bauen Sie das Incident-Evidence-Schema vor autonomer Remediation. Wenn das Nachweismodell schwach ist, verstärkt Automatisierung die Unklarheit.
4. Verknüpfen Sie Lieferantenzugriffe mit Ticket-IDs, Ablaufdatum, Least Privilege und benannter Verantwortung. Vermeiden Sie geteilte Notfallkonten.
5. Legen Sie Netzwerkänderungen hinter Simulation, Peer Review, Rollback und Post-Change-Verifikation.
6. Testen Sie das System mit Tabletop-Übungen: übersehener Alarm, False Positive, Lieferantenausfall, Identity-Kompromittierung und fehlgeschlagener Rollback.
Wo Automatisierung sofort hilft
Die wertvollsten Startfälle sind keine autonomen Reparaturen. Sie liegen in Evidence Collation, Alert Clustering, Impact-Zusammenfassungen, Lieferantenticket-Entwürfen, Duplikaterkennung und managementfähigen Lagebildern. Das reduziert manuelle Arbeit, ohne Verantwortung zu verwischen.
Mehr Autonomie kann folgen, wenn Telemetrie verlässlich ist, Freigabeklassen dokumentiert sind, Rollback-Pfade deterministisch funktionieren und False-Positive-Raten gemessen werden. Ohne diese Grundlagen wird KI zwar schneller, aber weniger verteidigungsfähig.
Quellen
Europäische Kommission, NIS2 Directive overview: NIS2 als Cybersicherheitsrahmen für 18 kritische Sektoren mit Risikomanagement, Meldepflichten, Lieferkettensicherheit, Aufsicht und Management-Verantwortung. https://digital-strategy.ec.europa.eu/en/policies/nis2-directive
Richtlinie (EU) 2022/2555: Primärtext zu Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union. https://eur-lex.europa.eu/eli/dir/2022/2555
BSI-Informationen für NIS2-regulierte Unternehmen: Registrierung, Projekt-Roadmap und deutscher Umsetzungskontext. https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html
Wie ich helfe
Wenn Sie KI in Security-, Netzwerk- oder Industrieprozesse einführen, unterstütze ich beim Aufbau der Kontrollarchitektur: Telemetriemodell, Freigabepfade, Lieferantengrenzen, Evidence Packs und realistische Automatisierungsstufen. Ziel ist keine Agenten-Demo, sondern ein KI-Betriebssystem, das in Incidents, Audits und Management-Reviews belastbar bleibt.
