// Agenten

Warum KI-Agenten in der Produktion scheitern

Im Test überzeugend, im Betrieb abgeschaltet. Die häufigsten Gründe, warum KI-Agenten es nicht durch den Alltag schaffen. Und woran Sie das Risiko erkennen, bevor Sie investieren.

4. August 2026 · ca. 7 Min. Lesezeit · Jan Fischer

Quadrant aus Zuverlässigkeit und Autonomie mit Risiko-Zone

Motiv

Inhalt

Die Geschichte beginnt fast immer gleich. Ein Agent geht in den Testbetrieb, die ersten Ergebnisse sehen gut aus, das Management ist zufrieden. Sechs Wochen später kontrolliert ein Mitarbeiter jede einzelne Entscheidung nach. Nach drei Monaten übernimmt er wieder komplett, der Agent läuft nur noch formal mit. Irgendwann schaltet ihn jemand ab, leise, ohne Projektabschluss.

Dieses Muster hat einen Namen verdient, denn es kostet den Handel derzeit viel Geld. Der Beitrag ordnet ein, wie verbreitet es ist, woran es wirklich liegt und woran Sie das Risiko bei Ihrem eigenen Vorhaben erkennen, bevor die erste Rechnung bezahlt ist.

Wie oft werden KI-Agenten wieder eingestellt?

Öfter, als die Erfolgsgeschichten vermuten lassen. Gartner rechnet in einer Prognose damit, dass über 40 Prozent der agentischen KI-Projekte bis Ende 2027 wieder eingestellt werden. Als Gründe nennt das Analystenhaus steigende Kosten, unklaren Nutzen und fehlende Risikokontrollen. Das ist eine Vorhersage, kein gemessenes Ergebnis, und so sollte man sie auch lesen. Sie passt allerdings zu dem, was Befragungen über den Ist-Zustand zeigen: Der Anteil der Unternehmen, die die Mehrheit ihrer KI-Initiativen vor der Produktion abbrechen, hat sich laut S&P Global Market Intelligence zuletzt auf 42 Prozent mehr als verdoppelt.

Auffällig an diesen Zahlen ist weniger ihre Höhe als ihre Richtung. Die Modelle werden von Jahr zu Jahr besser, die Abbruchquoten steigen trotzdem. Wäre die Technologie das Problem, müsste die Kurve in die andere Richtung zeigen. Tut sie aber nicht. Der Engpass liegt woanders.

Woran scheitern die Agenten wirklich?

An der Grundlage unter dem Agenten, fast nie am Modell. Die Ursachenforschung der RAND Corporation hat erfahrene Data Scientists und Ingenieure zu gescheiterten KI-Projekten befragt. Die häufigsten Ursachen: missverstandene Problemstellungen und fehlende oder unzureichende Daten. Technische Grenzen der Modelle tauchen in der Liste weit hinten auf. Gartner ergänzt die Datenseite: Fehlende KI-taugliche Daten gefährden Projekte grundsätzlich, und ein erheblicher Teil der Organisationen hat die nötigen Datenfundamente schlicht nicht.

Was heißt das konkret für einen Agenten im Handel? Ein Agent, der Bestellungen auslöst, Preise anpasst oder Kundenanfragen beantwortet, trifft seine Entscheidungen aus den Daten, die ihm die Systeme liefern. Artikelstammdaten, Bestände, Konditionen, Kundenhistorie. Sind diese Daten lückenhaft oder widersprüchlich, entscheidet der Agent lückenhaft und widersprüchlich. Nur eben automatisiert, in Masse und mit voller Überzeugung. KI löst Datenprobleme nicht. Sie skaliert sie.

Auch die Kostenseite gehört in dieses Bild. Ein Agent, der mehrschrittige Aufgaben selbstständig ausführt, verursacht laufende Verarbeitungskosten, und die steigen mit jeder Korrekturschleife. Ein Agent auf schlechten Daten dreht viele solcher Schleifen: Er entscheidet, ein Mensch greift ein, der Fall geht zurück, der Agent entscheidet erneut. Aus dem Werkzeug, das Arbeit sparen sollte, wird ein System, das Arbeit erzeugt und dabei Rechenkosten produziert. Die eskalierten Kosten, die Gartner als Abbruchgrund nennt, sind oft nur das Symptom dieser Schleifen.

