Können Sie Ihrem KI-Mitarbeiter vertrauen? Observability und Evaluation für Agenten in der Produktion

Sie würden einem neuen Mitarbeiter nicht an Tag eins Schreibzugriff auf Ihr CRM, Ihre Buchhaltung und Ihr Kundenpostfach geben - ohne Probezeit, ohne Vorgesetzten, ohne Aktenlage. Genau das aber tun viele Unternehmen mit einem KI-Agenten, sobald eine Anbieter-Demo gut läuft. Der Agent geht live, er beginnt echte Aktionen in echten Systemen auszuführen, und dann kommt die unbequeme Frage im nächsten Board-Meeting: Woher wissen wir eigentlich, dass er das Richtige tut?

Das ist keine hypothetische Sorge. 2024 entschied ein kanadisches Gericht, dass Air Canada an eine Erstattungsregel gebunden ist, die der eigene Chatbot erfunden hatte - ein Präzedenzfall, der jedes Unternehmen für das haftbar machte, was seine KI sagt²³. Branchenschätzungen beziffern die Kosten von KI-Halluzinationen für Unternehmen auf zweistellige Milliardenbeträge pro Jahr, ein großer Teil davon als operative Nacharbeit und Reputationsschaden²². Und Gartner erwartet, dass bis Ende 2027 mehr als 40 Prozent der agentischen KI-Projekte abgebrochen werden - genannt werden unklarer Wert und unzureichende Risikokontrollen¹.

Die Unternehmen, die ihre Agenten in der Produktion halten werden, sind jene, die sehen, messen und belegen können, was diese Agenten tun. Diese Fähigkeit hat einen Namen: KI-Agenten-Observability. Dieser Leitfaden erklärt, was sie ist, die vier Ebenen, die sie ausmachen, wie Evaluation und Drift-Erkennung aus einer Blackbox einen messbaren Kollegen machen, und wie dieselbe Instrumentierung, die Vertrauen schafft, auch den Audit-Trail erzeugt, den die EU-KI-Verordnung inzwischen erwartet.

Die Vertrauenslücke: Warum eine gute Demo nichts beweist

Eine Demo zeigt Ihnen einen Lauf, der gut ging. Produktion sind Tausende Läufe gegen unordentliche, unvorhersehbare Eingaben - und ein KI-Agent verhält sich anders als jede Software, die Ihr Team bisher eingesetzt hat. Die Lücke zwischen „es lief in der Demo“ und „wir können ihm in der Produktion vertrauen“ ist der Ort, an dem die meisten Agenten-Projekte still sterben.

• Agenten sind nicht-deterministisch - Dieselbe Eingabe kann in verschiedenen Läufen verschiedene Ausgaben erzeugen. Standard-Softwaretests setzen deterministische Ausgaben voraus, sodass die Werkzeuge, die Ihr Team bereits hat, die entscheidenden Fehler nicht fangen¹⁵.
• Fehler sind still - Eine klassische App wirft einen sichtbaren Fehler. Ein Agent gibt selbstbewusst eine falsche Antwort zurück, die vollkommen plausibel aussieht, und niemand bemerkt es, bis ein Kunde oder ein Prüfer es tut²⁰.
• Der Wirkungsradius sind echte Aktionen - Ein Chatbot, der halluziniert, verschwendet Lesezeit. Ein Agent mit Schreibzugriff, der halluziniert, bucht eine falsche Rechnung, sendet eine falsche Kundenantwort oder aktualisiert den falschen Datensatz in einem führenden System.
• Sie haften jetzt - Das Air-Canada-Urteil stellte fest, dass ein Unternehmen an das gebunden ist, was seine KI einem Kunden sagt²³. Behörden und Gerichte behandeln die Ausgabe einer KI zunehmend als Ausgabe des Unternehmens²⁴.
• Die versteckten Prüfkosten - Wenn ein Team einem Agenten nicht traut, prüft es seine Arbeit von Hand. Branchenumfragen schätzen, dass ein durchschnittlicher KI-Nutzer über vier Stunden pro Woche mit dem Verifizieren von Ausgaben verbringt - eine Steuer, die die Produktivität, die der Agent bringen sollte, still auffrisst²².
• Governance ist unreif - Gartners Forschung zeigt, dass den meisten Unternehmen noch ein reifes Modell zur Steuerung von Agenten fehlt, was einer der Gründe ist, warum so viele Einführungen zwischen Pilot und Produktion stecken bleiben⁴.

