Die sechs Säulen der KI-bereiten Telemetrie

„KI-bereit“ ist überall gerade im Trend und wird fast jedem Produkt in jeder Kategorie angehängt. Das eingängige Label bedeutet selten etwas Konkretes, genauso wie zusätzliche Fragen berechtigt sind, wenn Anbieter behaupten, „KI-nativ“ zu sein. Nach dem Durchkämpfen durch all das Marketing-Jargon braucht es einen Standard, keine Werbeaussage. Und die Definition ändert sich je nachdem, wofür die Daten verwendet werden. KI-bereit für ein Data Warehouse und KI-bereit für Live-Operationstelemetrie sind nicht dasselbe Problem.

Telemetriedaten haben enormes ungenutztes Potenzial, und jeder Anbieter, der KI-Sicherheit verkauft, führt mit derselben Aussage an: Unser Modell ist intelligenter. Aber ein intelligenteres Modell, das ungeordnete Daten liest, halluziniert an einem schlechten Tag einfach schneller. An einem guten Tag verbraucht es massive Mengen an Tokens und fügt unstrukturierten Daten Struktur hinzu. Die eigentliche Frage ist nicht, wie intelligent Ihr Agent ist. Es ist, ob Ihre Telemetrie überhaupt dafür konzipiert wurde, dass ein Agent sie von Anfang an verarbeitet.

Was macht Telemetrie KI-bereit?

KI-bereite Telemetrie wird nicht durch eine einzelne Eigenschaft definiert. Es sind sechs Dimensionen, die aufeinander aufbauen und zusammen definieren, ob ein Telemetrie-Data-Lake für die agentischen Workflows bereit ist, die bereits ankommen. Nicht eine Funktion, die auf Ihren Security- und Observability-Stack aufgesetzt wird, sondern ein Standard für die Daten darunter. Wir glauben, dass diese sechs Eigenschaften KI-bereite Telemetrie definieren:

1. Einheitlich: Daten befinden sich in einer durchsuchbaren Ebene.
2. Normalisiert: Daten haben eine konsistente Struktur und Bedeutung.
3. Korreliert/kontextualisiert: Signale sind miteinander verbunden und mit dem Wissen angereichert, das nötig ist, um sie zu verstehen.
4. Aktuell: Daten sind verfügbar, wenn Sie sie brauchen, über aktuelle und historische Zeiträume hinweg.
5. Untersuchbar: Die Plattform kann Daten in nützliche Antworten umwandeln, nicht nur Rohergebnisse zurückgeben.
6. Rechenschaftspflichtig: KI-Überlegungen und Aktionen können nachvollzogen, gesteuert und im Nachhinein nachverfolgt werden.

Die Herausforderung wird verstärkt, weil Operationstelemetrie nicht stillsteht. Metriken, Ereignisse, Logs und Traces – manchmal auch als MELT-Daten bezeichnet – werden kontinuierlich von Systemen generiert, die keine Ahnung haben, dass ein KI-Agent sie später möglicherweise liest, in Mengen und Formaten, die niemand für die maschinelle Verarbeitung konzipiert hat. Und zunehmend ist die KI, die diese Daten liest, nicht dabei, eine Tatsache für einen Chatbot abzurufen. Sie diagnostiziert einen Live-Incident, untersucht eine aktive Bedrohung und nimmt in einer wachsenden Zahl von Bereitstellungen Maßnahmen mit echten Konsequenzen.

So sieht jede Funktion in der Praxis aus.

Einheitlich: Eine Ebene, um sie alle zu beherrschen

Die erste Anforderung ist die grundlegendste und die am häufigsten nicht erfüllte: Logs, Metriken, Traces und Sicherheitsereignisse müssen in einer einzigen, durchsuchbaren Ebene leben, nicht in vier separaten Tools, die jemand oder ein Agent manuell abgleichen muss. Selbst mit den Fortschritten der Federated Search, robusten APIs und MCP-fähigen Workflows ist es nicht ideal, kritische Daten in verschiedenen Formaten über Silos verteilt zu lassen. Wenn Sie darauf vertrauen müssen, dass der Agent die Datenbits zusammensetzt, die er zur Problemlösung benötigt, verschwindet das Risiko, dass er das falsch macht, nicht. Es wird nur schwerer zu erkennen.

