Die meisten KI-Agenten-Projekte sterben nicht in der Produktion. Sie sterben in den drei Monaten zwischen einer vielversprechenden Demo und einem Business Owner, der die E-Mails des Anbieters still und leise unbeantwortet lässt.
Die Demo hat funktioniert. Das Konzept war solide. Irgendwo zwischen Kickoff und Launch hat die Sache einfach… gestockt. Wenn Sie ein Agentenprojekt planen — oder eines retten möchten, das bereits ins Stocken geraten ist — bringt es mehr, zu verstehen, warum KI-Agenten-Projekte scheitern, als jeder Technologieleitfaden. Die Probleme sind fast nie technischer Natur.
Die vier Fehlermuster, die wir immer wieder sehen
Nach der Entwicklung und dem Einsatz massgeschneiderter KI-Agenten für KMU in der Schweiz und in Europa tauchen immer wieder dieselben vier Versagensmodi auf — mit einer unangenehmen Regelmässigkeit.
1. Ein Scope, den niemand wirklich definieren konnte
Das häufigste Problem. Ein Projekt startet mit einem Brief der Art: „Wir möchten einen KI-Agenten, der Kundenanfragen bearbeitet.” Keine Angaben zum Eingangsvolumen, keine Definition, was „bearbeitet” bedeutet, keine Liste von Sonderfällen, keine Einigung darauf, was der Agent tun soll, wenn er nicht weiterhelfen kann.
Ohne einen präzisen Scope setzt jedes Gespräch neu an. Der Anbieter interpretiert „bearbeiten” als Umleiten; der Kunde meint Lösen. In der vierten Woche baut jede Seite etwas anderes. Das Projekt weitet sich aus, um alle denkbaren Szenarien abzudecken, die Kostenschätzungen vervierfachen sich, und irgendwann zieht jemand den Stecker.
So sollte es aussehen: Ein Scope-Dokument, das die genauen Auslöseereignisse benennt, die Datenquellen, auf die der Agent zugreifen darf, die Eskalationsbedingungen und die Definition eines erfolgreichen Ergebnisses — alles vereinbart und unterzeichnet, bevor eine einzige Zeile Code geschrieben wird.
2. Kein Process Owner auf der Business-Seite
Technisch versierte Anbieter können genau das bauen, was Sie spezifizieren — aber sie können internes Wissen nicht ersetzen. Jedes KI-Agenten-Projekt braucht auf der Kundenseite jemanden, der den tatsächlichen Arbeitsablauf kennt, Fragen zu Randfällen beantworten kann und die Befugnis hat, Entscheidungen zu treffen, wenn Anforderungen kollidieren.
Wenn diese Person nicht existiert — oder auf dem Papier existiert, aber zu beschäftigt ist — driftet das Projekt. Entwickler treffen Annahmen. Annahmen häufen sich. Wenn jemand auf Führungsebene das Ergebnis prüft, verarbeitet der Agent 60 % der Fälle korrekt, und niemand weiss, ob das akzeptabel ist oder nicht.
Prozessverantwortung ist keine Teilzeitaufgabe. Planen Sie für ein Projekt von nennenswertem Umfang zwei bis vier Stunden pro Woche von jemandem ein, der den zu automatisierenden Prozess tatsächlich führt.
3. Kein Evaluierungsrahmen vor dem Entwicklungsstart
Woran erkennen Sie, dass der Agent funktioniert? Wenn Sie diese Frage vor Projektbeginn nicht beantworten können, werden Sie es nach dem Launch ebenfalls nicht können.
Teams, die auf das Evaluierungsdesign verzichten, erhalten Agenten in der Produktion, denen niemand vertraut, die niemand benchmarkt und die schliesslich niemand mehr nutzt. „Im Testing schien es zu funktionieren” ist kein Qualitätsmerkmal. Genauso wenig wie „Die Nutzer haben sich noch nicht beschwert.”
Ein minimaler Evaluierungsrahmen beantwortet drei Fragen: Wie sieht korrektes Verhalten an einem repräsentativen Sample realer Eingaben aus, wer prüft Randfälle, und woran erkennt man eine Regression? Einen tieferen Einblick in die Praxis bietet KI-Agenten testen: Wie Evaluierungen Automatisierung zuverlässig halten.
4. Pilot-Erfolg mit Produktionsreife gleichsetzen
Ein Pilot, der mit 50 ausgewählten Testfällen funktioniert, ist kein Agent, der bereit ist, 5.000 Live-Interaktionen zu verarbeiten. In der Lücke zwischen beiden stossen die meisten Projekte auf eine unerwartete Wand.
Echte Produktion bringt: Eingaben, an die niemand beim Testen gedacht hat, Integrationsfehler unter Last, Latenz, die bei geringem Traffic noch akzeptabel war, und Nutzer, die mit dem System auf Arten interagieren, die das Design-Team nie vorhergesehen hat. Ein Agent, der in einer kontrollierten Umgebung einwandfrei funktionierte, kann am Montagmorgen zum Risiko werden.
Der Übergang vom Pilot zur Produktion braucht eine eigene Projektphase, ein eigenes Budget und eigene Erfolgskriterien. Teams, die den Go-live als Ziellinie behandeln, merken meist schnell, warum das ein Fehler war.
Warum diese Fehler zusammen auftreten
Keines der vier oben beschriebenen Muster betrifft das KI-Modell, das Framework oder die Infrastruktur. Es handelt sich um organisatorische und prozessuale Probleme, die ein technologisches Kostüm tragen.
Das ist wichtig, denn es verlagert, wo das Risiko tatsächlich liegt. Die Frage „Welches KI-Framework sollen wir verwenden?” ist weit weniger bedeutsam als „Haben wir definiert, wie das Ergebnis aussieht?” Ein Projekt auf dem richtigen Framework mit vagem Scope scheitert. Ein Projekt auf einem einfacheren Stack mit rigorosem Scope und einem starken Process Owner wird ausgeliefert.
Dennoch können schlechte technische Entscheidungen organisatorische Fehler verstärken. Ein Agent, der auf einer No-Code-Plattform aufgebaut wurde — bei der monatliche Ausführungslimits oder Preise pro Interaktion im Produktionsvolumen bindend werden können — lässt Ihnen keinen Spielraum, Prozessprobleme unterwegs zu korrigieren. Wenn Sie Build-vs.-Buy-Entscheidungen abwägen, decken KI-Agenten in Ihrem Unternehmen implementieren: Eine phasenweise Roadmap und Den ROI von KI-Agenten messen: Ein Framework für KMU die Bewertungslogik ab, die jeder technischen Entscheidung vorausgehen sollte.
Eine De-Risking-Checkliste für Auftraggeber
Gehen Sie diese Liste durch, bevor Sie ein KI-Agenten-Projekt freigeben. Wenn Sie eine Frage nicht beantworten können, ist das eine Lücke, die geschlossen werden muss — kein Detail, das man später regeln kann.
Scope und Anforderungen
- Ist die Auslösebedingung für den Agenten eindeutig? (Was startet die Interaktion?)
- Gibt es eine schriftliche Liste, was der Agent tun darf und was nicht?
- Sind die Eskalationsbedingungen definiert? (Wann übernimmt ein Mensch, und wie?)
- Ist die Erfolgsdefinition schriftlich vereinbart — nicht „funktioniert gut”, sondern messbar?
Prozessverantwortung
- Gibt es einen namentlich benannten Business-seitigen Process Owner mit Entscheidungsbefugnis?
- Hat diese Person eine realistische Stundenanzahl pro Woche für das Projekt zugesagt?
- Hat sie Zugang zu den echten Workflow-Daten — nicht zu einer aufbereiteten Demo-Version?
Evaluierung
- Verfügen Sie vor dem Launch über ein repräsentatives Set realer Eingaben zum Testen?
- Gibt es eine vereinbarte Schwelle dafür, was gute Performance bedeutet?
- Wer prüft Fehlerfälle, und wie oft?
Planung Pilot-zu-Produktion
- Gibt es ein separates Budget und eine separate Timeline für die Nachpilot-Härtung?
- Wurde der Agent unter realistischem Eingangsvolumen getestet, nicht nur mit ausgewählten Samples?
- Gibt es einen Rollback-Plan, falls das Produktionsverhalten nachlässt?
Anbieterverantwortung
- Ist der Anbieter für die Lieferung definierter Ergebnisse verantwortlich — oder nur für geleistete Stunden?
- Gibt es eine definierte Phase des Post-Launch-Supports?
- Sind Preisgestaltung und Prozesse für Scope-Änderungen klar geregelt?
Wenn Sie einschätzen möchten, wie gut Ihre Organisation aufgestellt ist, bevor Sie starten, behandelt Ist Ihr Unternehmen bereit für KI-Agenten? die Bereitschaftsdimensionen ausführlicher.
Die Anbieterseite der Gleichung
Eine De-Risking-Checkliste hilft Ihnen als Auftraggeber — aber sie funktioniert nur, wenn der Anbieter, den Sie wählen, bereit ist, ehrlich damit umzugehen. Warnsignale auf Anbieterseite sind:
- Fixpreiszusagen, bevor der Scope definiert ist
- Eine Demo zeigen, bevor Ihr tatsächlicher Workflow verstanden wurde
- Keine Diskussion über Evaluierungs- oder Testmethodik
- Ein Übergabemodell, bei dem der Anbieter „baut und Sie einschult”, statt für die Produktionsperformance verantwortlich zu bleiben
Der richtige Anbieter verlangsamt das Tempo, bevor der Scope klar ist. Er stellt unbequeme Fragen zur Prozessverantwortung. Er schlägt einen Evaluierungsrahmen vor und macht ihn zum Vertragsbestandteil. Diese Reibung zu Beginn des Prozesses ist es, die das stille Ins-Stocken-Geraten drei Monate später verhindert.
Unser AI-Strategy-Service ist genau für diese Pre-Build-Phase gedacht — um Organisationen dabei zu helfen, den Scope zu definieren, Evaluierungskriterien festzulegen und herauszufinden, wo ein Agent tatsächlich Mehrwert schafft, bevor die Entwicklung beginnt.
Es gibt eine Version jedes gescheiterten KI-Agenten-Projekts, in der ein einziges ehrliches Gespräch — zwei Wochen vor Arbeitsbeginn — alles verändert hätte. Die Technologie muss fast nie verteidigt werden. Der Prozess schon.
Wenn Sie ein Projekt haben, das Sie gerade definieren, oder eines, das bereits ins Stocken geraten ist, buchen Sie ein 30-minütiges Gespräch mit dem Orange-ITS-Team. Wir sagen Ihnen ehrlich, ob die Grundlagen stimmen — und was sich ändern muss, wenn das nicht der Fall ist.