Die Vertrauenslücke ist kein Grund, Agenten zu meiden. Gartner prognostiziert ebenso, dass bis Ende 2026 40 Prozent der Unternehmensanwendungen aufgabenspezifische KI-Agenten enthalten werden - gegenüber weniger als 5 Prozent ein Jahr zuvor⁵. Die Agenten kommen. Die Frage ist, ob Ihre auf Belegen laufen oder auf Hoffnung.

Was Agent-Observability wirklich ist

Observability ist eine alte Idee aus der Technik: Ein System ist beobachtbar, wenn man seinen inneren Zustand von außen verstehen kann. Auf KI-Agenten angewandt heißt das, Sie können aus den Aufzeichnungen, die ein Agent hinterlässt, exakt rekonstruieren, was er entschieden hat, warum und was er getan hat. Die Kerneinheit ist der Trace.

Ein Trace ist die vollständige, strukturierte Aufzeichnung eines Agenten-Laufs, aufgeteilt in verschachtelte Spans. Ein Span auf oberster Ebene deckt die gesamte Aufgabe ab. Untergeordnete Spans decken jeden Modellaufruf, jeden Tool-Aufruf und jeden Abrufschritt ab. Jeder Span erfasst seine Eingaben, Ausgaben, Zeit, Token-Verbrauch und Kosten, sodass ein Entwickler einen einzelnen Lauf öffnen und den gesamten Entscheidungsbaum auf jeder Ebene sehen kann²⁵.

Der Standard, der es portabel macht

Das ist kein proprietäres Format mehr. Im April 2024 gründete OpenTelemetry, der offene Standard, der bereits für Anwendungs-Monitoring genutzt wird, eine Gruppe für generative KI, um gemeinsame Konventionen für Agenten-Telemetrie zu definieren. Das Ergebnis ist ein gemeinsames Schema für Prompts, Modellantworten, Token-Verbrauch, Tool-Aufrufe und Agenten-Orchestrierung⁶.

• Eine Instrumentierung, viele Tools - Die OpenTelemetry-GenAI-Konventionen erlauben, einmal zu instrumentieren und Traces an jedes kompatible Backend zu senden, statt sich an einen einzigen Anbieter zu binden⁷.
• Native Framework-Unterstützung - Agenten-Frameworks wie LangChain, CrewAI und AutoGen erzeugen konforme Spans nativ oder über Instrumentierungspakete, sodass grundlegendes Tracing in Tagen live sein kann⁸.
• Standard-Span-Typen - Ein Lauf erzeugt oben einen Invoke-Agent-Span, untergeordnete Chat-Spans für jeden Modellaufruf und Execute-Tool-Spans für jedes Tool, das der Agent nutzt⁸.
• Breite Anbieter-Adoption - Große Observability-Plattformen wie Datadog, IBM Instana, Honeycomb und New Relic unterstützen diese Konventionen bereits und korrelieren Agenten-Spans mit dem Rest Ihres Anwendungs-Monitorings⁹.
• Semantisch, nicht nur strukturell - Es geht darum, nicht nur „ist es gelaufen“ zu erfassen, sondern „was hat es entschieden und warum“ - also das Reasoning und die Tool-Argumente aufzuzeichnen, nicht nur die finale Ausgabe²⁸.

Was ein Trace ermöglicht

• Eine konkrete Beschwerde debuggen - Ein Kunde sagt, der Agent habe eine falsche Antwort gegeben. Sie öffnen genau diesen Lauf und sehen den Prompt, das veraltete abgerufene Dokument und den fehlgeschlagenen Tool-Aufruf.
• Das Muster hinter vielen Fehlern finden - Traces lassen sich aggregieren. Sie sehen, dass alle Fehler der letzten Woche dieselbe Abrufquelle oder dasselbe Tool teilten - das zeigt direkt auf den Fix.
• Kosten zuordnen - Jeder Span trägt den Token-Verbrauch, sodass Sie sehen, welche Schritte und Anwendungsfälle Ihre Modellkosten wirklich treiben²⁵.
• Belegen, was passiert ist - Ein vollständiger Trace ist der Beleg, den Sie einem Prüfer, einer Behörde oder Ihrem eigenen Risikoausschuss vorlegen.

Die vier Ebenen der Agent-Observability

Observability wird oft auf „wir loggen die Traces“ reduziert, aber Logging ist nur die erste Ebene. Ein produktiver Agent, dem Sie wirklich vertrauen können, ruht auf vier Ebenen, von denen jede eine andere Frage beantwortet. Lassen Sie eine weg, und das Vertrauen bricht.

