Ausgangspunkt des Leitfadens ist die Beobachtung, dass viele Anbieter von KI für das SOC überzeugende Demonstrationen zeigen: saubere Warnmeldungen werden in Sekunden in präzise Bewertungen übersetzt. Laut Quelltext lässt die Genauigkeit jedoch häufig nach, sobald diese Werkzeuge die kuratierte Demo-Umgebung verlassen und auf reale Produktionsbedingungen treffen. Zwar berichten einige Teams von messbaren Fortschritten, für viele Organisationen bleibt der Abstand zwischen Proof of Concept und operativer Realität aber groß.
Der Leitfaden empfiehlt daher, schon zu Beginn zu klären, was überhaupt beschafft werden soll: ein Werkzeug, eine Fähigkeit oder eine neue Art, Sicherheitsarbeit zu organisieren. Erst danach lasse sich sinnvoll festlegen, was ein Proof of Concept tatsächlich beweisen soll. Anders als frühere Automatisierung im SecOps-Umfeld, etwa Bayes-Spamfilter oder SOAR, reichen GenAI und große Sprachmodelle laut Quelltext von Detection Engineering über Beweissammlung bis hin zu autonomer Alarm-Triage, Untersuchung und Reaktion.
Zentral ist dabei die Frage, ob eine KI über die tatsächlich relevanten Szenarien und Angriffsflächen eines SOC hinweg verlässliche Bewertungen liefern kann. Der Leitfaden beschreibt dafür eine Schwelle: Unterhalb eines bestimmten Niveaus helfen weder weiteres Feinjustieren noch Prompt-Anpassungen; oberhalb davon werden die Ergebnisse ohne zusätzliche Nacharbeit zuverlässig. Die Daten, die diese Schwelle typischerweise überschreiten helfen, sind laut Quelltext Identitäts-, Asset- und Organisationskontext — also Informationen, mit denen sich ein Angreifer von einem legitimen Administrator unterscheiden lässt.
Das hat unmittelbare Folgen für die Bewertung. Eine Phishing-Warnung lasse sich noch anhand von E-Mail-Metadaten und Reputationsabfragen sortieren. Die Untersuchung von Privilegieneskalation oder lateraler Bewegung erfordere dagegen Identitätsdaten, Asset-Inventare, Verhaltens-Baselines und Organisationsstrukturen. Wenn ein Proof of Concept nur Fälle abdeckt, in denen einfache Erkennung und Telemetrie ausreichen, teste er nach Darstellung des Leitfadens lediglich das leichte Szenario.
Als häufige Ursache schwacher Ergebnisse nennt der Text eine Fehlanpassung zwischen dem Betriebsmodell eines Produkts und dem Team, das es nutzt. Ein Ein-Personen-Betrieb setze auf KI, um Arbeiten zu übernehmen, die sonst niemand leisten kann; bei größeren Teams gehe es eher darum, menschliche Analysten wirksamer zu machen. Als besonders aufschlussreich beschreiben die Autoren einen Gleichlauf-Test zwischen Mensch und KI: Das System soll einige Wochen parallel zu Analysten laufen, es sollen Baselines vor der Einführung erfasst werden, und Korrekturen durch Analysten sollen nicht als Störgeräusch, sondern als zentrale Messgröße gelten.
Ein Warnsignal ist laut Leitfaden, wenn Analysten am Ende nur noch die Schlussfolgerungen der KI abnicken, statt unabhängig zu eigenen Bewertungen zu kommen. Dahinter steht das Risiko, dass KI-Plattformen schon weit vor der eigentlichen Analyse Entscheidungen treffen: was aufgenommen, unterdrückt oder priorisiert wird, welcher Kontext zusammengetragen wird und wie eine Untersuchung gerahmt ist. Je weiter vorgelagert eine solche Entscheidung ist, desto weniger sichtbar und desto schwerer rückgängig zu machen ist sie.
Darum betont der Leitfaden Erklärbarkeit und Untersuchungstiefe. Analysten könnten Bewertungen nur dann vertrauen und sie prüfen, wenn sie die zugrunde liegende Argumentation sehen. Ebenso wichtig sei Belastbarkeit über die Anfangsphase hinaus: Der Text nennt als Bereiche für Belastungstests die Robustheit gegen gegnerische Einwirkungen, Modelldrift und Qualitätsabfall, Anpassungsfähigkeit bei veränderten Umgebungen sowie Lock-in.
Im Produktionseinsatz sehen die Autoren zudem spürbare Veränderungen bei Rollen und Arbeitsumfang. Ein im Quelltext genannter Enterprise-CISO berichtete, dass Aufgaben rund um Phishing-Triage und DMARC-Prüfung innerhalb weniger Wochen automatisiert wurden, bevor das Team neue Aufgaben für diese Analysten festgelegt hatte. Neue Rollen wie Detection Engineering, Threat Hunting, Red Teaming und KI-Aufsicht sollten deshalb vor der Einführung geplant werden. Die größten Zugewinne kamen demnach nicht aus schnellerer Bearbeitung bestehender Warnmeldungen, sondern aus Untersuchungen, die Analysten zuvor gar nicht verfolgt hätten.
Der Leitfaden nennt auch ein Beispiel: Ein Team reaktivierte zuvor verworfene Erkennungsregeln und korrelierte HR-Daten, Authentifizierungsprotokolle und Asset-Datensätze über mehrere Standorte hinweg, um geteilte Zugangsdaten zu erkennen. Zudem wird eine Drei-Zustands-Klassifikation empfohlen — unbedenklich, verdächtig und bösartig. Ein System, das nie „ich weiß es nicht“ sagt und immer nur binäre Urteile ausgibt, verberge Unsicherheit eher, als sie aufzulösen.
Als roter Faden gilt ein hybrides Modell aus Mensch und KI: probabilistische KI für Triage und Untersuchung, deterministische Schutzmechanismen und Menschen für Eindämmung, Eskalation und irreversible Maßnahmen. Prophet Security beschreibt seine eigene Plattform im Quelltext genau entlang dieser Prinzipien: Jede Bewertung zeige die von der KI ausgeführten Abfragen und die berücksichtigten Belege, während Menschen bei folgenreichen Schritten die Kontrolle behalten.