Dazu kommt ein zweiter, selten benannter Grund: der fehlende kontrollierte Betrieb. Viele Agenten gehen ohne Protokoll ihrer Entscheidungen, ohne definierte Grenzen und ohne geregelte Ausnahme-Freigabe in den Test. Ein Mensch, der eingreifen soll, braucht aber nachvollziehbare Entscheidungen und einen klaren Eingriffspunkt. Fehlt beides, bleibt ihm nur das Misstrauen gegen alles. Dann kontrolliert er jede Entscheidung nach, und der Agent spart keine Minute mehr ein.

Warum fällt das erst im Betrieb auf und nicht im Test?

Der Test ist darauf angelegt, zu überzeugen. Das ist keine böse Absicht, es liegt in der Natur eines Piloten. Jemand wählt die Daten aus, bereinigt sie von Hand und führt das System unter Aufsicht vor. Widersprüche im Artikelstamm, tote Pflichtfelder, veraltete Bestände: alles vorab aufgeräumt, damit die Demo läuft. Der Pilot beweist damit die Fähigkeit des Modells. Über den Zustand der eigenen Datenlandschaft sagt er nichts.

Gegenüberstellung von Pilotbetrieb und Produktivbetrieb
Der Pilot läuft auf handverlesenen Daten. Der Betrieb läuft auf der echten Systemlandschaft.

Im Betrieb fällt die Handarbeit weg, und noch etwas kommt hinzu. Menschen gleichen schlechte Daten seit Jahren unbewusst aus. Ein Disponent, also die Person, die über Nachbestellungen entscheidet, erkennt eine unplausible Lieferzeit auf einen Blick und korrigiert sie im Kopf. Dieses stille Wissen taucht in keinem System auf. Der Agent übernimmt den Prozess ohne dieses Wissen und macht die verdeckten Lücken zum ersten Mal sichtbar. Für die Beteiligten sieht es dann so aus, als hätte der Agent neue Fehler eingeführt. Tatsächlich waren die Fehler immer da. Es hat sie nur nie jemand gezählt.

Durchgerechnetes Beispiel

fiktive Daten. Ein Multichannel-Händler testet einen Nachbestell-Agenten. Im Pilotbetrieb über sechs Wochen greift ein Disponent bei 31 Prozent der Bestellvorschläge ein. Die Auswertung der Protokolle zeigt: 72 Prozent dieser Eingriffe gehen auf Stammdaten zurück, vor allem auf fehlende Lieferzeiten und Mindestbestellmengen. Der Agent war nie das Problem. Der vollständige Befund steht im frei verfügbaren Beispiel-Report.

Woran erkennen Sie das Risiko, bevor Sie starten?

An fünf Warnsignalen, die sich ohne Projekt und ohne Berater prüfen lassen. Jedes einzelne hat in unseren Datenprüfungen schon Vorhaben gestoppt.

  1. Der Prozess, den der Agent übernehmen soll, hat keine gemessene Fehler- oder Eingriffsquote. Wer nicht weiß, wie oft heute korrigiert wird, kann den Agenten später an nichts messen.
  2. Die Daten, aus denen der Agent entscheiden soll, werden in mehreren Systemen parallel gepflegt, ohne dass eines führt. Widersprüche wandern dann ungefiltert in seine Entscheidungen.
  3. Niemand kann sagen, wie vollständig die entscheidungsrelevanten Felder gepflegt sind. Die Zahl ist in einer Stunde abfragbar. Fehlt sie, hat sie nur noch niemand wissen wollen.
  4. Das Wissen, das der Prozess braucht, liegt in Excel-Ablagen und Köpfen. Ein Agent kann daraus nicht zuverlässig lesen, und niemand merkt, wenn er Veraltetes nutzt.
  5. Es gibt keinen Plan für Protokoll, Grenzen und Ausnahme-Freigabe. Ein Agent ohne kontrollierten Betrieb verliert das Vertrauen der Mannschaft nach dem ersten sichtbaren Fehler. Danach ist es fast unmöglich, es zurückzugewinnen.

Treffen zwei oder mehr Signale zu, ist das Vorhaben nicht verloren. Es hat nur die falsche Reihenfolge. Erst die Lücke schließen, dann den Agenten starten. Andersherum finanziert man ein teures Experiment mit vorhersehbarem Ausgang.