1. Traces - was passiert ist - Die strukturierte Aufzeichnung jedes Laufs: Prompts, Reasoning, Tool-Aufrufe, abgerufene Daten, Ausgaben, Kosten und Latenz. Das ist der Rohbeleg, auf dem alles Weitere aufbaut.
2. Evaluation - war es gut - Die Bewertung dieser Traces gegen einen Standard für Genauigkeit, Sicherheit, Regeltreue und Aufgabenerfüllung, mit einer Mischung aus deterministischen Prüfungen und modellbasierten Judges.
3. Drift und Alerts - ist es noch gut - Die Beobachtung der Evaluationswerte über die Zeit und ein Alarm, wenn die Genauigkeit fällt, Ablehnungen steigen oder das Verhalten von der Baseline abdriftet.
4. Governance und Audit - können wir es belegen - Manipulationssichere, aufbewahrte Aufzeichnungen und Zugriffskontrollen, die es erlauben, einer Behörde, einem Prüfer oder einem Kunden zu antworten, und die Artikel 12 der EU-KI-Verordnung für Hochrisiko-Systeme erfüllen¹⁰.

Evaluation: Offline-Suiten und Online-Judges

Traces sagen Ihnen, was passiert ist. Evaluation sagt Ihnen, ob es gut war - in einem Maßstab, den kein menschliches Prüfteam erreichen könnte. Es gibt zwei Hälften, und ein produktiver Agent braucht beide.

Offline-Evaluation: das Regressions-Gate

Offline-Evaluation lässt Ihren Agenten vor jeder Änderung gegen einen festen Datensatz an Testfällen laufen. Sie ist das Äquivalent einer Testsuite in normaler Software, und einen Unternehmens-Agenten ohne eine solche auszuliefern, ist ein architektonisches Anti-Muster²¹.

• Sichert jede Änderung ab - Bevor ein neuer Prompt, ein neues Modell oder ein neues Tool live geht, läuft die Suite, und Regressionen werden sichtbar, bevor die Änderung gemergt wird¹⁶.
• Aus echten Fehlern gebaut - Die stärksten Testsets sind in echten Produktionsfehlern verankert, nicht in ausgedachten Fällen, weil sie einsehbare Belege dafür tragen, was tatsächlich bricht¹⁴.
• Berücksichtigt Nicht-Determinismus - Eine gute Offline-Suite lässt jeden Fall mehrfach laufen, denn eine Evaluation, die die Lauf-zu-Lauf-Varianz ignoriert, zieht den falschen Schluss¹⁵.
• Wächst jede Woche - Jeder neue Fehler, der in der Produktion gefangen wird, wird als Fall ergänzt, sodass die Suite kumuliert und derselbe Fehler nie still zurückkehrt¹⁴.

Online-Evaluation: Live-Verkehr beurteilen

Online-Evaluation bewertet eine Stichprobe echter Produktionsläufe, während sie geschehen, und alarmiert Sie, wenn die Qualität fällt, ohne die Erfahrung des Nutzers zu verzögern¹⁶.

• Nimmt Live-Läufe als Stichprobe - Sie bewerten einen konfigurierbaren Anteil des Produktionsverkehrs in Echtzeit, statt auf eine Beschwerde zu warten¹⁸.
• Setzt Schwellen und Alarme - Wenn der Live-Qualitätswert eine Schwelle überschreitet, wird der verantwortliche Owner benachrichtigt - so wie ein Bereitschaftsingenieur bei einem Latenzsprung¹⁸.
• Schließt die Schleife - Online gefundene Fehler werden gelabelt und in die Offline-Suite zurückgespielt, sodass die Realität Ihre Tests fortlaufend verbessert¹⁴.

Wie die Bewertung tatsächlich funktioniert

Drei Techniken übernehmen die Beurteilung, und reife Setups kombinieren alle drei, statt auf eine zu setzen.

LLM-as-a-Judge macht Evaluation bezahlbar, denn ein Modell kann ein anderes gegen klare Kriterien bewerten und ein strukturiertes Urteil zurückgeben¹⁷. Es ist keine Magie. Die Forschung dokumentiert echte Verzerrungen: Judges bevorzugen die erste Option, die sie sehen, belohnen längere Antworten und präferieren Ausgaben, die ihren eigenen ähneln¹⁶. Zuverlässig machen Sie es so, wie Sie es bei einem menschlichen Prüfer täten.