Stellen Sie sich einen On-Call-Ingenieur eines mittelgroßen Fintech-Unternehmens während eines Incidents vor. Die Fehlerquote-Metrik ist in einem Dashboard, die Logs sind in einem zweiten Tool, die Trace-Daten befinden sich in einem dritten, und die Sicherheitsereignisse sitzen in einem vierten System ganz woanders. Niemand ist schuld in diesem Szenario. Jedes Tool kann bei seiner Aufgabe perfekt sein. Aber während eines Incidents wird die Aufgabe des Ingenieurs zum Tab-Wechsel und mentaler Übersetzung, nicht zur Untersuchung.

Ein KI-Agent, der mit derselben Fragmentierung konfrontiert ist, wird nicht magisch intelligenter als dieser Ingenieur. Er scheitert einfach schneller, weil er die Teile des Bildes nicht sehen kann, die in Systemen leben, auf die er nicht zugreifen kann.

Das Open Cybersecurity Schema Framework und Dienste wie AWS Security Lake existieren genau deshalb, weil die Branche erkannt hat, dass Security- und Operationsdaten, die über Dutzende von Anbietern verteilt sind, unverwaltbar werden. Jetzt integrieren sich bereits mehr als 50 Anbieter nur mit Security Lake, jeder trägt ein weiteres Format bei, das abgestimmt werden muss. Der Instinkt zur Vereinheitlichung ist jetzt branchenweit, nicht nur eine Meinung von Sumo Logic. Im Zeitalter des Betriebs mit Maschinengeschwindigkeit und Maschinenumfang ist es nicht verhandelbar.

Einheitlich bedeutet nicht ein Anbieter für alles. Es bedeutet einen Ort, an dem die Frage „Was ist passiert?“ über alles hinweg auf einmal gestellt werden kann. Und wenn dieser einheitliche Data Lake auch ein einheitliches Entity-Modell und ein einheitliches institutionelles Gedächtnis hat, haben Agenten nicht nur die Daten. Sie haben den Kontext, der erforderlich ist, um verantwortungsvoll zu argumentieren.

Normalisiert: Struktur wird automatisch angewendet, nicht manuell

Wir haben dies oben erwähnt, aber es verdient seine eigene Säule. Alles an einen Ort zu bringen, löst die Hälfte des Problems. Die andere Hälfte ist, dass Rohtelemetrie ein Durcheinander inkonsistenter Formate ist.

Jede Anwendung, jedes Team, jede Ära der Infrastruktur schreibt Logs leicht unterschiedlich, ohne durchgesetztes Schema. Dieses Problem ist nicht neu. Wie der berühmte XKCD-Comic festgehalten hat, bekommt jedes Mal, wenn jemand merkt, dass es konkurrierende Standards gibt, die brillante Idee, noch einen weiteren Standard hinzuzufügen. Optimistisch gesehen könnten wir mit OCSF und ECS und breiter Branchenunterstützung endlich die Normalisierungsschlacht gewinnen … und sogar den Krieg.

Genau genommen hat die Pipeline drei unterschiedliche Schritte. Normalisierung bedeutet, dass die Struktur automatisch bei der Erfassung angewendet wird – vom Parsing über die Feldextraktion bis zur Schema-Zuordnung – anstatt dass jedes Mal ein maßgeschneidertes Integrationsprojekt erforderlich ist, wenn eine neue Datenquelle auftaucht. Paradoxerweise ist dies für KI wichtiger als für Menschen: Eine Person kann eine leicht fehlgeformte Protokollzeile überfliegen und verstehen, was sie bedeutet. Ein Modell, das über dieselben Daten nachdenkt, benötigt eine konsistente Struktur, um zuverlässig zu argumentieren, sonst ist es nur Mustererkennung gegen Rauschen. Und selbst wenn es sich durcharbeiten kann, kostet es unnötige Token-Verbrennung, um dorthin zu gelangen.