Was machen Häuser anders, bei denen Agenten durchhalten?

Sie bauen Zuverlässigkeit vor Autonomie auf. Das klingt banal und ist in der Praxis die seltene Ausnahme. Der Normalfall sieht anders aus: hoher Autonomie-Anspruch, schwaches Fundament. In unserem Zielbild aus Zuverlässigkeit und Autonomie ist das die Risiko-Zone unten rechts, und dort entstehen die Projekte, die später in der Abbruch-Statistik landen.

Quadrant aus Zuverlässigkeit und Autonomie mit markierter Risiko-Zone
Der Weg zum verlässlichen Agenten führt nach oben, nicht nach rechts.

Häuser, bei denen Agenten im Alltag bestehen, gehen den Weg in einer anderen Reihenfolge. Sie klären zuerst, welche Datenbereiche ihr konkreter Anwendungsfall braucht, und bringen nur diese in Ordnung. Kein unternehmensweites Datenprojekt, sondern das kleinste Fundament, das ausreicht. Sie starten den Agenten mit engen Grenzen und einer klaren Ausnahme-Freigabe, messen die Eingriffsquote von Woche eins an und weiten die Autonomie erst aus, wenn die Zahlen es erlauben. Und sie behandeln den Betrieb als Teil des Vorhabens: Protokolle werden ausgewertet, Ausnahmen fließen zurück in die Datenpflege.

Ein Punkt noch, der in Erfolgsprojekten auffällig oft vorkommt: eine vorab festgelegte Zielgröße. Vor dem Start steht fest, an welcher Kennzahl der Agent gemessen wird, etwa an der Fehlbestandsquote oder der Zeit der Disposition, und wo diese Kennzahl heute liegt. Nach einer festen Frist im Betrieb, üblich sind 90 Tage, wird nachgemessen. Das diszipliniert alle Beteiligten. Ohne Zielgröße endet jedes Agenten-Projekt in derselben Diskussion: Die einen finden, es funktioniert, die anderen finden, es funktioniert nicht, und niemand kann es belegen.

Der Unterschied liegt also weniger im Werkzeug als in der Reihenfolge. Wie sich die Reihenfolge für einen konkreten Fall bestimmen lässt, zeigt unser Beitrag zum agentischen Replenishment an dem Anwendungsfall, der im Handel am häufigsten den Anfang macht.

Wie senken Sie das Risiko vor der Investition?

Mit einer Messung statt einer Meinung. Ob Ihre Daten einen Agenten aushalten, lässt sich vorab feststellen: mit Belegen aus den Systemen, nach einem offenen Standard, in drei Wochen. Das Ergebnis ist ein Zuverlässigkeits-Wert für Ihren Anwendungsfall, der benannte Engpass und ein Maßnahmenplan mit Reihenfolge. Fällt die Messung gut aus, starten Sie mit Rückendeckung. Fällt sie schlecht aus, wissen Sie es vor der Investition und nicht nach sechs Monaten Pilotbetrieb.

Die Kriterien und Formeln hinter der Messung sind öffentlich dokumentiert, nachlesbar auf der Methode-Seite. Wichtig ist dabei die Ergebnisoffenheit: Eine ehrliche Prüfung darf auch ergeben, dass Ihr Wunsch-Anwendungsfall die Investition heute nicht wert ist. Diese Antwort nach drei Wochen ist unbequem, aber günstig. Ein abgeschalteter Agent ist die teuerste Art, den Zustand der eigenen Daten kennenzulernen. Es geht auch vorher.

Quellen

QuelleEinordnung
Gartner · Prognose zu agentischen KI-Projekten, Juni 2025
Gartner · Lack of AI-ready data puts AI projects at risk, Februar 2025
RAND Corporation · The Root Causes of Failure for AI Projects, 2024
S&P Global Market Intelligence via CIO Dive · AI project failure rates on the rise, März 2025
prodct · Beispiel-Report ACME Inc. (fiktive Daten)
Produktionsreife-Audit

Drei Wochen, ergebnisoffen.

Das Produktionsreife-Audit misst, ob Ihre Daten für Ihren Anwendungsfall ausreichen. Mit Belegen aus Ihren Systemen, nicht mit Selbsteinschätzung.

Zum Produktionsreife-Audit
Audit anfragen 3 Wochen · ergebnisoffen