KI im SOC: Nutzen und Grenzen ohne Hype

KI im SOC ist das Thema mit dem größten Abstand zwischen Marketing und Alltag. Die einen versprechen das autonome SOC, das sich selbst verteidigt; die anderen winken ab, weil sie ein Modell einmal beim Halluzinieren erwischt haben. Beide liegen daneben. Große Sprachmodelle sind im SOC weder die Lösung noch nutzlos, sondern ein Werkzeug mit klar umrissenen Stärken und ebenso klaren Grenzen. Dieser Beitrag ordnet ein, wofür KI im SOC 2026 tatsächlich taugt, wo sie versagt, warum der Datenschutz die entscheidende Hürde ist und wie ein Blue Team sie nützlich einsetzt, ohne die Verantwortung abzugeben. Er beschreibt Prinzipien, keine Produkte, weil sich die Werkzeuge schnell ändern und die Prinzipien nicht.

Wofür KI im SOC taugt

Die Stärke der Sprachmodelle liegt bei Sprache, und ein überraschend großer Teil der SOC-Arbeit ist Sprache: erklären, zusammenfassen, formulieren, übersetzen.

• Alarme erklären. Ein kryptischer Alarm mit rohen Feldwerten wird in einen Satz übersetzt, der sagt, was passiert sein könnte. Gerade für Analysten in der ersten Linie senkt das die Hürde, einen unbekannten Alarmtyp einzuordnen.
• Kontext zusammentragen. Ein Modell kann die Informationen zu einem Alarm bündeln: Was ist dieses Konto, dieses System, diese Technik nach ATT&CK, welche verwandten Ereignisse gibt es. Das spart das Zusammensuchen aus mehreren Konsolen.
• Abfragen formulieren. Aus „zeig mir alle Anmeldungen dieses Kontos der letzten 24 Stunden nach Land“ wird eine SIEM-Abfrage. Das Modell kann die Syntax, der Analyst prüft das Ergebnis. Besonders nützlich für Analysten, die die Abfragesprache nicht täglich schreiben.
• Berichte entwerfen. Der erste Entwurf eines Vorfallberichts, einer Kurzfassung für die Leitung oder eines Eintrags für den Post-Incident-Review aus den vorhandenen Notizen. Der Mensch redigiert, aber die leere Seite ist gefüllt.
• Wiederkehrende Triage vorbereiten. Für häufige, klar umrissene Alarmtypen kann ein Modell die immer gleichen ersten Schritte vorbereiten und eine Vorbewertung liefern, die der Analyst bestätigt oder verwirft. Das ist die Automatisierung der Fleißarbeit, nicht der Entscheidung.
• Lernen und Nachschlagen. Ein Modell erklärt eine unbekannte Technik, ein Protokoll, einen Feldwert, ohne dass man die Dokumentation durchsucht. Für die Weiterbildung im Team ist das ein ständiger Nachhilfelehrer, dessen Antworten man allerdings prüfen muss.

Der gemeinsame Nenner: KI entlastet bei der Fleißarbeit rund um die Entscheidung, damit der Analyst mehr Zeit für die Entscheidung selbst hat. Das wirkt direkt gegen die Alert Fatigue, weil es die Bearbeitung pro Alarm verkürzt.

Wo KI versagt

• Halluzination unter Druck. Ein Sprachmodell erzeugt plausibel klingende Antworten, auch wenn es die Antwort nicht weiß. Im SOC ist das gefährlich, weil eine falsche, aber überzeugend formulierte Einordnung einen Analysten in die falsche Richtung schickt. Jede Ausgabe ist ein Vorschlag, kein Befund.
• Kein Urteil. Ob ein Alarm in dieser konkreten Umgebung ein Problem ist, hängt vom Kontext ab, den nur das Team kennt: Was ist hier normal, welche Ausnahmen gibt es, was ist gerade im Gange. Dieses Urteil kann ein Modell nicht ersetzen, es kann es nur mit Information füttern.
• Keine autonome Reaktion. Ein Modell darf nicht selbstständig Konten sperren, Systeme isolieren oder Vorfälle schließen. Die Reaktion hat Konsequenzen für den Betrieb, und die Verantwortung dafür braucht einen Menschen mit Mandat. KI schlägt vor, der Mensch entscheidet und handelt.
• Angreifbar. Ein Modell, das Alarmtexte oder Logdaten verarbeitet, kann durch manipulierte Inhalte in diesen Daten in die Irre geführt werden (Prompt Injection). Wer KI in die Verarbeitungskette einbaut, muss diese Angriffsfläche bedenken.
• Verlernt nichts, aber lernt auch nichts dazu. Ein Basismodell kennt die eigene Umgebung nicht. Ohne Anbindung an den eigenen Kontext bleibt seine Einordnung allgemein, und diese Anbindung ist genau der Teil, der Datenschutzfragen aufwirft.