Drift, Genauigkeits-Alerts und Regression

Ein Agent, der am Starttag jeden Test bestand, kann still schlechter werden. Diese schrittweise Verschlechterung heißt Drift, und da Agenten nicht-deterministisch sind, ist sie ohne kontinuierliche Evaluation unsichtbar. Drift ist das stärkste Argument dafür, Observability als laufenden Betrieb zu behandeln, nicht als Häkchen beim Start.

Woher Drift kommt

• Daten-Drift - Die realen Eingaben verschieben sich weg von dem, worauf der Agent gebaut und getestet wurde, sodass die Genauigkeit fällt, obwohl sich am Agenten nichts geändert hat¹⁸.
• Modell-Drift - Der Anbieter aktualisiert das zugrunde liegende Modell. Derselbe Prompt verhält sich nun anders, und Ausgaben können über Anbieter und Versionen hinweg so variieren, dass ein Workflow bricht²¹.
• Agenten-Drift - In langlaufenden oder Multi-Agenten-Systemen zieht angesammelter Kontext den Agenten von der Aufgabe weg. Forschung, die Multi-Agenten-Systeme simulierte, fand, dass Verhaltensverschlechterung fast die Hälfte langlaufender Agenten betreffen könnte¹⁹.
• Prompt- und Tool-Drift - Eine Änderung an einer Prompt-Vorlage, einem Tool oder einer Abrufquelle hat Folgewirkungen, die ein einzelner Stichprobencheck verfehlt²⁰.
• Ablehnungs- und Wiederholungs-Anstieg - Eine steigende Rate an Ablehnungen oder Wiederholungen ist ein Frühwarnzeichen dafür, dass sich Verhalten verschiebt, oft bevor die Genauigkeit sichtbar fällt¹⁸.

Wie gute Drift-Erkennung aussieht

1. Eine gemessene Baseline - Ohne einen dokumentierten Startpunkt können Sie keine Drift erkennen. Erfassen Sie Genauigkeit, Latenz, Ablehnungsrate und Kosten beim Start als Referenz¹⁵.
2. Kontinuierliche Bewertung - Online-Evaluation läuft gegen Live-Verkehr, sodass die Trendlinien stets aktuell sind, nicht ein Quartals-Audit¹⁶.
3. Schwellen, die an Folgen gekoppelt sind - Alarme feuern, wenn eine Metrik ein für das Geschäft wirklich relevantes Niveau überschreitet, nicht bei statistischem Rauschen.
4. Ein Regressions-Gate bei jeder Änderung - Die Offline-Suite blockiert eine Änderung, die eine Kernmetrik senkt, sodass Sie nie versehentlich eine Regression ausliefern²¹.
5. Ein Rollback-Pfad - Wird Drift erkannt, können Sie auf eine bekannt gute Version zurücksetzen oder die Autonomie des Agenten reduzieren, bis das Problem behoben ist.

Governance und Audit-Trails

Die ersten drei Ebenen halten einen Agenten am Laufen. Die vierte Ebene erlaubt es Ihnen, es zu belegen - gegenüber einer Behörde, einem Prüfer, einem Kunden oder Ihrem eigenen Board. In der EU ist das für Hochrisiko-Systeme nicht mehr optional, und selbst wo es nicht verpflichtend ist, macht dieselbe Infrastruktur aus „vertrauen Sie uns“ ein „hier ist die Aufzeichnung“.

Was die EU-KI-Verordnung verlangt

• Automatisches Logging - Artikel 12 verlangt, dass Hochrisiko-KI-Systeme Ereignisse über ihren Lebenszyklus automatisch aufzeichnen, in einer Form, die die Funktionsweise des Systems nachvollziehbar macht¹⁰.
• Volle Rekonstruierbarkeit - Logs müssen genug erfassen - Zeitstempel, Eingaben, Ausgaben, aufgerufene Tools und menschliche Entscheidungen -, dass ein Prüfer rekonstruieren kann, was in einem bestimmten Lauf passiert ist¹³.
• Aufbewahrung - Betreiber müssen die Logs mindestens sechs Monate aufbewahren, bei bestimmten Systemen länger¹².
• Manipulationssicherheit - Die Aufzeichnungen müssen vertrauenswürdig sein, was in der Praxis heißt, dass sie nachträglich nicht still verändert werden können¹³.
• Die Frist steht - Die Pflichten für Anbieter und Betreiber von Hochrisiko-Systemen, einschließlich der Aufzeichnungspflicht aus Artikel 12, gelten ab dem 2. August 2026¹¹.

