Wenn alle KI nutzen: Was das mit deinem SOC macht

Ein Alert ist kein Angriff

Ich habe in den letzten Monaten öfter in Runden gesessen, in denen jemand stolz verkündete, die KI-Einführung laufe 'reibungslos'. Dann kam die Frage, ob das SOC informiert wurde. Stille. [EIGENE ERFAHRUNG: Kurze Anekdote aus einem Kundenprojekt oder internen Rollout, bei dem das Security-Team erst nachträglich eingebunden wurde und plötzlich mit unbekannten Alert-Mustern konfrontiert war.]

The Hacker News berichtet, dass Unternehmen, die in den letzten zwölf Monaten AI-Tools und AI-Agenten eingeführt haben, einen messbaren Anstieg von Sicherheitsalarmen verzeichnen. Die entscheidende Einschränkung dabei: Diese Alarme stammen nicht aus Angriffen auf die KI-Systeme. Sie sind der normale operative Fußabdruck eines unternehmensweiten AI-Einsatzes.

Was sich im Alert-Profil verschiebt

Ein SOC arbeitet mit Baselines. Es lernt, was im Netz normal ist, und schlägt Alarm, wenn etwas abweicht. Das funktioniert gut, solange sich das Nutzungsverhalten langsam verändert. Ein unternehmensweiter KI-Rollout ist aber kein langsamer Wandel. Er ist ein Sprung.

AI-Agenten stellen API-Calls in einem Volumen und Rhythmus, den kein menschlicher Nutzer erzeugt. Sie greifen auf Datenquellen zu, die vorher kaum berührt wurden. Sie laufen nachts, am Wochenende, ohne Pause. Für ein SIEM, das auf menschliche Nutzungsmuster kalibriert ist, sieht das verdächtig aus — und es ist auch verdächtig, bis das Team entschieden hat, dass es das nicht ist.

Das Problem ist nicht die Technik. Das Problem ist der Prozess: In vielen Unternehmen wird der KI-Rollout vom Fachbereich oder der IT-Abteilung verantwortet, das SOC erfährt davon zu spät oder gar nicht. Die Folge ist ein wachsender Stapel von Alerts, die niemand sauber klassifizieren kann.

Was das für die Governance-Architektur bedeutet

Die Antwort auf dieses Problem ist keine technische. Sie ist organisatorisch. Wer AI-Agenten oder -Tools einführt, muss das SOC in den Rollout-Prozess einbinden — nicht als Nachkontrolle, sondern als Mitgestalter der Baseline.

Konkret heißt das: Vor dem Go-live eines AI-Systems braucht das SOC eine Beschreibung des erwarteten Verhaltens. Welche Endpunkte werden angesprochen? Welche Datenmengen sind normal? Zu welchen Zeiten ist Aktivität zu erwarten? Diese Informationen müssen dokumentiert und ins SIEM überführt werden, bevor der erste produktive Request läuft.

Für DACH-Unternehmen kommt ein weiterer Aspekt hinzu: Die NIS2-Richtlinie, die seit Oktober 2024 in nationales Recht überführt werden musste, verlangt von betroffenen Unternehmen ein nachweisbares Risikomanagement für informationsverarbeitende Systeme. Ein AI-Agent, der unkontrolliert Alerts erzeugt und nicht in die Sicherheitsarchitektur eingebettet ist, ist genau das Szenario, das Aufsichtsbehörden interessiert.

• •

  SOC-Einbindung vor dem Go-live, nicht danach

• •

  Verhaltensbaseline für jeden AI-Agenten dokumentieren

• •

  SIEM-Regeln an neue Aktivitätsmuster anpassen

• •

  Rollout-Prozesse mit NIS2-Anforderungen abgleichen

Das Architekturproblem dahinter

Viele Unternehmen haben KI-Tools zunächst als Einzellösungen eingeführt: ein Copilot hier, ein Summarization-Tool dort. Das ließ sich noch halbwegs überblicken. Jetzt wächst die Zahl der Agenten, und sie interagieren miteinander. Ein Agent ruft einen anderen auf, der wiederum auf eine externe API zugreift. Die Kette wird länger, die Sichtbarkeit schlechter.

Das ist kein Argument gegen Agenten-Architekturen. Es ist ein Argument dafür, sie von Anfang an mit Observability zu bauen. Logging, Tracing und ein klares Identitätsmodell für AI-Agenten — also die Frage, unter welchem technischen Account ein Agent handelt und welche Rechte er hat — sind keine Nice-to-haves. Sie sind die Voraussetzung dafür, dass ein SOC überhaupt sinnvoll arbeiten kann.

Wer heute Agenten ohne Identitätskonzept ausrollt, schafft sich ein Problem, das in sechs Monaten schwer zu lösen sein wird. Dann nämlich, wenn die erste Prüfung kommt und niemand sagen kann, welcher Agent wann auf welche Daten zugegriffen hat.

Was ich daraus mitnehme

Der Bericht von The Hacker News beschreibt ein Phänomen, das ich für strukturell halte: Die Schere zwischen der Geschwindigkeit, mit der Unternehmen KI einführen, und der Geschwindigkeit, mit der ihre Sicherheitsarchitektur nachzieht, wird größer. Das ist kein Vorwurf an die Teams, die KI einführen. Es ist eine Beobachtung über Prozesse, die noch nicht für diese Geschwindigkeit gebaut sind.

Was mich beschäftigt: Viele der Governance-Frameworks, die ich sehe, behandeln KI-Systeme immer noch wie klassische Software. Einmalige Risikobeurteilung, Freigabe, fertig. Agenten, die sich dynamisch verhalten und mit anderen Systemen interagieren, passen in dieses Modell nicht. Wir brauchen kontinuierliche Beurteilung, nicht einmalige. Das ist mehr Arbeit. Aber es ist die ehrliche Antwort auf das, was gerade passiert.

Ich weiß noch nicht, wie das in der Breite skaliert. Das ist die offene Baustelle.

Quellen

Dieser Entwurf wurde KI-gestützt aus folgenden Meldungen erstellt und ist vor der Veröffentlichung redaktionell zu prüfen.

• •

  When the Whole Company Adopts AI: What It Does to Your SOC – The Hacker News (https://thehackernews.com/2026/09/when-whole-company-adopts-ai-what-it.html)