Normalisierung ist kein Datenhygiene-Projekt. Das Bereinigen Ihrer Daten ist wie das Korrekturlesen eines Dokuments auf Tippfehler. Parsing und Normalisierung sind das Übersetzen von Dokumenten, die in fünf verschiedenen Sprachen geschrieben sind, in eine gemeinsame Sprache. Wenn sich Feldnamen zwischen Quellen unterscheiden, hat ein KI-Agent keine zuverlässige Möglichkeit, den Akteur vom Ziel zu unterscheiden.

Ein Firewall-Protokoll speichert Quell- und Ziel-IPs in verschiedenen Feldern, manchmal ohne Beschriftung. Das Cloud-Audit-Protokoll nennt die Person, die die Aktion ausgeführt hat, userIdentity.arn; das Endpoint-Protokoll nennt sie TargetUserName. Ohne ein normalisiertes Schema kann ein Agent, der eine Lateral-Movement-Warnung untersucht, Angreifer und Opfer verwechseln, den falschen Benutzer mit dem falschen Asset korrelieren oder das Ziel als Quelle des Kompromisses kennzeichnen.

Das Hauptproblem hier ist, dass es den Fehler nicht korrigiert. Es wird ihn mit vollständiger Sicherheit präsentieren, und der Analyst wird danach handeln. Multiplizieren Sie das jetzt über jede Protokollquelle, in der „wer hat was wem angetan“ anders ausgedrückt wird, und Sie haben eine Plattform, auf der KI Untersuchungen nicht beschleunigt. Sie produziert plausible, gut formatierte falsche Antworten mit Maschinengeschwindigkeit. Normalisierung bedeutet, dass jede Quelle einem Schema zugeordnet wird, bevor ein Agent sie berührt, sodass „src“ immer Quelle bedeutet, „dst“ immer Ziel bedeutet und Akteur immer die Entität bedeutet, die die Aktion eingeleitet hat, unabhängig davon, von welchem Anbieter das Protokoll stammt.

Korreliert und kontextualisiert: Signale, die über Typ und System hinweg verknüpft sind

Einheitliche und normalisierte Daten geben einem KI-Agenten Zugriff auf die Teile. Die nächste Herausforderung besteht darin, ihm zu helfen, zu verstehen, wie diese Teile zusammenpassen. Dies erfordert sowohl Korrelation als auch Kontext.

Korrelation verbindet Signale, die eine kausale Beziehung über Ihre Telemetrie hinweg teilen. Eine Trace-ID verknüpft sich mit den Protokollzeilen, die sie generiert hat, die sich mit der Metrik-Anomalie verknüpfen, die sie erklärt. Ein Ermittler, Mensch oder KI, kann die Kette vom Symptom zur Grundursache nachvollziehen, anstatt sie von Hand zusammenzusetzen. Korrelation beantwortet die Frage: Was ist passiert und was hat es verursacht? Alles, was es braucht, existiert bereits irgendwo im Datenstrom. Das Problem besteht darin, die Teile zu finden und zu verknüpfen.

Kontext ist das Wissen, das im Datenstrom überhaupt nicht existiert. Es ist die Tatsache, dass dieser Server der Laptop des CFO ist. Dass ein IP-Bereich einem Auftragnehmer gehört, der letzten Freitag offboarded wurde. Dass sich ein Service gerade migriert und das Team bis Donnerstag mit erhöhten Fehlerquoten rechnet. Dass ein Warnmuster im letzten Quartal zweimal untersucht und beide Male als bekannter Fehlalarm geschlossen wurde.

In der alten Welt lebte dieses Wissen im Kopf eines Analysten, in einem Slack-Thread, auf einer Wiki-Seite, die niemand aktualisiert hat, oder in einem Flurgespräch zwischen zwei Ingenieuren, die zufällig zur gleichen Zeit Kaffee trinken gingen. Es war real, es war kritisch, und es war für jedes automatisierte System im Gebäude völlig unsichtbar.

