{"id":82073,"date":"2026-09-02T08:18:11","date_gmt":"2026-09-02T16:18:11","guid":{"rendered":"http:\/\/www.sumologic.com\/blog\/die-sechs-saeulen-der-ki-bereiten-telemetrie"},"modified":"2026-10-29T17:38:01","modified_gmt":"2026-10-30T01:38:01","slug":"six-pillars-ai-ready-telemetry","status":"publish","type":"blog","link":"https:\/\/www.sumologic.com\/de\/blog\/six-pillars-ai-ready-telemetry","title":{"rendered":"Die sechs S\u00e4ulen der KI-bereiten Telemetrie"},"content":{"rendered":"\n
\n
\n
\n
\n
\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

\u201eKI-bereit\u201c ist \u00fcberall gerade im Trend und wird fast jedem Produkt in jeder Kategorie angeh\u00e4ngt. Das eing\u00e4ngige Label bedeutet selten etwas Konkretes, genauso wie zus\u00e4tzliche Fragen berechtigt sind, wenn Anbieter behaupten, \u201eKI-nativ\u201c zu sein. Nach dem Durchk\u00e4mpfen durch all das Marketing-Jargon braucht es einen Standard, keine Werbeaussage. Und die Definition \u00e4ndert sich je nachdem, wof\u00fcr die Daten verwendet werden. KI-bereit f\u00fcr ein Data Warehouse und KI-bereit f\u00fcr Live-Operationstelemetrie sind nicht dasselbe Problem.<\/p>\n\n\n\n

Telemetriedaten<\/a> haben enormes ungenutztes Potenzial, und jeder Anbieter, der KI-Sicherheit verkauft, f\u00fchrt 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\u00fcgt unstrukturierten Daten Struktur hinzu. Die eigentliche Frage ist nicht, wie intelligent Ihr Agent ist. Es ist, ob Ihre Telemetrie \u00fcberhaupt daf\u00fcr konzipiert wurde, dass ein Agent sie von Anfang an verarbeitet.<\/p>\n\n\n\n

Was macht Telemetrie KI-bereit?<\/h2>\n\n\n\n

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\u00fcr die agentischen Workflows bereit ist, die bereits ankommen. Nicht eine Funktion, die auf Ihren Security- und Observability-Stack aufgesetzt wird, sondern ein Standard f\u00fcr die Daten darunter. Wir glauben, dass diese sechs Eigenschaften KI-bereite Telemetrie definieren:<\/p>\n\n\n\n

    \n
  1. Einheitlich<\/strong>: Daten befinden sich in einer durchsuchbaren Ebene.<\/li>\n\n\n\n
  2. Normalisiert:<\/strong> Daten haben eine konsistente Struktur und Bedeutung.<\/li>\n\n\n\n
  3. Korreliert\/kontextualisiert:<\/strong> Signale sind miteinander verbunden und mit dem Wissen angereichert, das n\u00f6tig ist, um sie zu verstehen.<\/li>\n\n\n\n
  4. Aktuell<\/strong>: Daten sind verf\u00fcgbar, wenn Sie sie brauchen, \u00fcber aktuelle und historische Zeitr\u00e4ume hinweg.<\/li>\n\n\n\n
  5. Untersuchbar:<\/strong> Die Plattform kann Daten in n\u00fctzliche Antworten umwandeln, nicht nur Rohergebnisse zur\u00fcckgeben.<\/li>\n\n\n\n
  6. Rechenschaftspflichtig:<\/strong> KI-\u00dcberlegungen und Aktionen k\u00f6nnen nachvollzogen, gesteuert und im Nachhinein nachverfolgt werden.<\/li>\n<\/ol>\n\n\n\n

    Die Herausforderung wird verst\u00e4rkt, weil Operationstelemetrie nicht stillsteht. Metriken, Ereignisse, Logs und Traces \u2013 manchmal auch als MELT-Daten bezeichnet \u2013 werden kontinuierlich von Systemen generiert, die keine Ahnung haben, dass ein KI-Agent sie sp\u00e4ter m\u00f6glicherweise liest, in Mengen und Formaten, die niemand f\u00fcr die maschinelle Verarbeitung konzipiert hat. Und zunehmend ist die KI, die diese Daten liest, nicht dabei, eine Tatsache f\u00fcr einen Chatbot abzurufen. Sie diagnostiziert einen Live-Incident, untersucht eine aktive Bedrohung und nimmt in einer wachsenden Zahl von Bereitstellungen Ma\u00dfnahmen mit echten Konsequenzen.<\/p>\n\n\n\n

    So sieht jede Funktion in der Praxis aus.<\/p>\n\n\n\n

    Einheitlich: Eine Ebene, um sie alle zu beherrschen<\/h2>\n\n\n\n

    Die erste Anforderung ist die grundlegendste und die am h\u00e4ufigsten nicht erf\u00fcllte: Logs, Metriken, Traces und Sicherheitsereignisse m\u00fcssen 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\u00e4higen Workflows ist es nicht ideal, kritische Daten in verschiedenen Formaten \u00fcber Silos verteilt zu lassen. Wenn Sie darauf vertrauen m\u00fcssen, dass der Agent die Datenbits zusammensetzt, die er zur Probleml\u00f6sung ben\u00f6tigt, verschwindet das Risiko, dass er das falsch macht, nicht. Es wird nur schwerer zu erkennen.<\/p>\n\n\n\n

    Stellen Sie sich einen On-Call-Ingenieur eines mittelgro\u00dfen Fintech-Unternehmens w\u00e4hrend 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\u00e4hrend eines Incidents wird die Aufgabe des Ingenieurs zum Tab-Wechsel und mentaler \u00dcbersetzung, nicht zur Untersuchung.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    Das Open Cybersecurity Schema Framework<\/a> und Dienste wie AWS Security Lake<\/a> existieren genau deshalb, weil die Branche erkannt hat, dass Security- und Operationsdaten, die \u00fcber Dutzende von Anbietern verteilt sind, unverwaltbar werden. Jetzt integrieren sich bereits mehr als 50 Anbieter nur mit Security Lake, jeder tr\u00e4gt 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.<\/p>\n\n\n\n

    Einheitlich bedeutet nicht ein Anbieter f\u00fcr alles. Es bedeutet einen Ort, an dem die Frage \u201eWas ist passiert?\u201c \u00fcber alles hinweg auf einmal gestellt werden kann. Und wenn dieser einheitliche Data Lake auch ein einheitliches Entity-Modell und ein einheitliches institutionelles Ged\u00e4chtnis hat, haben Agenten nicht nur die Daten. Sie haben den Kontext, der erforderlich ist, um verantwortungsvoll zu argumentieren.<\/p>\n\n\n\n

    Normalisiert: Struktur wird automatisch angewendet, nicht manuell<\/h2>\n\n\n\n

    Wir haben dies oben erw\u00e4hnt, aber es verdient seine eigene S\u00e4ule. Alles an einen Ort zu bringen, l\u00f6st die H\u00e4lfte des Problems. Die andere H\u00e4lfte ist, dass Rohtelemetrie ein Durcheinander inkonsistenter Formate ist.<\/p>\n\n\n\n

    Jede Anwendung, jedes Team, jede \u00c4ra der Infrastruktur schreibt Logs leicht unterschiedlich, ohne durchgesetztes Schema. Dieses Problem ist nicht neu. Wie der ber\u00fchmte XKCD-Comic<\/a> festgehalten hat, bekommt jedes Mal, wenn jemand merkt, dass es konkurrierende Standards gibt, die brillante Idee, noch einen weiteren Standard hinzuzuf\u00fcgen. Optimistisch gesehen k\u00f6nnten wir mit OCSF und ECS und breiter Branchenunterst\u00fctzung endlich die Normalisierungsschlacht gewinnen \u2026 und sogar den Krieg.<\/p>\n\n\n\n

    Genau genommen hat die Pipeline drei unterschiedliche Schritte. Normalisierung bedeutet, dass die Struktur automatisch bei der Erfassung angewendet wird \u2013 vom Parsing \u00fcber die Feldextraktion bis zur Schema-Zuordnung \u2013 anstatt dass jedes Mal ein ma\u00dfgeschneidertes Integrationsprojekt erforderlich ist, wenn eine neue Datenquelle auftaucht. Paradoxerweise ist dies f\u00fcr KI wichtiger als f\u00fcr Menschen: Eine Person kann eine leicht fehlgeformte Protokollzeile \u00fcberfliegen und verstehen, was sie bedeutet. Ein Modell, das \u00fcber dieselben Daten nachdenkt, ben\u00f6tigt eine konsistente Struktur, um zuverl\u00e4ssig zu argumentieren, sonst ist es nur Mustererkennung gegen Rauschen. Und selbst wenn es sich durcharbeiten kann, kostet es unn\u00f6tige Token-Verbrennung, um dorthin zu gelangen.<\/p>\n\n\n\n

    Normalisierung ist kein Datenhygiene-Projekt. Das Bereinigen Ihrer Daten ist wie das Korrekturlesen eines Dokuments auf Tippfehler. Parsing und Normalisierung sind das \u00dcbersetzen von Dokumenten, die in f\u00fcnf verschiedenen Sprachen geschrieben sind, in eine gemeinsame Sprache. Wenn sich Feldnamen zwischen Quellen unterscheiden, hat ein KI-Agent keine zuverl\u00e4ssige M\u00f6glichkeit, den Akteur vom Ziel zu unterscheiden.<\/p>\n\n\n\n

    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\u00fchrt 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.<\/p>\n\n\n\n

    Das Hauptproblem hier ist, dass es den Fehler nicht korrigiert. Es wird ihn mit vollst\u00e4ndiger Sicherheit pr\u00e4sentieren, und der Analyst wird danach handeln. Multiplizieren Sie das jetzt \u00fcber jede Protokollquelle, in der \u201ewer hat was wem angetan\u201c anders ausgedr\u00fcckt 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\u00fchrt, sodass \u201esrc\u201c immer Quelle bedeutet, \u201edst\u201c immer Ziel bedeutet und Akteur immer die Entit\u00e4t bedeutet, die die Aktion eingeleitet hat, unabh\u00e4ngig davon, von welchem Anbieter das Protokoll stammt.<\/p>\n\n\n\n

    Korreliert und kontextualisiert: Signale, die \u00fcber Typ und System hinweg verkn\u00fcpft sind<\/h2>\n\n\n\n

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

    Korrelation<\/strong> verbindet Signale, die eine kausale Beziehung \u00fcber Ihre Telemetrie hinweg teilen. Eine Trace-ID verkn\u00fcpft sich mit den Protokollzeilen, die sie generiert hat, die sich mit der Metrik-Anomalie verkn\u00fcpfen, die sie erkl\u00e4rt. 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\u00fcpfen.<\/p>\n\n\n\n

    Kontext<\/strong> ist das Wissen, das im Datenstrom \u00fcberhaupt nicht existiert. Es ist die Tatsache, dass dieser Server der Laptop des CFO ist. Dass ein IP-Bereich einem Auftragnehmer geh\u00f6rt, der letzten Freitag offboarded wurde. Dass sich ein Service gerade migriert und das Team bis Donnerstag mit erh\u00f6hten Fehlerquoten rechnet. Dass ein Warnmuster im letzten Quartal zweimal untersucht und beide Male als bekannter Fehlalarm geschlossen wurde.<\/p>\n\n\n\n

    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\u00e4ch zwischen zwei Ingenieuren, die zuf\u00e4llig zur gleichen Zeit Kaffee trinken gingen. Es war real, es war kritisch, und es war f\u00fcr jedes automatisierte System im Geb\u00e4ude v\u00f6llig unsichtbar.<\/p>\n\n\n\n

    Die Unterscheidung ist erw\u00e4hnenswert, weil ein KI-Agent, der einer Trace-Spanne zum Protokollfehler folgen kann, der sie verursacht hat, aber nicht wei\u00df, dass der betroffene Service sich in einem geplanten Wartungsfenster befindet, die Untersuchung nicht gel\u00f6st hat. Er hat eine technisch korrekte, operativ nutzlose Warnung produziert. Ein Agent ben\u00f6tigt beides, was bedeutet, dass die Plattform beides bereitstellen muss: kausale Verkn\u00fcpfungen \u00fcber Telemetrie hinweg f\u00fcr Korrelation und organisatorisches Wissen wie Asset-Eigent\u00fcmerschaft, gesch\u00e4ftliche Kritikalit\u00e4t, \u00c4nderungspl\u00e4ne, historische Untersuchungsergebnisse und Threat-Intel-Anreicherungen, kodiert in einer Struktur, die der Agent abfragen kann, nicht in jemandem institutionellem Ged\u00e4chtnis gefangen.<\/p>\n\n\n\n

    Aktuell: Widerspiegelt, was jetzt passiert, nicht was fr\u00fcher passiert ist<\/h2>\n\n\n\n

    Stellen Sie sich vor: Sie haben nach einer Threat Hunt ein erhebliches Sicherheitsproblem identifiziert. Eine der beteiligten Schl\u00fcsselentit\u00e4ten 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\u00fcr die Sie aktiv bezahlen. Alles \u00c4ltere ist in einem eingefrorenen Zustand, m\u00f6glicherweise ein Archiv, oder nur in einer k\u00e4lteren Datenschicht.<\/p>\n\n\n\n

    Sie m\u00fcssen diese Daten rehydrieren, bevor Sie \u00fcberhaupt mit der Suche beginnen k\u00f6nnen, aber bei der Menge, die Sie durchgehen m\u00fcssen, wird das eine Weile dauern. Sie sind festgefahren, die H\u00e4nde gebunden, weil Sie die Analyse, die Sie ben\u00f6tigen, nicht durchf\u00fchren k\u00f6nnen. Vorf\u00e4lle entfalten sich jetzt schneller, als ein Mensch folgen kann. Die Daten, die sie erkl\u00e4ren, k\u00f6nnen nicht in kaltem Speicher warten, um aufgetaut zu werden, denn bis Sie den M.E.L.T.-Gletscher geschmolzen haben, ist der Angreifer weitergezogen.<\/p>\n\n\n\n

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