Die Demo lief perfekt. Der Agent hat jedes Beispiel korrekt behandelt, die Ausgaben sahen richtig aus, und das Team verließ den Raum zuversichtlich. Sechs Monate später erfordert das Live-System konstante Aufsicht und produziert Ausgaben, denen das Team nicht vertraut. Nichts ist kaputt gegangen — aber nichts funktioniert so, wie die Demo es vermuten ließ. Die Lücke zwischen einer erfolgreichen Demo und einem zuverlässigen Live-System ist keine Überraschung. Sie ist strukturell.
Warum die Demo-Umgebung grundlegend anders ist als die Produktion
Eine Demo läuft auf Eingaben, die der Präsentator ausgewählt hat. Diese Eingaben wurden ausgewählt, weil der Agent sie gut behandelt — sie repräsentieren den Workflow in seiner saubersten Form, nicht in seiner häufigsten.
Echte Produktionssysteme verarbeiten, was ankommt. Das umfasst Eingaben mit fehlenden Feldern, inkonsistenter Formatierung, mehrdeutigem Kontext und Randfällen, die niemand in die Demo aufgenommen hat. Der Agent wurde nie auf diesen Eingaben getestet. In der Demo existierten sie nicht.
Das ist keine Täuschung. Der Präsentator ist möglicherweise nicht einmal bewusst, wie unrepräsentativ die Eingaben sind. Die Demo zeigt, was der Agent unter idealen Bedingungen leisten kann. Sie zeigt nicht, wie der Agent sich verhält, wenn die Bedingungen nicht ideal sind.
Wie sich die Demo-Umgebung von der Produktion unterscheidet
Die Lücke zwischen einem Demo und einem Live-System ist keine Frage des Ausmaßes. Es ist ein struktureller Unterschied zwischen zwei Betriebsumgebungen. Die Dimensionen der Lücke zu verstehen macht es leichter zu beurteilen, was ein Demo tatsächlich zeigt — und was nicht.
| Dimension | Demo | Produktion |
|---|---|---|
| Eingabedaten | Saubere, vollständige Datensätze, die zur Workflow-Beschreibung passen | Was auch immer ankommt — fehlende Felder, inkonsistentes Format, unerwartete Werte |
| Eingabevolumen | 3–10 Beispiele, einzeln verarbeitet | Dutzende bis Hunderte pro Tag, gleichzeitig verarbeitet |
| Edge Cases | Abwesend — Eingaben werden ausgewählt, um sie zu vermeiden | Vorhanden und über Zeit zunehmend |
| System-Anbindungen | Gemockt oder für die Demo-Umgebung vorkonfiguriert | Live-APIs mit Authentifizierungsanforderungen, Rate-Limits und Schema-Änderungen |
| Fehlerbehandlung | Prompt wird umgeschrieben und Demo erneut gestartet | Fehler muss automatisch eskalieren oder behandelt werden |
| Konsequenzen von Fehlern | Keine — Demo-Ausgabe wird verworfen | Echte Kunden, echte Datensätze, echte Reputation |
| Wartung | Nicht anwendbar | Aktiver monatlicher Review erforderlich |
Jede Dimension in dieser Tabelle repräsentiert eine Klasse von Problemen, die der Demo nicht aufdecken kann — nicht weil der Demo unehrlich war, sondern weil die Demo-Umgebung strukturell so gestaltet ist, dass sie diese Probleme entfernt.
Wie echte Geschäftsdaten aussehen
Eine Demo, die mit drei vorbereiteten Beispielen funktioniert, kann nicht auf ein Produktionssystem übertragen werden, das Hunderte realer Eingaben verarbeitet. Die richtige Frage nach einer erfolgreichen Demo ist nicht "hat es funktioniert?" — sondern "was würde das brechen?"
Jedes Unternehmen sammelt Daten auf Weisen, die nie für maschinelle Verarbeitung ausgelegt wurden. CRM-Datensätze haben leere Felder, Felder mit Abkürzungen, die das Team versteht, ein System aber nicht, oder Felder, die inkonsistent über verschiedene Teammitglieder aktualisiert wurden. E-Mails kommen mit Betreffzeilen an, die nicht mit ihrem Inhalt übereinstimmen. Datumsangaben werden von verschiedenen Absendern unterschiedlich formatiert.
Eine Demo-Eingabe ist in der Regel ein vollständiger, sauberer Datensatz, der genau so aussieht, wie die Workflow-Beschreibung es sagte. Echte Eingaben weichen ständig davon ab — nicht weil etwas schiefgelaufen ist, sondern weil Menschen Formulare nicht so ausfüllen, wie Ingenieure sie entworfen haben.
Die Fragen, die man nach einer erfolgreichen Demo stellen sollte
Die Demo hat funktioniert, weil die Eingaben sauber waren. Ihre Daten sind es nicht.
Drei Fragen liefern ein klareres Bild davon, wie die Produktion tatsächlich aussehen wird:
Was waren die Eingaben? Fragen Sie, die Rohdaten zu sehen, die der Agent verarbeitet hat. Wenn die Eingaben identisch formatiert sind, entspricht das wahrscheinlich nicht Ihren tatsächlichen Geschäftsdaten. Fragen Sie, was passiert, wenn ein Feld fehlt oder inkonsistent ausgefüllt ist.
Was würde dazu führen, dass das scheitert? Jeder ehrliche Implementierer kann die Fehlerarten des Systems nennen, das er gebaut hat. Wenn die Antwort "es behandelt alles" lautet, wurde die Demo nicht mit repräsentativen Daten erstellt.
Wie behandelt das System Eingaben, für die es nicht ausgelegt wurde? Zeigen Sie dem Agenten eine Eingabe, die teilweise falsch ist — ein fehlendes Feld, ein Datum in einem anderen Format, ein mehrdeutiger Wert. Beobachten Sie, was passiert. Das ist informativer als zehn erfolgreiche Demo-Läufe.
Wie man einen Agenten vor der Produktion testet, nicht während
Ein Agent, der nur gegen kuratierte Demo-Eingaben getestet wurde, begegnet seiner ersten echten Eingabevarianz in der Produktion. Vor dem Launch unter realen Bedingungen zu testen ist das, was Implementierungen, die halten, von solchen unterscheidet, die konstante Nachbesserung erfordern.
Eine echte Eingabe-Stichprobe ziehen
Vor dem Testen des Agenten 50–100 echte Eingaben aus dem Workflow ziehen, für den der Agent gebaut wird. Nicht auf Qualität auswählen. Eine aufeinanderfolgende Stichprobe aus dem Live-System nehmen — die letzten 50 E-Mails, die letzten 100 CRM-Datensätze, die letzten 50 Support-Tickets. Diese Stichprobe enthält die Inkonsistenzen, fehlenden Felder und Edge Cases, die der Demo nie gezeigt hat.
Den Agenten gegen die gesamte Stichprobe laufen lassen
Die gesamte Stichprobe verarbeiten, keine kuratierte Teilmenge. Festhalten, wie viele Eingaben der Agent beim ersten Durchgang korrekt behandelt, wie viele er als unsicher markiert und wie viele er falsch behandelt. Die Korrekt-beim-ersten-Durchgang-Rate und die Markierungsrate sind die Basis-Metriken für die Überwachung des Live-Systems.
Jede markierte und falsch behandelte Eingabe überprüfen
Für jede Eingabe, die der Agent markiert oder falsch behandelt hat: Was war das spezifische Versagen — fehlende Daten, mehrdeutiger Kontext, ein Eingabemuster, das der Brief nicht abdeckt? Jedes identifizierte Muster repräsentiert entweder ein Brief-Update (wenn das Muster behandelt werden soll) oder einen bestätigten Ausnahmepfad (wenn es manuell eskaliert werden soll).
Den Brief vor dem Launch aktualisieren
Jedes im Review identifizierte Muster adressieren: Brief aktualisieren, um Muster abzudecken, die der Agent behandeln soll; Eskalationspfad für Muster definieren, die markiert werden sollen; Muster dokumentieren, die abgelehnt werden sollen. Der Brief ist nicht fertig, bis der Agent die echte Eingabe-Stichprobe korrekt verarbeiten kann.
Erfolgskriterien vor dem Launch festlegen
Die Basis-Metriken aus dem echten Eingabe-Testing festhalten: Korrekt-beim-ersten-Durchgang-Rate, Markierungsrate, Falschbehandlungsrate. Das sind die Benchmarks, gegen die das Live-System überwacht wird. Ein Live-System, das unter diesen Benchmarks liegt, degradiert — es funktioniert nicht normal.
Was produktionsreife Implementierungen anders machen
Implementierungen, die für die Produktion gebaut werden, beginnen mit echten Daten, nicht mit konstruierten Beispielen. Der erste Schritt ist nicht das Bauen des Agenten — es ist die Überprüfung einer Stichprobe tatsächlicher Eingaben, um die Varianz zu verstehen, mit der der Agent konfrontiert wird.
Diese Überprüfung produziert ein Scoping-Dokument: eine Liste jedes Eingabemusters, das der Agent behandeln soll, jedes Musters, das er ablehnen soll, und was mit Eingaben passiert, die in keine der beiden Kategorien fallen. Das Demo-Äquivalent davon ist ein handverlesener Beispielsatz. Das Produktions-Äquivalent ist ein Ausnahme-Handler.
Ein Agent, der gegen echte Eingabevarianz gebaut wird, verhält sich in der Produktion vorhersehbar, weil er vor dem Launch gegen Unvorhersehbarkeit getestet wurde. Die Lücke zwischen Demo und Live-System verengt sich nicht, weil der KI klüger ist, sondern weil die Implementierung mit dem Wissen gebaut wurde, dass die Lücke existiert.
Häufig gestellte Fragen
Warum sehen KI-Agenten-Demos besser aus als Live-Systeme?
Demos verwenden Eingaben, die der Präsentator ausgewählt hat — vollständige, saubere Datensätze, die der Agent gut verarbeitet. Die Produktion verarbeitet, was tatsächlich ankommt: fehlende Felder, inkonsistente Formatierung und Randfälle, die niemand antizipiert hat. Die Demo zeigt die Fähigkeit unter idealen Bedingungen — nicht das Verhalten unter echten.
Welche Fragen sollte ich nach einer KI-Agenten-Demo stellen?
Drei Fragen: Was waren die tatsächlichen Eingaben — sind sie repräsentativ für Ihre echten Daten? Was würde dazu führen, dass das scheitert — kann der Implementierer konkrete Fehlerarten nennen? Wie behandelt das System Eingaben, für die es nicht ausgelegt wurde — zeigen Sie ihm eine unvollständige oder fehlerhafte Eingabe und beobachten Sie, was passiert.
Was ist der Unterschied zwischen Demo-Daten und Produktionsdaten?
Demo-Daten sind auf Korrektheit ausgewählt — vollständige Datensätze, die genau der Workflow-Beschreibung entsprechen. Produktionsdaten spiegeln wider, wie Menschen Systeme tatsächlich nutzen: leere Felder, nur dem Team verständliche Abkürzungen, inkonsistent formatierte Datumsangaben, Betreffzeilen, die nicht zum E-Mail-Inhalt passen. Die Lücke zwischen beiden ist vorhersehbar und strukturell — kein Zufall.
Was macht eine KI-Agenten-Implementierung produktionsreif?
Eine produktionsreife Implementierung beginnt mit echten Eingabe-Stichproben, nicht mit konstruierten Beispielen. Sie erzeugt ein Scoping-Dokument, das jedes Eingabemuster auflistet, das der Agent behandelt, jedes Muster, das er ablehnt, und was mit Eingaben außerhalb beider Kategorien geschieht. Sie wird vor dem Launch gegen unvorhersehbare Eingaben getestet — und die Kontrollschicht wird entworfen, bevor eine einzige Zeile Agenten-Logik geschrieben wird.
Wie viele Eingaben sollten vor dem Launch zum Testen eines KI-Agenten verwendet werden? Mindestens 50 echte Eingaben, als aufeinanderfolgende Stichprobe aus dem Live-Workflow genommen — nicht nach Qualität ausgewählt. Das Ziel ist, die Inkonsistenzen, fehlenden Felder und Edge Cases einzuschließen, die die kuratierten Demo-Daten ausgeschlossen haben. Das Testen gegen 50 echte Eingaben vor dem Launch ist prädiktiver für das Produktionsverhalten als 500 Tests mit kuratierten Demo-Daten.
Was ist die Korrekt-beim-ersten-Durchgang-Rate, und warum ist sie wichtig? Die Korrekt-beim-ersten-Durchgang-Rate ist der Anteil der Eingaben, die der Agent korrekt behandelt, ohne menschliche Korrektur oder Markierung als unsicher zu erfordern. Es ist die Basis-Metrik für die Überwachung eines Live-Agenten. Wenn diese Rate sechs Monate nach dem Launch ohne entsprechende Änderung des Eingabevolumens sinkt, degradiert der Agent — und die Degradierung kann durch monatliche Verfolgung dieser Metrik erkannt werden.
Sollte man einer KI-Agenten-Demo eines potenziellen Implementierungspartners vertrauen? Ein Demo ist Beweis für Fähigkeit, nicht für Lieferfähigkeit. Bitten Sie darum, die Roheingaben des Demos zu sehen, und fragen Sie den Präsentator, die drei häufigsten Fehlerarten des Systems zu beschreiben, das er gebaut hat. Ein Implementierungspartner, der konkrete Fehlerarten ehrlich beschreiben kann, ist vertrauenswürdiger als einer, der behauptet, das System behandele alles. Fragen Sie auch, ob er bereit wäre, den Demo mit einer Stichprobe Ihrer tatsächlichen Geschäftsdaten statt seiner vorbereiteten Beispiele durchzuführen — diese Anfrage allein unterscheidet erfahrene Implementierer von denen, die nur Demos ausgeliefert haben.