Die Unterscheidung ist erwähnenswert, weil ein KI-Agent, der einer Trace-Spanne zum Protokollfehler folgen kann, der sie verursacht hat, aber nicht weiß, dass der betroffene Service sich in einem geplanten Wartungsfenster befindet, die Untersuchung nicht gelöst hat. Er hat eine technisch korrekte, operativ nutzlose Warnung produziert. Ein Agent benötigt beides, was bedeutet, dass die Plattform beides bereitstellen muss: kausale Verknüpfungen über Telemetrie hinweg für Korrelation und organisatorisches Wissen wie Asset-Eigentümerschaft, geschäftliche Kritikalität, Änderungspläne, historische Untersuchungsergebnisse und Threat-Intel-Anreicherungen, kodiert in einer Struktur, die der Agent abfragen kann, nicht in jemandem institutionellem Gedächtnis gefangen.

Aktuell: Widerspiegelt, was jetzt passiert, nicht was früher passiert ist

Stellen Sie sich vor: Sie haben nach einer Threat Hunt ein erhebliches Sicherheitsproblem identifiziert. Eine der beteiligten Schlüsselentitäten wird seit sechs Monaten in Ihrem Bestand gesehen. Wenn sie seit sechs Monaten dort ist, was ist davor? Leider haben Sie nur sechs Monate Aufbewahrung, für die Sie aktiv bezahlen. Alles Ältere ist in einem eingefrorenen Zustand, möglicherweise ein Archiv, oder nur in einer kälteren Datenschicht.

Sie müssen diese Daten rehydrieren, bevor Sie überhaupt mit der Suche beginnen können, aber bei der Menge, die Sie durchgehen müssen, wird das eine Weile dauern. Sie sind festgefahren, die Hände gebunden, weil Sie die Analyse, die Sie benötigen, nicht durchführen können. Vorfälle entfalten sich jetzt schneller, als ein Mensch folgen kann. Die Daten, die sie erklären, können nicht in kaltem Speicher warten, um aufgetaut zu werden, denn bis Sie den M.E.L.T.-Gletscher geschmolzen haben, ist der Angreifer weitergezogen.

Latenz wird normalerweise als Echtzeit-Problem dargestellt: Wie schnell neue Ereignisse nach ihrem Auftreten abfragbar werden. Aber es gibt zwei Arten von Latenz:

• Erfassungslatenz: Wie schnell neue Daten verfügbar werden.
• Historische Abfragelatenz: Wie schnell Sie Daten durchsuchen können, die bereits existieren.

Ein Agent, der ein kompromittiertes Dienstkonto untersucht, benötigt nicht nur die letzten Stunden von Authentifizierungsprotokollen. Er muss feststellen, ob dieses Konto über das vergangene Jahr hinweg ähnliches Verhalten gezeigt hat, ob die gleiche IP vor sechs Monaten in einem anderen Kontext auftauchte und ob sich die Zugriffsmuster der Entität allmählich verschoben oder sich über Nacht änderten. Wenn die Beantwortung dieser Fragen einen langen Rehydrierungsjob erfordert, stellt sich die Untersuchung des Agenten genau an dem Punkt ein, an dem der historische Kontext der Wendepunkt gewesen wäre.

Für einen KI-Agenten, der eine Untersuchungszeitachse erstellt, sind sowohl die Erfassungslatenz in Echtzeit als auch die historische Abfragelatenz gleich kritisch.

Im Rahmen des Zumutbaren sollten Daten jederzeit zugänglich sein. Eine aggregierte Ansicht aller Ihrer Telemetrie und Quellen über jeden Zeitrahmen hinweg ist wesentlich, um Verhaltensmuster zwischen den Agenten, Menschen und Maschinen zu verstehen, die in heutigen Umgebungen mehr Aktivität generieren. Hier resoniert das Konzept eines Cloud-nativen Sicherheits- und Observability-Data-Lake bei Führungs- und Betriebsteams.

Sie möchten, dass Ihre KI-Agenten Empfehlungen auf der Grundlage aller Ihrer Daten geben, nicht nur der Spitze des Eisbergs. Mehr vollständige Daten, genauere Antworten, schnellere Behebungen.

Untersuchbar: Gebaut, um Antworten zu liefern, nicht nur Daten zu speichern

