KI-Evaluation: Was wir im Alltag wirklich brauchen

Agenten bestehen Tests – und scheitern trotzdem

Ich habe oft genug gesehen, wie ein Agent in der Testumgebung alles richtig macht und zwei Tage später in der Produktion eine Entscheidung trifft, die niemand vorausgesehen hat. Das ist kein Bug. Das ist die Natur dieser Systeme: sie sind nicht-deterministisch.

Für mich war das eine harte Lehre, weil es einen Denkfehler korrigiert, der in vielen IT-Abteilungen noch sitzt: „Wenn es grün ist, ist es fertig."

Bei Agenten gibt es kein „fertig". Es gibt nur: „läuft zur Zeit gut, unter diesen Bedingungen." Genau deshalb brauchen wir eine andere Art, diese Systeme zu bewerten – kontinuierlich, im echten Betrieb, mit Menschen im Loop.

Kontext ist fast immer die Antwort

Wenn in meinen Pipelines ein Agent Unsinn produziert, liegt es in 8 von 10 Fällen nicht am Modell. Es liegt daran, dass ihm an einer bestimmten Stelle Kontext fehlt – oder der falsche Kontext ankommt.

Das ist die Arbeit, die niemand sexy findet, aber die wirklich den Unterschied macht:

Mehr Parameter ist leicht.
Bessere Retrieval-Architektur ist schwer.
Den richtigen Kontext auf der richtigen Ebene ist noch schwerer.

Aber genau da liegt der Hebel. Nicht beim nächsten Modell-Swap.

Die größte Hürde ist nicht technisch

Menschen vertrauen einem System nicht, weil es technisch perfekt ist. Sie vertrauen ihm, wenn sie spüren, dass es sich an ihre Arbeitsweise anpasst, dass sie verstanden werden, dass sie im Zweifel das letzte Wort haben.

Ich nenne das in meiner Arbeit Reagierfähigkeit – die Fähigkeit eines Systems, auf Signale zu antworten, statt stur durchzuwalzen. Das ist kein weiches Feature. Das ist die Voraussetzung dafür, dass KI überhaupt angenommen wird.

Unternehmen, die in teure Agenten-Stacks investieren und dann feststellen, dass niemand sie benutzt, haben meistens genau dieses Problem übersehen.

Evaluation ist ein Organ, kein Prozess

Der vielleicht härteste Punkt: Unternehmen, die ihre eigenen Arbeitsabläufe nicht verstehen, können KI nicht sinnvoll bewerten.

Viele, mit denen ich spreche, haben ihre Workflows nie wirklich kartographiert. Sie sehen den Input und das Endergebnis. Dazwischen: Blackbox. Und in diese Blackbox soll jetzt eine KI – ohne dass jemand sagen kann, ob sie die Sache besser oder schlechter macht als der Status quo.

Deshalb beginnt für mich jede seriöse KI-Einführung mit Workflow-Mapping. Nicht mit Tool-Auswahl.

Evaluation ist danach kein separater Prozess mehr. Sie ist ein Organ, das ein Unternehmen ausbildet – eine Eigenwahrnehmung für das eigene KI-Verhalten. Man merkt selbst, wann etwas rund läuft und wann etwas verkantet.

Weniger Dashboards, mehr Klarheit

Mein Lackmustest für jedes KI-Projekt: Wird dadurch etwas einfacher und handhabbarer – oder entsteht nur noch mehr Komplexität, die jemand verwalten muss?

Ich erlebe viel zu oft das Zweite. Teams, die unter ihren eigenen Monitoring-Tools ersticken. Das ist das stille Versagen vieler KI-Projekte: Sie fügen Komplexität hinzu, statt sie abzubauen.

Gute KI sorgt für Klarheit und Handlungssicherheit. Nicht für noch ein Dashboard.

Was ADAPTIVE Intelligence dazu beiträgt

Wenn du bis hierhin gelesen hast, ahnst du, warum mich diese Themen umtreiben. Mit der Adaptive Intelligence GmbH bin ich genau an diesem Schnittpunkt unterwegs: zwischen Agenten-Architektur, Kontext-Engineering und der menschlichen Seite von KI-Einführung.

Was wir am liebsten machen:

🔹 Kontext-Pipelines bauen, die Agenten das geben, was sie brauchen – nicht mehr, nicht weniger. Mehrstufiges Retrieval, sauberes Context-Packing, IntentRouter-Logik. Die unsexy Arbeit, die am meisten bringt.

🔹 Human-in-the-Loop-Oberflächen gestalten – unser g3nui ist genau dafür da: Evaluation als Teil des Workflows, nicht als nachträgliches Audit.

🔹 Workflow-Mapping bevor irgendwas automatisiert wird. Damit du dein eigenes System verstehst, bevor du es an eine KI übergibst.

🔹 Lokal lauffähige Systeme (Go, SQLite, Ollama) für alle, für die Datenhoheit nicht verhandelbar ist. DSGVO ist bei uns kein Hindernis – sie ist Architekturprinzip.

🔹 Stolpern als Signal – wir instrumentieren Systeme so, dass Fehlverhalten nicht nur geloggt, sondern als Lernsignal nutzbar wird. Ein Agent, der stolpert und daraus etwas mitnimmt, ist mehr wert als einer, der brav durchmarschiert und niemand weiß warum.

Wenn du gerade vor der Frage stehst, wie du KI-Piloten verantwortungsvoll in den Produktivbetrieb hebst – oder wenn deine Agenten in Tests brillieren und in der echten Welt stolpern – dann melde dich einfach.

Ein kurzes Gespräch reicht oft, um zu sehen, wo die eigentlichen Hebel liegen.