Die Datenschutzhürde

Der Nutzen von KI im SOC steigt, je mehr eigene Daten das Modell sieht, und genau hier liegt das Problem. Log- und Vorfalldaten enthalten personenbezogene und vertrauliche Informationen: Benutzernamen, IP-Adressen, Dateinamen, interne Systeme. Diese Daten ungeprüft in ein externes Modell zu geben, ist datenschutzrechtlich heikel und je nach Vertrag mit dem Anbieter unzulässig. Drei Wege, damit umzugehen, mit steigendem Aufwand und steigender Kontrolle. Erstens: nur allgemeine Fragen an externe Modelle, ohne eigene Daten, also das Modell als Nachschlagewerk statt als Analyst. Zweitens: ein Modell mit vertraglich zugesichertem Datenschutz und ohne Training auf den Eingaben, sodass Vorfalldaten den zulässigen Rahmen nicht verlassen. Drittens: ein lokal betriebenes Modell, das die Daten nie verlassen, mit dem Preis von Betriebsaufwand und geringerer Leistung. Welcher Weg passt, entscheidet die Sensibilität der Daten und die Regulierung; für Organisationen unter strengen Vorgaben ist der lokale Betrieb oft die einzige zulässige Option. In jedem Fall gehört der KI-Einsatz mit der eigenen Datenschutzstelle abgestimmt, bevor das erste Log in ein Modell fließt.

Wie ein Blue Team KI einführt

1. Bei der Fleißarbeit anfangen. Erklären, zusammenfassen, Abfragen entwerfen, Berichte vorformulieren: die Anwendungen ohne Entscheidungsgewalt und mit geringem Datenschutzrisiko. Hier ist der Nutzen sofort da und das Risiko klein.
2. Den Menschen in der Schleife lassen. Jede KI-Ausgabe wird von einem Analysten geprüft, bevor sie zu einer Handlung führt. Das gilt besonders für Abfragen und Vorbewertungen, die falsch sein können, ohne dass es auffällt.
3. Datenschutz zuerst klären. Bevor eigene Daten in ein Modell gehen, ist der Weg mit der Datenschutzstelle abgestimmt und der Anbietervertrag geprüft. Das ist kein Formalismus, sondern die Voraussetzung für den nächsten Schritt.
4. Ergebnisse messen. Wird die Bearbeitung pro Alarm kürzer, ohne dass die Fehlerrate steigt? Wenn KI die Arbeit nicht messbar entlastet, sondern nur eine weitere zu prüfende Quelle schafft, ist der Einsatz falsch gewählt.
5. Klein halten, was Konsequenzen hat. Automatisierung von Reaktionen kommt zuletzt und nur für eng umrissene, gut verstandene Fälle, mit klaren Grenzen und immer der Möglichkeit, sie zu überstimmen. Die Entscheidung über einen Vorfall bleibt beim Menschen, wie im Incident-Response-Prozess beschrieben.

Die andere Seite: KI beim Angreifer

KI verändert nicht nur die Verteidigung, sondern auch den Angriff. Phishing-Mails werden sprachlich fehlerfrei und individuell, Deepfake-Stimmen senken die Hürde für Betrug, und Angreifer nutzen Modelle, um Code und Kampagnen schneller zu bauen. Das ändert nichts an den Grundlagen der Verteidigung, verschiebt aber Gewichte: Awareness, die auf schlechte Grammatik als Warnsignal setzt, ist überholt, und die prozessuale Zweitverifikation wird wichtiger. Die Verteidigung mit KI ist damit auch eine Antwort auf den Angriff mit KI, aber keine, die das Wettrüsten gewinnt; sie hält mit.

Fazit

KI im SOC ist 2026 ein nützliches Werkzeug und keine Revolution: Sie entlastet bei der Sprach- und Fleißarbeit rund um die Entscheidung, sie erklärt, fasst zusammen und formuliert, und sie tut das gut genug, um Analysten Zeit zurückzugeben. Sie ersetzt nicht das Urteil, halluziniert unter Druck und darf nicht autonom über Vorfälle entscheiden, und der Datenschutz setzt der Anbindung an die eigenen Daten enge Grenzen. Ein Blue Team, das KI bei der Fleißarbeit einsetzt, den Menschen in der Schleife lässt und den Datenschutz zuerst klärt, gewinnt Zeit, ohne Kontrolle abzugeben. Wer sie als autonomen Verteidiger verkauft bekommt, sollte skeptisch sein, denn die Verantwortung für einen Vorfall lässt sich nicht an ein Modell delegieren.