Die ersten vier Säulen beschreiben Eigenschaften der Daten: einheitlich, normalisiert, korreliert und aktuell. Sie können jede einzelne überprüfen, indem Sie sich die Daten ansehen, ohne etwas über die Plattform zu wissen, die sie bereitstellt.

Untersuchbarkeit ist anders. Es geht darum, was passiert, wenn jemand oder etwas versucht, die Daten zu nutzen. Man könnte argumentieren, dass wenn Sie die Säulen 1 bis 4 perfekt treffen, Untersuchbarkeit nur das natürliche Ergebnis ist. Das ist absolut nicht der Fall. Sie können einen perfekt einheitlichen, normalisierten, korrelierten, Echtzeit-Datensatz haben, der hinter einer Abfrage-Engine sitzt, die 45 Sekunden braucht, um Ergebnisse zurückzugeben, 10.000 ungeordnete Ergebnisse zurückgibt, kein Konzept für die Bereichsfestlegung nach Entität hat und keine Möglichkeit bietet, eine Folgefrage zu stellen, die von der ersten Antwort informiert ist.

Die Daten sind fehlerfrei. Das Untersuchungserlebnis ist nutzlos. Jeder, der jemals ein wunderbar gestaltetes Data Warehouse mit einem schrecklichen BI-Tool verwendet hat, hat genau dieses Problem erlebt.

Stellen Sie sich die Säulen eins bis vier als das Rezept vor und Säule fünf als den Ofen. Ein schlechter Ofen ruiniert jedes noch so perfekte Rezept, und keine noch so hohe Qualität der Zutaten kann das kompensieren. Bei etablierten Kunden ist der Ofen oft genau der Ort, an dem KI-Agent-Bereitstellungen heute tatsächlich scheitern. Das Modell kann Schlussfolgerungen ziehen. Die Daten sind vorhanden. Aber die Plattform oder die KI-Umgebung kann nicht schnell genug den richtigen Ausschnitt davon bereitstellen, ihn eng genug eingrenzen und genug Kontext anhängen, damit der Agent damit in der für die Untersuchung erforderlichen Zeit etwas Sinnvolles anfangen kann.

Auf der Plattformebene erfordert Untersuchbarkeit:

• Entitätsbezogene Abfragen, die eine Zeitachse zurückgeben, nicht eine Ergebnismenge.
• Vorkorrelierter Kontext, der an jede Antwort angehängt ist, damit der Agent keinen zweiten Umweg braucht, um zu verstehen, was er vor sich hat.
• Bewertete Relevanz, sodass das erste Ergebnis die wahrscheinlichste Antwort ist, nicht nur die neueste Übereinstimmung.
• Reaktionszeiten, die in die Reasoning-Schleife eines Agenten passen, nicht in die Geduld eines Menschen beim Warten auf einen Ladebalken.

Der Unterschied zwischen einer Plattform, die Daten gut speichert, und einer, die untersuchbar ist, ist der Unterschied zwischen einer Bibliothek und einem Forschungsassistenten. Beide haben Zugriff auf die gleichen Bücher. Einer von ihnen reicht Ihnen die offene Seite.

Rechenschaftspflicht und Reasoning

Die letzte Säule wird entscheidend, sobald ein KI-Agent von der Empfehlung einer Aktion zum autonomen Ausführen übergeht. Oder in der Sprache des Betriebsmodells: von Human-in-the-Loop zu Human-on-the-Loop bis hin zu Human-out-of-the-Loop.

Eine Empfehlungs-Engine kann falsch liegen, ohne große Konsequenzen. Ein Agent mit Produktionszugriff, der autonom handelt, ist eine andere Sache. Sein Reasoning und seine Aktionen müssen im Nachhinein rekonstruierbar sein – nicht als Compliance-Nachgedanke, sondern als operative Anforderung.

