KI-Agenten für Meldepflichten: NIS2, DSGVO, DORA und KRITIS in Falcon
Teil 1: Fünf KI-Agenten in Charlotte AI AgentWorks, die Meldeentwürfe für NIS2, DSGVO, DORA, KRITIS und die Cyber-Versicherung vorbereiten.
Seit Anfang Juni gibt es mit AgentWorks einen Baukasten für eigene KI-Agenten innerhalb von CrowdStrike. Agenten, die selbst Queries absetzen, Ergebnisse bewerten und am Ende einen fertigen Bericht ausgeben.
Inzwischen haben wir über 50 davon gebaut, für ganz unterschiedliche Zwecke. Weil das zu viel für einen Artikel ist, machen wir eine Serie daraus. Teil 1 dreht sich um die Meldepflichten: NIS2, DSGVO, DORA, KRITIS und die Cyber-Versicherung. Danke an dieser Stelle an Julien von Crowdstrike, der bereits Anfang Juni einen NIS2 Agent erstellt und die Inspiration zu dieser Serie gegeben hat.
Der Unterschied zwischen Chatbot und Agent ist im Kern die Handlungsfähigkeit.
Ein Chatbot verfügt über Wissen welches sich mit natürlicher Sprache abfragen lässt. Auf die Frage, welche Hosts betroffen sind, erklärt er den Weg dorthin. Ein Agent hat Werkzeuge. Er setzt die Abfrage selbst ab, liest das Ergebnis und entscheidet daraufhin, ob er noch eine zweite braucht.
Drei Zutaten machen einen Agenten aus:
Der dritte Punkt ist der eigentliche Bruch mit dem, was wir aus Fusion-Workflows kennen. Ein Workflow macht Schritt 1, dann 2, dann 3. Ein Agent probiert Schritt 1, findet nichts, überlegt und probiert etwas anderes. Das ist die Stärke und gleichzeitig der Grund, warum ein Agent klare Grenzen braucht.
Seit Anfang Juni ist AgentWorks in der Falcon Konsole. Seitdem hat CrowdStrike in kurzem Takt nachgelegt: Anfang Juli kamen Action Requests, Agent-Templates und APIs dazu, Ende Juli Playbooks für Malware-Analyse und die Möglichkeit, einen Agenten als Werkzeug innerhalb eines anderen Agenten zu verwenden. Anfang August folgten Skills für zusätzliche Instruktionen an einen Agenten, dazu bessere Kostenaufschlüsselung pro Ausführung.
Die Voraussetzungen sind überschaubar:
Der Baukasten liegt unter Charlotte AI > AgentWorks. Kosten laufen über Charlotte-Credits, verbraucht werden die Credits dann pro Ausführung. Je nach Komplexität der Aufgabe werden mehrere Credits verbraucht.
Meldepflichten haben eine unangenehme Eigenschaft: Sie laufen genau dann, wenn niemand Zeit hat. Während das Team eindämmt und wiederherstellt, tickt im Hintergrund eine Frist, und die Meldung selbst ist oft manuelle Arbeit, bei der sehr genau der Sachverhalt zusammentragen und bewertet werden muss.
Genau diese Fleißarbeit lässt sich vorbereiten. Die fünf Agenten greifen einen Vorfall aus Falcon auf, ziehen die Fakten zusammen und legen einen Entwurf vor. Die Meldung selbst muss natürlich weiterhin manuell abgegeben werden.
Worum es geht: Die EU-Richtlinie NIS2 löst die alte NIS-Richtlinie ab und zieht den Kreis der betroffenen Unternehmen deutlich weiter. Betroffen sind wesentliche und wichtige Einrichtungen aus einer Reihe von Sektoren, in der Regel ab einer Schwelle im Bereich mittlerer Unternehmen. Neu ist neben dem Umfang vor allem die Verantwortung, denn die Geschäftsleitung steht für die Umsetzung gerade.
Die Meldekette: Ein erheblicher Sicherheitsvorfall muss in einem dreistufigen Verfahren gemeldet werden. Eine Frühwarnung innerhalb von 24 Stunden, eine Meldung mit erster Bewertung innerhalb von 72 Stunden, ein Abschlussbericht innerhalb eines Monats. Der Startpunkt ist die Kenntniserlangung, nicht der Angriffsbeginn.
Was der Agent macht: Er nimmt Incident und Kenntniszeitpunkt, holt sich die Fakten aus Incident-Zusammenfassung, Cases, Hosts und LogScale und bewertet die Erheblichkeit anhand der Kriterien: Betriebsstörung, finanzieller Verlust, Schäden bei Dritten. Dann rechnet er die drei Fristen mit Datum und Uhrzeit aus, zeigt an, wie viel Zeit noch bleibt, und liefert den Entwurf, der gerade dran ist. Jede Angabe kommt mit Quellenverweis, alles Unbelegte steht als [AUSFÜLLEN] im Text.
Worum es geht: Artikel 33 DSGVO verlangt bei einer Verletzung des Schutzes personenbezogener Daten eine Meldung an die Aufsichtsbehörde binnen 72 Stunden nach Bekanntwerden. Kommt sie später, muss die Verzögerung begründet werden. Bei hohem Risiko für die Betroffenen kommt nach Artikel 34 deren Benachrichtigung dazu. Anders als NIS2 gilt das unabhängig von Branche und Unternehmensgröße.
Der Denkfehler, den wir oft sehen: Viele prüfen nur, ob Daten abgeflossen sind. Der Schutz umfasst aber auch Integrität und Verfügbarkeit. So sind auch Ransomware-Fälle ohne vorherige Data-Exfiltration potenziell melderelevant.
Was der Agent macht: Er sucht gezielt nach Exfiltrations-Indizien (ungewöhnliche Datenmengen nach außen, Zugriffe auf Dateifreigaben und Postfächer, Archivierungs- und Uploadvorgänge) und ordnet betroffenen Systemen zu, welche Datenkategorien dort liegen könnten. Diese Zuordnung kennzeichnet er ausdrücklich als Annahme, die der Fachbereich bestätigen muss. Dann entwirft er die Meldung entlang der Struktur aus Art. 33 Abs. 3.
Worum es geht: Die EU-Verordnung DORA regelt die digitale operationale Widerstandsfähigkeit im Finanzsektor. Sie gilt für Banken, Versicherer, Wertpapierfirmen, Zahlungsdienstleister und weitere Finanzunternehmen und über Umwege auch für deren IKT-Dienstleister. Bei schwerwiegenden IKT-bezogenen Vorfällen greift eine gestufte Meldepflicht mit Erst-, Zwischen- und Abschlussmeldung.
Die eigentliche Hürde: Nicht die Meldung, sondern die Einstufung. Ob ein Vorfall schwerwiegend ist, entscheidet sich an einem Kriterienkatalog: betroffene Kunden und Transaktionen, Auswirkung auf kritische Funktionen, Dauer und Ausfallzeit, geografische Ausbreitung, Datenverluste, wirtschaftliche Auswirkungen. Diese Bewertung unter Zeitdruck sauber zu dokumentieren, ist der aufwändige Teil.
Was der Agent macht: Er geht die Kriterien einzeln durch und liefert pro Kriterium eine Bewertung mit Begründung und Beleg. Was er nicht aus Falcon ziehen kann z.B. Kundenzahlen, Transaktionsvolumina, Kosten, markiert er als aus dem Fachbereich zu ergänzen, statt zu schätzen. Am Ende steht eine Empfehlung samt der Angabe, welche Kriterien sie tragen. Reicht die Datenlage für ein tragendes Kriterium nicht, sagt er das und eskaliert.
Worum es geht: Betreiber Kritischer Infrastrukturen aus Sektoren wie Energie, Wasser, Ernährung, Gesundheit, Transport, Finanzen und IT melden erhebliche Störungen an das BSI, und zwar unverzüglich. Keine feste Stundenfrist, sondern ohne schuldhaftes Zögern. Ob ein Betrieb unter KRITIS fällt, hängt an Schwellenwerten, die sich am Versorgungsgrad orientieren.
Warum das technisch anders ist: Bei KRITIS hängt die Bewertung an einer Frage, die es bei den anderen Regularien so nicht gibt: Ist nur die Büro-IT betroffen oder die Leit- und Steuerungstechnik? Ein verschlüsselter Dateiserver in der Verwaltung ist etwas anderes als ein kompromittiertes System mit Anlagenbezug. Erschwerend kommt hinzu, dass in OT-Netzen seltener ein Falcon Sensor läuft. Dadurch muss auf andere Telemetrie aus dem SIEM zurückgegriffen werden.
Was der Agent macht: Die Unterscheidung der Netz-Ebenen steckt fest in den Agent-Anweisungen. Er prüft, ob Systeme mit Anlagenbezug betroffen sind, ob es Übergänge zwischen IT und OT gab und ob Fernzugänge im Spiel waren. Findet er Hinweise auf OT-Betroffenheit, urteilt er nicht selbst, sondern eskaliert an einen Menschen. Und wenn die vorhandene Telemetrie für eine Aussage nicht reicht, schreibt er genau das in den Bericht, statt eine Entwarnung zu formulieren, die nicht gedeckt ist.
Worum es geht: Hier steht keine gesetzliche Regulierung dahinter, sondern der Versicherungsvertrag. Cyber-Policen enthalten Obliegenheiten: den Schaden unverzüglich anzeigen, mindern, bei der Aufklärung mitwirken und den Ablauf dokumentieren. Was genau verlangt wird, steht in der jeweiligen Police und unterscheidet sich von Versicherer zu Versicherer.
Das praktische Problem: Dokumentation entsteht im Ernstfall nebenbei oder gar nicht. Wer erst nach der Wiederherstellung versucht eine saubere Timeline zu erstellen, läuft Gefahr, dass ein Teil der Telemetrie aus der Aufbewahrung gelaufen ist. Besonders relevant sind die Abstände: zwischen Erstzugriff und erster Erkennung, zwischen Erkennung und Kenntnisnahme, zwischen Kenntnisnahme und Reaktion.
Was der Agent macht: Er erstellt die Timeline zeitstempelgenau und mit Quellenangabe, trennt dabei die genannten Phasen sauber voneinander und listet betroffene Systeme, Angriffsweg und ergriffene Maßnahmen mit Uhrzeit und ausführender Stelle. Kosten beziffert er nicht. Am wichtigsten ist der letzte Abschnitt: eine Liste dessen, was für die Schadensregulierung üblicherweise verlangt wird und im Bericht noch fehlt.
Keiner der fünf Agenten darf aktiv etwas verändern. Kein Deaktivieren, kein Ändern von Cases, kein automatischer Versand an eine Behörde. Die Agents liefern Entwürfe und Entscheidungsgrundlagen, entscheiden muss ein Mensch.
Eine Meldung an eine Aufsichtsbehörde ist eine rechtsverbindliche Erklärung des Unternehmens. Sie kann nicht zurückgenommen werden, und eine falsche Einstufung hat möglicherweise juristische Folgen.
Genauso wichtig: Alle fünf Agents melden ausdrücklich, wenn sie etwas nicht beurteilen können. So werden auch die Grenzen des Agents transparent und die Gefahr von fehlenden oder halluzinierten Erkenntnissen ist reduziert.
Die Anweisung ist die eigentliche Arbeit. Ein Agent ist so gut wie die Beschreibung dessen, was er tun soll. Wie viel das ausmacht, hat uns ein Agent aus einem anderen Bereich gezeigt: Er sollte nach einem Mitarbeiteraustritt prüfen, ob die Konten wirklich zu sind, und fand mit der exakten Namenssuche nichts. Nach einem einzigen ergänzten Absatz bilde selbst die üblichen Schreibweisen, samt Umlautvarianten — fand derselbe Agent im zweiten Durchlauf ein aktives Azure-Konto mit fünf Anmeldungen nach dem Austrittsdatum. Er war vorher nicht dümmer. Ihm hatte nur niemand gesagt, dass er hartnäckig sein soll.
Lesend zuerst. Die Tools mit Schreibrechten sind in AgentWorks als „Requires human intervention“ markiert, und das ist gut so. Wir bauen Agenten grundsätzlich erst in einer rein lesenden Fassung und ergänzen Aktionen später gezielt, wenn sich das Verhalten über mehrere Läufe als stabil erwiesen hat.
Agenten können Agenten benutzen. Sobald ein Agent gespeichert ist, taucht er in der Werkzeugliste der anderen auf. Damit lässt sich ein Dach-Agent bauen, der bei einem Incident alle Meldepflichten parallel prüft und sagt: hier greift NIS2 und DSGVO, DORA nicht. Steht auf unserer Liste.
Erst speichern, dann testen. Ein Testlauf legt eine Version an, spätere Änderungen bleiben ungespeichert, bis jemand aktiv draufdrückt. Uns hat eine abgelaufene Session eine komplett überarbeitete Anweisung gekostet, die wir dann nochmal tippen durften.
Rechtstexte gehören in die Knowledge Base. Fristen, Schwellenwerte und Meldewege ändern sich, und ein Sprachmodell kennt immer nur einen Stand. Für den Produktivbetrieb hängt man die geltenden Rechtstexte, Schwellenwerttabellen und Behördenformulare als Knowledge Base an den Agenten. Dann zieht er die Details aus der Quelle statt aus dem Modellgedächtnis. Die Beschreibungen in diesem Artikel sind zur Orientierung gedacht und ersetzen keine Prüfung des aktuellen Stands, gerade bei der nationalen Umsetzung von NIS2.
Eine Subscription für Charlotte AI oder Charlotte Agentic SOAR. Manche Subscriptions bringen über Opt-in-Credits einen begrenzten Zugriff mit, für den vollen Funktionsumfang braucht es die Charlotte-AI-Subscription.
Ja. AgentWorks läuft in US-1, US-2 und EU-1. Deutsche Kunden auf der EU-1-Cloud können es also nutzen.
Abgerechnet wird über Charlotte-Credits pro Ausführung. Wie viele Credits ein Lauf verbraucht, hängt davon ab, wie viele Schritte und Werkzeuge der Agent für die Aufgabe braucht. Seit Anfang August zeigt Falcon die Kosten pro Agentenausführung einzeln aus.
Ja, aber nicht unbemerkt. Werkzeuge mit Schreibrechten sind in der Tool-Auswahl als „Requires human intervention“ gekennzeichnet. Wer will, kann Agenten rein lesend bauen, dann erstellen sie nur Berichte und Entwürfe.
Technisch wäre ein automatisierter Versand denkbar. Wir raten davon ab. Eine behördliche Meldung ist eine verbindliche Erklärung des Unternehmens und gehört vor dem Absenden auf den Tisch eines Menschen.
Ein Fusion-Workflow folgt einem festen Ablauf. Ein Agent entscheidet pro Schritt neu, welches Werkzeug er als Nächstes braucht, und kann auf ein leeres Ergebnis mit einem anderen Ansatz reagieren.
Der eigentliche Aufwand liegt nicht im Klicken. Der Baukasten ist an einem Nachmittag verstanden. Er liegt darin, präzise aufzuschreiben, wie man selbst vorgehen würde, und dabei zu merken, an welchen Stellen das noch nie sauber formuliert wurde.
Bei den Meldepflichten war genau das der interessante Teil. Nicht die Frage, ob ein Agent ein Formular ausfüllen kann, sondern die Frage, ab wann ein Vorfall eigentlich erheblich ist und woran man das festmacht. Insofern ist der Agent fast ein Nebenprodukt aus der ohnehin (hoffentlich) dokumentierten Vorgehensweise.
