Ein Anbieter zeigt dir eine Demo. Sie liest Rechnungen, sortiert E-Mails oder beantwortet Kundenanfragen, je nachdem, was du brauchst. Sie läuft makellos: schnell, sauber, kein einziger Fehler. Du unterschreibst, ihr hängt sie an euren echten Betrieb, und drei Wochen später sagt dir jemand aus dem Team, dass man ihr nicht trauen kann. Der Anbieter schwört, es sei dasselbe Produkt. Er hat recht, und genau das ist das Problem: Zwischen Demo und Produktion hat sich nicht das System geändert, sondern das Material, an dem es getestet wurde.
Die These in einer Zeile: Die Demo scheitert nicht aus böser Absicht, sondern an der Auswahl der Stichprobe. Die Dokumente, die du geschickt hast, waren die sauberen, die Tickets die gut geschriebenen, und die Fälle, die deinen Business Case kippen, sind nie hineingekommen. Was du gesehen hast, war kein Test, sondern eine Probe.
Warum die KI-Demo nicht der Produktion entspricht
Weil jemand die Fälle ausgesucht hat. Fast immer du, mit den besten Absichten. Man bittet dich um Beispiele für den Test, und du schickst, was griffbereit ist: die gut gescannten Dokumente, die Tickets in vollständigen Sätzen, die Kunden, die den Prozess genau so durchlaufen, wie du ihn aufs Papier gezeichnet hast. Damit sieht jedes vernünftige System gut aus. Und der Anbieter bereitet sich damit vor: Er passt den Prompt an, schärft die Regeln, löst die Eigenheiten, die auftauchen. Wenn die Demo kommt, kennt das System die Prüfungsfragen längst.
Produktion ist nicht diese Stichprobe. Sie ist die ganze Verteilung samt ihren Rändern: der schiefe Scan, die dreizeilige Mail ohne Kontext, der Kunde mit zwei Firmierungen, die Korrekturrechnung, die freitagnachmittags eintrifft. Ein System, das nur am leichten Teil der Verteilung bewertet wurde, ist nicht erprobt, sondern einstudiert. Es ist dieselbe Logik, warum eine Trefferquote in Produktion nicht reicht: Die Zahl hängt davon ab, welche Fälle in die Rechnung eingehen.
Was eine Demo auslässt, und warum genau das Geld kostet
- Die hässlichen Dokumente. Handyfotos, verkehrt herum gescannte PDFs, Tabellen, die über zwei Seiten gerissen sind, Formate von vor fünf Jahren, die nie jemand abgeschaltet hat.
- Die schlecht geschriebenen Nachrichten. Halbe Sätze, zwei Sprachen in einer Mail, Verweise auf ein früheres Gespräch, das das System nicht kennt.
- Die Ausnahmen im Geschäft. Der Kunde mit Sonderkonditionen, die Bestellung, die zwei Preislisten mischt, der Fall, den nur die Person kennt, die seit zehn Jahren auf der Stelle sitzt.
- Das Seltsame und das Feindliche. Leere Eingaben, Dubletten, Anhänge, die nicht sind, was sie vorgeben, jemand, der die Grenzen des Systems austestet.
Es gibt etwas, das schlimmer ist als die Häufigkeit: Seltene Fälle kosten nicht dasselbe wie normale. Ein Fehler bei einem einfachen Ticket ist in einer Minute korrigiert. Ein Fehler in der Rechnung eines großen Kunden oder in der Antwort, die bei der Geschäftsführung landet, zahlst du mit Vertrauen. Deshalb sagt eine perfekte Demo auf den leichten Fällen wenig über die echten Kosten des Echtbetriebs.
Die Zahl, die zählt, ist nicht der Durchschnitt, sondern das schlechte Ende
Wenn man dir sagt, das System liege „fast immer“ richtig, frag: bei was? Ein hoher Durchschnitt kann verbergen, dass die leichten Fälle fast alle stimmen und die schweren fast alle nicht, und dass dein Business Case an den schweren hängt. Wenn sich der Prozess lohnt, weil heute jemand Stunden an Ausnahmen verliert, spart dir ein System, das löst, was ohnehin leicht war, nichts. Schau auf das schlechteste Stück: was bei den kompliziertesten Fällen passiert, welche Fehler es macht und wie oft, welche es selbst bemerkt und welche beim Kunden ankommen. Genau das verlangt die Leistungsmessung deiner Automatisierungen vom ersten Tag an.
Was du statt einer Demo verlangen solltest: eine Kaufmethode in fünf Schritten
- Eine Zufallsstichprobe, von dir gezogen. Nimm die letzten echten Fälle eines Zeitraums, ungefiltert und ungeputzt, und zeig sie dem Anbieter nicht vor dem Test. Sucht er sie aus, bist du wieder am Anfang.
- Mit den seltenen Fällen drin. Ergänze von Hand die, die am meisten wehtun: die eskalierten, die als Beschwerde endeten, die nur eine Person im Team lösen kann.
- Kriterium, bevor du das Ergebnis siehst. Leg schriftlich fest, welcher Fehler bei welchem Falltyp akzeptabel ist und welcher nie. Setzt du die Latte erst danach, verteidigst du am Ende, was du schon gesehen hast.
- Lies die Fehler, nicht nur die Prozentzahl. Prüfe die gescheiterten Fälle von Hand. Zufällig verteilte Fehler und Fehler, die sich immer beim gleichen Kundentyp häufen, sind verschiedene Probleme, auch wenn der Prozentwert derselbe ist.
- Teste mit deinen Daten, in deiner Umgebung. Mit deinen Berechtigungen, deinen Formaten und deinen angebundenen Systemen. Eine Qualitätsbewertung von KI-Agenten gibt es genau dafür, diesen Test bei jeder Änderung zu wiederholen, nicht nur vor dem Kauf.
Wann die Demo doch hilft
Es ist nicht alles Misstrauen. Eine Demo hilft, um zu sehen, ob die Oberfläche zur Arbeitsweise deines Teams passt, ob die Integrationen wirklich existieren und ob der Ablauf Sinn ergibt. Sie reicht auch, wenn ein Fehler wenig kostet und sich rückgängig machen lässt: Ein Entwurf, den eine Person vor dem Versand prüft, braucht kein Evaluierungsprotokoll. Die Demo beantwortet „Geht das überhaupt?“. Sie beantwortet nicht „Hält das in meinem Betrieb?“, und genau dafür unterschreibst du.
Was du aus der Reaktion des Anbieters lesen kannst
Wenn du den Test mit Zufallsstichprobe und schwierigen Fällen vorschlägst, sagt dir die Reaktion mehr als die Demo. Ein seriöser Anbieter geht darauf ein, hilft dir beim Aufsetzen und zeigt dir die Fehler neben den Erfolgen. Wer anfängt, über die Stichprobe zu verhandeln, „einen repräsentativen Fall“ zu verlangen oder das Erfolgskriterium zu ändern, hat dir gerade gezeigt, wie die Zusammenarbeit aussieht, wenn in der Produktion etwas kaputtgeht.
Wenn du Optionen vergleichst, liefert dir wie du ein KI-Automatisierungstool auswählst die übrigen Kriterien. Und wenn du schon einen Pilot erlebt hast, der glänzte und nie in Produktion ankam, erzählt die Demo ist nicht das Projekt, was nach der Unterschrift kommt.
Der Satz zum Mitnehmen: Eine Demo beweist nicht, dass das System funktioniert, sie beweist, dass es eine Menge von Fällen gibt, für die es funktioniert. Deine Aufgabe vor der Unterschrift ist herauszufinden, welche Fälle nicht in dieser Menge liegen.