Die meisten KI-Agenten-Projekte scheitern nicht an der Technologie. Sie scheitern, weil der Rollout keine Struktur hatte: Jemand hat eine Demo gesehen, ein Use Case wurde aus dem Bauchgefühl heraus gewählt, an einen Entwickler übergeben — und das war es. Sechs Monate später ist der Agent in der Schublade, das Team ist skeptisch, und der CFO stellt Fragen, die niemand beantworten möchte.
Ein Phasenansatz ändert diese Rechnung. Er verwandelt eine Hochrisikowette in eine Folge kleinerer, handhabbarer Entscheidungen — jede gestützt auf die Erkenntnisse des vorherigen Schritts. Dieser Artikel führt Sie durch diese Abfolge: von der Identifikation des richtigen Kandidatenprozesses bis hin zum Betrieb von Produktionsagenten im grösseren Massstab.
Wenn Sie noch nicht bewertet haben, ob Ihre Organisation technisch und operativ bereit ist, starten Sie mit unserem Readiness-Check, bevor Sie hier weiterlesen.
Phase 1: Prozessauswahl — wo KI-Agenten wirklich Mehrwert schaffen
Nicht jeder Prozess ist ein guter Kandidat. Die rentablen teilen ein erkennbares Profil:
- Hohe Frequenz, niedrige Ausnahmequote. Der Prozess läuft dutzende oder hunderte Male pro Woche, und die meisten Fälle folgen einem vorhersehbaren Muster. Die Ausnahmebehandlung ist die Minderheit, nicht die Norm.
- Messbare Inputs und Outputs. Sie können klar definieren, was „korrekt erledigt” bedeutet — eine erteilte Antwort, ein geroutetes Dokument, ein aktualisierter Datensatz. Vage Erfolgskriterien machen eine Evaluation unmöglich.
- Toleranz für strukturierte Interaktion. Der Agent muss nicht bei sensiblen Themen improvisieren, rechtliche Urteile fällen oder emotional aufgeladene Gespräche ohne menschliche Rückversicherung führen.
Typische Kandidaten, die diesen Filter bestehen: Tier-1-Kundenanfragen, interne IT-Helpdesk-Tickets, Dokumentenklassifizierung und -weiterleitung, Bestellstatusanfragen, Terminvereinbarungen, Lead-Qualifizierungs-Follow-ups.
Prozesse, die verlockend wirken, aber oft früh scheitern: alles, was eine differenzierte regulatorische Auslegung erfordert, komplexe Verkaufsverhandlungen oder mehrstufige Genehmigungsketten, bei denen die Entscheidungslogik noch nirgendwo dokumentiert ist.
Nehmen Sie sich eine Woche Zeit für diese Phase, nicht eine Stunde. Sprechen Sie mit den Personen, die die Arbeit tatsächlich erledigen. Kartieren Sie den realen Prozess — nicht das idealisierte Flussdiagramm. Sie werden Ausnahmen, Randfälle und Datenlücken aufdecken, die den gesamten Piloten prägen.
Phase 2: Pilotdesign — enger Perimeter, reale Bedingungen
Ein Pilot ist keine Proof-of-Concept-Demo. Eine Demo beantwortet die Frage: „Kann diese Technologie das?” Ein Pilot beantwortet: „Funktioniert sie zuverlässig genug, in unserem konkreten Umfeld, um eine Ausweitung zu rechtfertigen?”
Dieser Unterschied bestimmt, wie Sie ihn gestalten:
Begrenzen Sie den Perimeter bewusst. Wählen Sie einen Teilprozess, nicht den gesamten Workflow. Wenn Sie den Kundensupport automatisieren, beginnen Sie mit einer einzigen Ticketkategorie — zum Beispiel Passwort-Resets oder Bestellstatus — nicht mit dem gesamten Posteingang. So können Sie präzise messen und Probleme beheben, ohne die gesamte Operation dem Risiko auszusetzen.
Führen Sie ihn parallel, nicht als Ersatz durch. Lassen Sie den Agenten in den ersten vier bis acht Wochen Anfragen bearbeiten, aber lassen Sie jeden Output vor der weiteren Verarbeitung von einem Menschen prüfen. Sie bauen einen Ground-Truth-Datensatz auf und fangen systematische Fehler ab, bevor sie Kunden erreichen.
Legen Sie Ihren Erfolgsschwellenwert fest, bevor der Pilot startet. Welche Genauigkeitsrate ist akzeptabel? Was ist Ihre maximale tolerierbare Antwortzeit? Welches Volumen an menschlicher Prüfung ist im grösseren Massstab nachhaltig? Diese Zahlen sollten vereinbart sein, bevor jemand die Ergebnisse betrachtet — nicht rückwirkend aus ihnen abgeleitet werden.
Instrumentieren Sie alles. Protokollieren Sie Inputs, Outputs, Latenz, Eskalationsraten und menschliche Korrekturraten. Ohne diese Daten ist die Evaluation Raterei.
Ein gut strukturierter Pilot dauert typischerweise vier bis acht Wochen und kostet einen Bruchteil eines vollständigen Deployments. Die Disziplin zahlt sich vielfach aus — sowohl durch die Vermeidung häufiger Fehlermodi als auch durch den Aufbau interner Zuversicht für das Rollout-Gespräch.
Phase 3: Evaluation — ehrliche Zahlen vor dem Skalieren
Wenn der Pilot endet, widerstehen Sie der Versuchung, Erfolg zu erklären, weil „die Leute zufrieden schienen”. Werten Sie die Zahlen aus.
Die Kennzahlen, die in dieser Phase zählen:
| Kennzahl | Was sie Ihnen sagt |
|---|---|
| Task-Abschlussrate | Hat der Agent abgeschlossen, was er begonnen hatte, oder an einen Menschen übergeben? |
| Genauigkeits- / Korrektheitssrate | Wie oft war der Output korrekt, ohne menschliche Korrektur? |
| Eskalationsrate | Welcher Anteil der Fälle erforderte eine menschliche Intervention? Ist das akzeptabel? |
| Latenz | Hat der Agent schnell genug geantwortet, um den bisherigen Prozess zu ersetzen? |
| Kosten pro Transaktion | Was kostet der Agent pro abgeschlossenem Task, alles eingerechnet? |
Vergleichen Sie diese Werte mit Ihrer Baseline vor dem Pilot. Wenn Sie keine Baseline-Zahlen für den manuellen Prozess haben, ist das eine Lücke, die Sie jetzt schliessen müssen — und ein nützliches Argument dafür, warum eine Messinfrastruktur vor jedem KI-Projekt wichtig ist.
Zwei Ergebnisse, auf die Sie sich ehrlich vorbereiten sollten:
- Die Zahlen reichen aus, um fortzufahren. Definieren Sie „produktionsreife” Kriterien, identifizieren Sie, welche Lücken vor dem vollständigen Rollout geschlossen werden müssen, und entwerfen Sie den Erweiterungsplan.
- Die Zahlen reichen nicht aus. Diagnostizieren Sie, bevor Sie entscheiden. Liegt das Defizit im Modell, im Prompt-Design, in der Datenqualität oder in der Prozessdefinition? Ein behebbarer Pilot ist es wert, behoben zu werden. Ein fundamental falsch eingegrenzter ist ein Signal, den Use Case zu wechseln — nicht härter zu drücken.
Für einen strukturierten Ansatz zur Renditeberechnung siehe unser ROI-Framework für KMUs.
Phase 4: Rollout — vom Pilot in den Produktionsbetrieb
Wenn der Pilot Ihre Schwellenwerte überschritten hat, bringt der Produktionsrollout eine Komplexität mit sich, die der Pilot bewusst vermieden hatte: höhere Volumen, mehr Randfälle, Integration in Live-Systeme und reale Verantwortung, wenn etwas schiefläuft.
Drei Faktoren entgleisen Rollouts häufiger als jedes technische Problem:
1. Kein Owner. Nicht der Anbieter, nicht das Entwicklungsteam — jemand im Unternehmen selbst, der KPIs überwacht, Eskalationen bearbeitet und den Agenten stoppen kann, wenn die Qualität nachlässt.
2. Kein Fallback. Agenten fallen aus. Modelle gehen offline. APIs brechen ab. Ihr Rollout braucht einen dokumentierten Fallback — in der Regel der manuelle Prozess, den er ersetzte — der solange bereitgehalten wird, bis Sie monatelange stabile Betrieb nachweisen können.
3. Kein Governance-Framework. Wie oft wird der Output geprüft? Wer genehmigt Änderungen? Was löst einen Vorfall aus? Diese Fragen sind leicht aufzuschieben und teuer, wenn man sie reaktiv beantworten muss — zumal sie zunehmend durch den EU AI Act geformt werden, dessen Pflichten für bestimmte KI-Systemkategorien schrittweise bis 2026–2027 in Kraft treten. Ein Governance-Playbook, das vor dem Go-live geschrieben wurde, ist weit mehr wert als eines, das nach einem Vorfall entsteht.
Auf der technischen Seite beinhaltet der Produktionsrollout typischerweise die Anbindung des Agenten an Live-Datenquellen (CRM, ERP, Ticketing-Systeme), die Einrichtung von Monitoring und Alerting sowie die Festlegung einer regelmässigen Neubewertung. Wenn Ihr Pilot auf synthetischen oder anonymisierten Daten lief, planen Sie extra Zeit für Integrationstests mit Echtdaten vor dem Go-live ein.
Phase 5: Skalierung — Ausweitung auf weitere Prozesse und Teams
Ein einziger Agent im Produktionsbetrieb ist ein Proof Point. Eine Flotte von Agenten, die über Funktionen hinweg koordinieren, ist ein Wettbewerbsvorteil.
Skalieren bedeutet nicht einfach, denselben Agenten zu replizieren. Jeder neue Prozess braucht sein eigenes Scoping, seinen eigenen Pilot und seine eigene Evaluation — der Phasenansatz wiederholt sich in kleinerem Massstab mit schnelleren Zyklen, weil Ihr Team nun über Erfahrung verfügt.
Was sich beim Skalieren ändert:
- Die Orchestrierungskomplexität steigt. Agenten, die Arbeit aneinander übergeben, Speicher teilen oder gleichzeitig auf denselben Daten operieren, benötigen eine durchdachte Architektur — keine Improvisation. Frameworks wie LangGraph sind genau für diese Art von zustandsbehafteter Multi-Agenten-Koordination konzipiert.
- Die Monitoring-Anforderungen vervielfältigen sich. Jeder Agent ist ein neuer Ausfallpunkt. Eine Observability-Infrastruktur, die für einen Agenten optional wirkte, wird für fünf unerlässlich.
- Die Governance formalisiert sich. Informelle Entscheidungen, die für einen Agenten getroffen wurden, müssen zur Policy werden, wenn zehn Agenten laufen. Wer darf einen neuen Agenten deployen? Auf welche Daten darf ein Agent zugreifen? Welche Audit-Anforderungen gelten? Für Schweizer Organisationen legt das revidierte Datenschutzgesetz die Grundlage dafür fest, welche Personendaten Agenten bearbeiten und aufbewahren dürfen.
Organisationen, die erfolgreich skalieren, behandeln jeden neuen Agenten als Produkt — nicht als Projekt: mit einem Owner, einem Performance-Dashboard und einer Roadmap. Diese Disziplin trennt Teams, die dauerhaften Wert erschliessen, von jenen, die einen teuren Pilot-Friedhof anhäufen.
Für wen diese Roadmap passt — und wo sie nicht greift
Dieser Phasenansatz eignet sich am besten für:
- Organisationen mit einem klar identifizierten Kandidatenprozess und einigen Baseline-Daten zu dessen aktueller Performance
- Teams mit Executive-Buy-in für einen echten Pilot, nicht nur für eine Demo
- Unternehmen, die bereit sind, 8–16 Wochen zu investieren, bevor sie Ergebnisse im Produktionsmassstab erwarten
Er ist nicht der richtige Rahmen, wenn Sie noch bei der Frage „Sollen wir das überhaupt tun?” stehen. Diese Diskussion gehört in ein Readiness-Assessment und ein AI-Strategiegespräch, nicht in einen Rollout-Plan.
Er ist auch nicht der richtige Rahmen, wenn Ihr Ziel ist, schnell zu prototypisieren, um eine Hypothese zu validieren. Rapid Prototyping folgt seinem eigenen Playbook.
Die Kosten des Phasen-Überspringens
Die Versuchung ist immer dieselbe: komprimieren — den Pilot überspringen, direkt von der Auswahl zum Rollout übergehen und „in der Produktion lernen”. Manche Organisationen tun das. Die meisten werden zur Quelle der Gruselgeschichten: Projekte, die doppelt so viel gekostet und halb so viel geliefert haben.
Die Phasen dieser Roadmap sind kein Overhead. Sie sind der Mechanismus, mit dem Sie die Evidenz anhäufen, die Sie benötigen, um jede nachfolgende Entscheidung mit Sicherheit zu treffen. Entfernen Sie eine Phase, entfernen Sie die Evidenz — und die Sicherheit kollabiert zu Hoffnung.
Ein anschaulicher Vergleich: Eine Organisation, die einen sauber instrumentierten 6-Wochen-Pilot mit externer Begleitung durchführt, gibt typischerweise CHF 10.000–25.000 aus, bevor sie sich zu einem vollständigen Build verpflichtet. Wer direkt in die Produktion geht und drei Monate später fundamentale Scoping-Probleme entdeckt, sieht sich typischerweise mit Nachbesserungskosten konfrontiert, die diesen Betrag bei weitem übersteigen — zuzüglich des Vertrauensschadens durch ein sichtbares Scheitern.
Starten Sie mit dem Prozess, der am meisten zu gewinnen hat
Um KI-Agenten in Ihrem Unternehmen einzuführen, brauchen Sie kein Transformationsprogramm. Sie brauchen einen gut gewählten Prozess, einen strukturierten Pilot und die Disziplin, ehrlich zu evaluieren, bevor Sie skalieren.
Wenn Sie einen Kandidatenprozess im Blick haben und eine externe Einschätzung wünschen, ob das der richtige Startpunkt ist — oder wenn Sie Hilfe beim Design eines Pilots benötigen, der Ihnen echte Antworten statt einer beruhigenden Demo liefert — sprechen wir gerne 30 Minuten darüber.
Vereinbaren Sie ein Scoping-Gespräch mit Orange ITS und kommen Sie mit dem Prozess, dem aktuellen Volumen und dem Ergebnis, das Sie erzielen möchten. Das reicht für ein nützliches Gespräch.