Governance ist nicht alles oder nichts

Der häufigste Governance-Fehler ist, jeden Agenten gleich zu behandeln - entweder alles zu sperren, bis nichts mehr live geht, oder allem zu vertrauen, bis etwas bricht. Gartner ist deutlich, wohin das führt.

• Aufsicht an Autonomie koppeln - Klassifizieren Sie jeden Agenten danach, wie viel er allein tun kann. Ein Nur-Lese-Agent, der Texte entwirft, braucht leichtere Aufsicht als einer mit Schreibzugriff auf Ihr ERP⁴.
• Human-in-the-Loop bei riskanten Aktionen - Die riskantesten Aktionen erhalten einen menschlichen Freigabepunkt; risikoarme laufen autonom mit Monitoring.
• Guardian-Agenten - Ein zweites KI-System kann einen arbeitenden Agenten zur Laufzeit bewerten und eindämmen. Gartner erwartet, dass bis 2028 viele CIOs Guardian-Agenten verlangen werden, um Agenten-Aktionen zu verfolgen und zu überwachen, und dass sie zu einem eigenen Marktsegment werden².
• Klare Verantwortung - Jeder Agent hat einen benannten menschlichen Owner, der für sein Verhalten verantwortlich ist, wie jeder andere Mitarbeiter.
• Eine Zugriffs- und Identitätsgrenze - Jeder Agent hat eine eigene Identität und Least-Privilege-Zugriff, sodass seine Aktionen zurechenbar sind und sein Wirkungsradius begrenzt ist. Das behandeln wir ausführlich in unserem Leitfaden zu Agenten-Identität und Zugriff.

Governance und Sicherheit sind zwei Seiten derselben Medaille. Observability sagt Ihnen, was ein Agent getan hat; Zugriffskontrolle begrenzt, was er tun kann. Für die Sicherheitshälfte des Bildes lesen Sie unseren Leitfaden zu KI-Agenten-Sicherheit und den OWASP LLM Top 10.

Der 90-Tage-Fahrplan zur Instrumentierung

Sie müssen nicht alle vier Ebenen bauen, bevor ein Agent live geht. Sie brauchen aber einen Plan, der Tracing ab Tag eins einbaut und Evaluation und Governance mit echten Läufen wachsen lässt. Hier ist ein fokussierter 90-Tage-Ansatz, der widerspiegelt, wie eine disziplinierte Einführung tatsächlich abläuft.

Phase 1: Instrumentieren und Baseline (Wochen 1-4)

1. Woche 1: Tracing einschalten - Instrumentieren Sie den Agenten mit den OpenTelemetry-GenAI-Konventionen, sodass jeder Lauf ab dem ersten Tag, an dem er echte Daten berührt, einen vollständigen Trace erzeugt⁷.
2. Woche 2: Definieren, was gut heißt - Schreiben Sie mit dem Prozess-Owner die aufgabenspezifischen Erfolgskriterien auf: Was zählt für diesen Agenten als korrektes, sicheres, regelkonformes Ergebnis.
3. Woche 3: Eine Baseline erfassen - Lassen Sie den Agenten im Schatten- oder begrenzten Modus laufen und erfassen Sie Genauigkeit, Latenz, Ablehnungsrate und Kosten als Referenzpunkt für jede künftige Drift-Erkennung¹⁵.
4. Woche 4: Die Offline-Suite anlegen - Machen Sie aus den ersten echten Läufen, besonders den Fehlern, einen ersten Satz an Testfällen¹⁴.

Phase 2: Bewerten und absichern (Wochen 5-8)

5. Woche 5-6: Die Judges bauen - Ergänzen Sie deterministische Prüfungen für alles mit einer korrekten Form und einen LLM-as-a-Judge für Qualität, kalibriert an menschlich gelabelten Beispielen¹⁶.
6. Woche 7: Das Regressions-Gate verdrahten - Lassen Sie die Offline-Suite bei jeder Änderung laufen, sodass kein Prompt-, Modell- oder Tool-Update ohne Bestehen live geht²¹.
7. Woche 8: Online-Evaluation aktivieren - Beginnen Sie, eine Stichprobe des Live-Verkehrs zu bewerten, und setzen Sie die ersten an echte Folgen gekoppelten Alarmschwellen¹⁸.

Phase 3: Steuern und skalieren (Wochen 9-12)