Hier hat sich die Aufmerksamkeit der Branche konzentriert: Analysten, die Unternehmenstechnologie-Führung erforschen, haben „Ermöglichung und Schutz von KI“ als oberste Priorität für Sicherheitsverantwortliche in diesem Jahr identifiziert, mit Schwerpunkt auf den Nachweis der Kontrolle über agentische Risiken statt nur deren Existenz zu behaupten. Separate Forschung zur Führung im Engineering zeigt, dass die große Mehrheit der Technologieführer KI-Agenten bereits als wachsendes Sicherheitsrisiko sieht – genau wegen der Breite des Zugriffs, der ihnen gewährt wird, im Verhältnis zur angewendeten Überwachung. Der jüngste Hugging Face-Vorfall ist ein Beispiel dafür. Einige Analysten prognostizieren, dass bis Ende des Jahrzehnts ein bedeutsamer Anteil der Sicherheitsvorfälle in Unternehmen auf KI-Agent-Missbrauch zurückzuführen sein wird – statt auf traditionelle Angriffsvektoren.

Rechenschaftspflicht bedeutet auch die Spur, die alles hinterlässt, was Ihre Agenten tun. Zugriff, der auf Plattformebene gesteuert wird, statt nach Konvention. Ein dauerhafter, abfragbarer Datensatz darüber, was ein Agent sah, was es entschied und was es tat – getrennt von der Aktion selbst – damit die Frage „Warum ist das passiert?“ sechs Monate später eine echte Antwort hat. Und entscheidend ist: ein Feedback-Loop. Wenn ein Fehler einmal passiert, liegt das an der KI. Wenn der gleiche Fehler zweimal passiert, weil niemand das Modell neu trainiert oder den Prompt verfeinert hat, liegt das an uns. Rechenschaftspflicht ist nicht nur der Audit-Trail. Es ist das System, das sicherstellt, dass der Trail gelesen und darauf reagiert wird.

Wie es aussieht, den Standard tatsächlich zu erfüllen

Dieses Framework beschreibt, worum die Sumo Logic-Plattform konstruiert ist, und wir sind unser eigener erster Kunde. Unser SOC nutzt unsere Agenten, um unsere App und Infrastruktur zu sichern. Mobot, der SOC Analyst Agent und eine breitere Team-of-Agents-Architektur hängen von diesen sechs Säulen ab. Sie funktionieren nicht ohne sie. Kein Agent tut das.

Die Fähigkeit von Mobot, über Logs, Metriken und Traces in einem einzigen Gesprächsfluss zu ermitteln, funktioniert nur, weil die zugrunde liegende Plattform sie als eine einzige, normalisierte Oberfläche behandelt, statt als drei separate Produkte, die nachträglich zusammengeklebt wurden. Wenn es von einer Metrik-Anomalie zur spezifischen Log-Zeile und zum Trace-Span übergeht, die sie erklären, leistet die Korrelation die Arbeit. Wenn es weiß, dass der betroffene Service von einem bestimmten Team betrieben wird und vor zwei Stunden bereitgestellt wurde, leistet der Kontext die Arbeit.

Und während der SOC Analyst Agent von der Oberflächenbearbeitung von Erkenntnissen zum Handeln übergeht, wird Rechenschaftspflicht von einem abstrakten Prinzip zu dem, das bestimmt, ob diese Autonomie tatsächlich vor einem Sicherheitsteam, einem Auditor oder einem Vorstand verteidigbar ist.

Die KI-Landschaft wird sich weiter verschieben. Modelle werden schneller, billiger und leistungsfähiger. Agenten werden sich vervielfachen. Die Anbieter, die sie entwickeln, werden kommen und gehen.

Aber die Plattformen, die überleben, werden diejenigen sein, die die Daten richtig verstanden haben, denn Daten überdauern jedes Modell, das auf ihnen trainiert wurde, jeden Agenten, der über sie nachdenkt, und jeden Anbieter, der behauptet, sie intelligenter gemacht zu haben. Die sechs Säulen sind kein Schutzgraben gegen Konkurrenten. Sie sind das Fundament, das alles, das darauf aufgebaut wird, vertrauenswürdig macht. Und in Sicherheitsoperationen mit KI ist Vertrauen das aktuelle Schlachtfeld.

Sehen Sie, wie Sumo Logic das in Aktion umsetzt. Fordern Sie eine Demo an.