9. Woche 9: Aufbewahrung und Zugriff festlegen - Konfigurieren Sie manipulationssicheres, aufbewahrtes Logging, das Artikel 12 und Ihren internen Audit-Bedarf erfüllt¹⁰.
10. Woche 10-11: Owner und Checkpoints zuweisen - Geben Sie dem Agenten einen benannten Owner, klassifizieren Sie seine Autonomiestufe und setzen Sie eine menschliche Freigabe auf die riskantesten Aktionen⁴.
11. Woche 12: Prüfen und erweitern - Halten Sie die erste monatliche Durchsicht des Scorecards gegen die Baseline, spielen Sie jeden gefangenen Fehler in die Suite zurück und planen Sie den nächsten Anwendungsfall.

Wie Superkind passt

Superkind baut maßgeschneiderte KI-Mitarbeiter, die sich mit den Systemen verbinden, die Ihr Team bereits nutzt: E-Mail, Teams, SharePoint, CRM, ERP, Datenbanken und jede API-basierte Software. Sie laufen auf einem Company Brain, das Ihre Prozesse, Ihre Daten und Ihre Regeln hält, und werden jeden Tag besser, weil Ihr Team mit ihnen arbeitet. Observability und Evaluation sind kein Zusatz zu diesem Modell; sie sind, wie das Vertrauen verdient und wie die Lernschleife instrumentiert wird.

• Nachvollziehbar von Grund auf - Jede Aktion, die ein KI-Mitarbeiter über Ihre Systeme hinweg ausführt, wird als strukturierter Trace erfasst, sodass Sie jeden Lauf öffnen und genau sehen können, was er getan hat und warum.
• Evaluation auf Ihrer Definition von gut - Wir definieren Erfolgskriterien mit Ihrem Prozess-Owner und bauen die Judges um Ihre Arbeit herum, nicht um einen generischen Benchmark.
• Drift-Alerts gegen Ihre Baseline - Wir messen während des Aufbaus eine Baseline und alarmieren Ihr Team, wenn Genauigkeit, Ablehnungen, Latenz oder Kosten davon abweichen.
• Die Feedback-Schleife ist das Produkt - Korrekturen, die Ihr Team bei der Prüfung macht, fließen direkt in das Company Brain zurück. Das ist dieselbe Schleife, die wir in unserem Beitrag zur KI-Feedback-Schleife beschreiben - sichtbar und messbar gemacht.
• Audit-fertige Aufzeichnungen - Aufbewahrte, manipulationssichere Logs geben Ihnen die Belege, die Artikel 12 für Hochrisiko-Systeme erwartet und nach denen Ihre eigenen Prüfer fragen.
• Sitzt auf Ihrem Stack - Observability klinkt sich über offene Konventionen in Ihr bestehendes Monitoring ein, statt Ihrem Team eine neue Plattform aufzuzwingen⁹.
• Human-in-the-Loop, wo es zählt - Riskante Aktionen erhalten einen Freigabepunkt; Routineaktionen laufen autonom mit Monitoring, passend zur Autonomiestufe jedes Agenten.
• Ergebnisse, keine Lizenzen - Wir messen den ROI jedes Anwendungsfalls gegen die erfasste Baseline, sodass Wert belegt und nicht behauptet wird. Unsere Sicht dazu steht im Leitfaden zum ROI von KI-Agenten.

Entscheidungsrahmen: Wie viel Observability brauchen Sie?

Nicht jeder Agent braucht den vollen Stack an Tag eins. Das richtige Maß an Observability skaliert mit dem, was der Agent tun kann, und dem, was es Sie kostet, wenn er falsch liegt.

Der Markt bewegt sich in eine Richtung. Das Segment der LLM-Observability wird von rund zwei Milliarden Dollar in 2025 aus zu einer schnell wachsenden Kategorie geschätzt, weil jede ernsthafte Agenten-Einführung sie inzwischen braucht²⁷. Es früh einzubauen, ist billiger als es nach dem ersten Vorfall nachzurüsten.

Häufig gestellte Fragen

Henri Jung

Mitgründer von Superkind, wo er KMU und Unternehmen hilft, maßgeschneiderte KI-Agenten einzuführen, die wirklich zu der Art passen, wie ihre Teams arbeiten. Henri brennt dafür, die Lücke zwischen dem, was KI kann, und dem Wert, den sie in echten Unternehmen schafft, zu schließen. Er ist überzeugt, dass der Mittelstand alles hat, was er braucht, um bei KI vorn zu sein - er braucht nur den richtigen Ansatz.