Warum KI-Pilotprojekte nie in den Regelbetrieb kommen

Die meisten KI-Projekte scheitern nicht laut. Sie erhalten Applaus für eine Demo, laufen einige Wochen und werden dann still nicht mehr genutzt. Selten liegt es am Modell. Pilot und Regelbetrieb sind zwei unterschiedliche Produkte, und für das zweite plant kaum jemand ein Budget.

Was ein Pilot tatsächlich beweist – und was nicht

Ein Machbarkeitstest beantwortet genau eine Frage: Kann die Technologie mit ausgewählten Eingaben ein als korrekt erkennbares Ergebnis erzeugen? Das ist berechtigt und nützlich. Vor achtzehn Monaten waren viele heutige Selbstverständlichkeiten noch nicht zuverlässig möglich. Ein zweiwöchiger Test klärte das am schnellsten.

Problematisch sind die Schlüsse aus einem bestandenen Piloten. Eine Demo gilt oft als Beweis betrieblicher Tauglichkeit. Das ist sie nicht. Sie belegt nur Funktion in einem ausgewählten Realitätsausschnitt unter kontrollierten Bedingungen und Beobachtung des Pilotteams.

Denken Sie an einen Sprachagenten für eine Zahnarztpraxis. Der Pilot deckt Neupatiententermin, Verschiebung und Öffnungszeiten ab. Alles klappt. Nicht getestet wurden der Anruf von der Autobahn bei offenem Fenster, ein Wechsel ins Niederländische, eine bestimmte Versicherung, ein Lieferant mit Rechnungsnachfrage, Sprechen zwei Sekunden vor Ende der Begrüßung und „Ich möchte Marta sprechen“, weil Marta die Praxis leitet und seit neun Jahren bekannt ist.

Nichts davon ist exotisch. In einer realen Woche macht es den Großteil aus. Ein Pilot ohne solche Tests prüft den Verkaufsvortrag statt des Produkts. Der praktische Ratgeber zum Training eines KI-Sprachagenten zeigt die Arbeit, die erst mit echten Anrufenden sichtbar wird.

Im maschinellen Lernen ist das lange bekannt. Google-Forscher zeigten vor einem Jahrzehnt, dass Modellcode nur einen kleinen Teil eines produktiven Systems ausmacht. Datenaufnahme, Prüfung, Bereitstellung, Überwachung, Konfiguration und Prozesssteuerung dominieren. Die Arbeit betraf klassische ML-Abläufe, doch das Problem übertrug sich auf Sprachmodelle und Sprachagenten. Entscheidend war nie das Modell allein.

Warum die Demo funktioniert und der Einsatz nicht

Vier strukturelle Gründe machen Demos auf eine Weise einfach, die im Regelbetrieb nicht existiert.

Die Daten passen zum Idealfall. Demo-Eingaben sind sauber, vollständig und passend zum verkauften Fall. Reale Daten sind lückenhaft, widersprüchlich und voller unbekannten Kontexts: alte Telefonnummern, Doppelbuchungen oder eine seit Dienstag geänderte Preisliste, die nur in einem Postfach liegt.

Das Publikum ist nachsichtig. In der Demo wollen alle Erfolg. Niemand unterbricht, spricht gleichzeitig oder sucht gezielt Fehler. Kleine Probleme erklärt der Vortragende weg. Reale Nutzer tun das Gegenteil. Ein frustrierter Anrufer montags um 08:40 ist ein Härtetester ohne Anreiz zur Fairness.

Der Umfang ist nur ein Ausschnitt. Demos zeigen einen vollständigen Prozess. Betriebe führen aber keinen isolierten Prozess aus. Er berührt fünf weitere, drei undokumentiert und einer eine Person namens Karel, die „das einfach erledigt“.

Es steht nichts auf dem Spiel. Eine Demobuchung ist kein echter Termin. Niemand fährt deswegen zur Klinik. Sobald reale Folgen entstehen, sinkt die Fehlertoleranz. Was in der Demo charmant war, wird im Betrieb unzumutbar.

Sechs Fehlermuster, an denen KI-Piloten scheitern

In den Projekten, die wir sehen, wiederholen sich sechs Muster. Sie sind weder rätselhaft noch Modellierungsprobleme.

1. Nach dem Start ist niemand zuständig

Der Pilot hatte einen Befürworter: Betriebsleitung, neugierigen Gründer oder Marketingmanager. Es gab ein temporäres Mandat und Begeisterung. Nach dem Start endet das Mandat, die Person kehrt zur Hauptarbeit zurück. Niemand liest Transkripte oder bemerkt neue Fehlantworten nach einer Preisänderung. Niemand verantwortet das Ergebnis.

Das ist der stärkste Hinweis auf stilles Scheitern. Ein durchschnittliches wöchentlich betreutes System übertrifft ein hervorragendes unbetreutes: Das erste verbessert sich, das zweite weicht ab. Verantwortung darf intern oder extern liegen, braucht aber Namen, feste Zeit und Änderungsbefugnis.

2. Kein geplanter Eskalationsweg

Piloten planen den Erfolgsweg detailliert und behandeln Fehler nachträglich. Im Betrieb ist die Fehlerbehandlung das Produkt. Wie erkennt das System seine Grenzen, was tut es dann, wer übernimmt mit welchem Kontext und was geschieht bei Nichterreichbarkeit?

Ein System, das sagt „Dabei kann ich nicht helfen. Ich verbinde Sie jetzt mit einem Kollegen, der die Details bereits hat“, stärkt Vertrauen. Eine plausible Falschantwort ohne vorgesehenen Ausweg kann es dauerhaft zerstören. Planen Sie zuerst die Eskalation und darunter erst den Erfolgsablauf.

3. Keine Anbindung an die führenden Systeme

Das beendet mehr Einsätze als jeder andere technische Faktor. KI liest den Kalender, schreibt aber nicht? Jemand überträgt. Sie erfasst einen Interessenten, legt aber keinen CRM-Eintrag an? Jemand tippt erneut. Sie löst ein Ticket, schließt es aber nicht? Jemand gleicht nach.

Jede Lücke lässt den menschlichen Prozess parallel weiterlaufen. Das zeigt, dass KI optional ist. Nach sechs Wochen fragt jemand, warum Sie doppelte Arbeit bezahlen. Die Antwort lautet: Genau das tun Sie. Integrationstiefe unterscheidet Assistenten von Mitarbeitern. Diese Unterscheidung prägt unsere KI-Frontoffice-Arbeit.

4. Ohne Messung lässt sich kein Budget begründen

Verlängerungen begründen Sie mit Zahlen von vor dem Start. Ohne frühere Annahmequote, Angebotsnachfasszeit oder Terminausfälle bleibt Verbesserung eine Behauptung. Behauptungen verlieren gegen Kostensenkungen.

Darum sind Ausgangsdaten wichtig. Definieren Sie den Zeitraum und messen Sie Anrufe, Buchungen und abgeschlossene Aufträge vor dem Start. Unser Kundenprojekt VEGNA zeigt den Umsetzungsumfang, keinen verifizierten Vorher-nachher-Datensatz.

5. Sonderfälle wurden nie erfasst

Akzente, Hintergrundgeräusche, Unterbrechungen, Sprachwechsel, „Dienstag übernächste Woche“, ungewohnte Namensbuchstabierung, fremde Wartemusik und der kleine reale Anteil, der nicht mit Maschinen sprechen will. Im Piloten sind das Fußnoten. In Woche drei des Regelbetriebs füllen sie eine Tabelle.

Diese Fälle zu erfassen ist langweilig und unspektakulär, macht aber einen Großteil guter Umsetzung aus. Deshalb empfehlen wir echte historische Anrufaufnahmen oder Ticketverläufe statt erfundener Skripte. Sonderfälle lassen sich nicht erraten. Man muss sie beobachten.

6. Das Pilotteam löst sich auf

Ein Pilot wird oft von einer temporären Gruppe aus Betrieb, Technik, externer Beratung und Sponsor getragen. Sie kennt die Gründe der Konfiguration. Danach löst sie sich auf, die Beratung stellt Rechnung und der Kontext verschwindet. Drei Monate später versteht niemand mehr die Abendweiterleitung und wagt keine Änderung. Die falsche Regel bleibt.

Pilot und Regelbetrieb im Vergleich

Mit der folgenden Tabelle prüfen wir, ob „live“ wirklich Regelbetrieb bedeutet. Liegen die meisten Antworten in der mittleren Spalte, haben Sie keinen produktiven Einsatz, sondern eine weiterlaufende Demo.

Dimension	Pilotniveau	Für den Regelbetrieb ausgelegt
Zuständigkeit	Vorübergehender Projektbefürworter mit Nebenaufgabe	Benannte Verantwortung mit regelmäßiger Prüfzeit und Befugnis zur Konfigurationsänderung
Eingabedaten	Ausgewählte Beispiele zum Fähigkeitsnachweis	Reale historische Fälle einschließlich schwieriger Ausnahmen, vor dem Start getestet
Integration	Nur lesend oder Export in eine manuell bearbeitete Tabelle	Lese- und Schreibzugriff auf führende Kalender-, CRM-, Telefonie- und Ticketsysteme
Eskalation	Undefiniert oder „es sagt, dass es nicht helfen kann“	Klare Auslöser, benannter Empfänger, vollständiger Kontext und Ersatzweg bei Nichterreichbarkeit
Fehlerbehandlung	Improvisiert bei Unsicherheit eine Antwort	Erkennt Unsicherheit, lehnt sicher ab und protokolliert zur Prüfung
Überwachung	Jemand prüft, wenn er daran denkt	Automatische Warnungen bei Latenz, Fehlerquote, Abschlussquote ohne Übergabe und Volumenabweichungen
Messung	Einzelne Erlebnisse und ein gutes Gefühl	Ausgangswerte vor dem Start und wöchentlicher Ergebnisbericht
Änderungsprozess	Spontane Änderungen durch alle mit Zugriff	Versionierte Konfiguration, Testsatz und Rückfallweg
Compliance	Später berücksichtigt	Rechtsgrundlage, Aufbewahrung, Hinweise und Datenstandorte vor dem Start geklärt
Kostenmodell	Einmalige Projektgebühr	Entwicklung plus laufender Betrieb als budgetierte Position

Was ein produktionsreifes System wirklich braucht

Im Kern unterscheiden sechs Dinge ein System, das sein erstes Jahr übersteht, von einem, das scheitert.

Eine verantwortliche Person mit festem Kalendertermin. Kein Gremium. Eine interne oder externe Person prüft wöchentlich Gesprächsstichproben, ordnet Eskalationen ein und ändert Konfigurationen. Dreißig bis sechzig Minuten reichen meist. Null nicht.

Schreibzugriff auf führende Systeme. Der Test ist einfach: Muss ein Mensch nach der Interaktion noch etwas in einem System abschließen? Falls ja, ist die Integration unvollständig und der Parallelprozess bleibt. Hier liegt auch der größte Umsetzungsaufwand, weit vor Promptarbeit.

Ein geplanter Eskalationspfad. Meist genügen drei Stufen: bearbeiten, mit Kontext übergeben und hart stoppen. Ordnen Sie Anliegen und Unsicherheitsbedingungen zu. Regeln Sie Zeiten außerhalb des Betriebs und ausbleibende Antworten innerhalb einer Frist. Testen Sie den Ablauf dann gezielt bis an seine Grenzen.

Überwachung mit Alarm an Menschen. Latenz, Fehlerquote, erwartetes Anruf- oder Ticketvolumen, Abschlussquote ohne Übergabe und Eskalationen. Abweichungen sollen warnen, statt auf einen Dashboardbesuch zu warten. Googles Site Reliability Engineering ist das direkt übertragbare Referenzmodell.

Ausgangswerte und Wochenbericht. Erfassen Sie vier Wochen Vorher-Zahlen und berichten Sie danach dieselben Werte wöchentlich im gleichen Format an die rechnungsfreigebende Person. Langweilige Beständigkeit erleichtert Verlängerungsentscheidungen.

Ein Rückfallweg. Jede Änderung sollte binnen Minuten umkehrbar sein. Dokumentieren Sie, wie alles sofort zu Menschen zurückkehrt. Die Sicherheit, abschalten zu können, schafft Bereitschaft zum Einschalten.

Bei europäischen Einsätzen kommt Compliance hinzu: DSGVO-Rechtsgrundlage, Aufbewahrung von Aufnahmen und Transkripten, Hinweise, Datenstandorte und Transparenz nach der EU-KI-Verordnung. Das sind keine Blockaden, vor dem Start aber günstiger zu klären. Einzelheiten erläutert DSGVO und KI-Kundenservice.

Was unsere Produktarbeit verdeutlicht

Launchzy entwickelte Openbiznis, einen Vertriebsarbeitsplatz für Interessenten, Anrufe, Termine, Abschlüsse und Provisionen. Außerdem entwickelten wir Morpheus, ein E-Commerce-Kundenanalyseprodukt mit Verhaltens-, CRM- und Zielgruppenabläufen. Die öffentlichen Websites zeigen Produktumfang, keine unabhängig verifizierten Geschäftsergebnisse.

Deshalb beginnt unsere Arbeit an KI-Systemen bei der Betriebsebene: Dateneingang, Befugnisse, automatisierte Aktionen, Eskalationen und menschliche Prüfbarkeit. Ein Modell allein ergibt kein nutzbares System. Öffentliche Links finden Sie in unserer Projektübersicht.

Wie Sie ein KI-Projekt mit Zukunft freigeben

Wenn Sie über die Finanzierung entscheiden, sagen diese fünf Fragen mehr als jede Anbieter-Demo.

Wer ist im neunten Monat verantwortlich? Verlangen Sie Namen und Zeitbudget. Lautet die Antwort „Das klären wir noch“, finanzieren Sie einen Piloten, unabhängig vom Namen im Angebot.

Was sind die Ausgangswerte? Kennt niemand die aktuellen Prozesszahlen, sollten die ersten zwei Wochen der Messung statt der Entwicklung dienen.

Was tut das System bei einer falschen Antwort? Lassen Sie einen Fehler statt eines Erfolgs vorführen. Die Qualität dieser Antwort ist das Aufschlussreichste im Verkaufsgespräch.

In welche Systeme schreibt es, statt nur zu lesen? Lassen Sie die Schreibintegrationen im Leistungsumfang festhalten. Reiner Lesezugriff ist ein Warnsignal.

Was kostet der laufende Betrieb, und was deckt er ab? Entwicklung ohne Betriebsbudget lässt Projekte sterben. Überwachung, Optimierung und Berichte sind wiederkehrende Arbeit, weil sich der Betrieb verändert. Wer das als einmalig verkauft, unterschätzt die Arbeit oder plant sie nicht. Die Kosten erläutern wir bei der Frage, was eine KI-Rezeption tatsächlich kostet.

Ebenso wichtig ist Umfangsdisziplin: ein häufig genutzter, regelbasierter, messbarer Prozess mit begrenzten Fehlerfolgen. Nicht drei und nicht „das ganze Frontoffice“. Ein enger produktiver Einsatz schlägt eine breite Demo. Der zweite Prozess wird leichter, sobald Integration und Eskalation stehen.

Wann die ehrliche Antwort lautet: nicht entwickeln

Manche Prozesse sollten nicht automatisiert werden. Das auszusprechen gehört zu guter Arbeit.

Am klarsten ist geringes Volumen. Bei vier Vorgängen im Monat kosten Entwicklung, Überwachung und Optimierung dauerhaft mehr als die gesparte Arbeitszeit. Automatisieren Sie später oder gar nicht.

Zweitens: anspruchsvolle Urteile mit hohen Folgen wie medizinische Triage, Rechtsberatung oder Kreditentscheidungen. KI kann strukturierte Angaben sammeln, Entwürfe erstellen und weiterleiten. Entscheiden sollte ein qualifizierter Mensch. Diese Grenze muss das Design ausdrücklich setzen.

Drittens: Prozesse ohne stabile Regeln. Bearbeiten fünf Personen dasselbe Anliegen anders und können es nicht begründen, fehlt eine Prozessdefinition. Automatisierung würde nur persönliche Gewohnheiten als Richtlinie festschreiben.

Und zuletzt: Will der Betrieb seine Arbeitsweise nicht ändern, beginnen Sie nicht. KI am Empfang verändert Aufgaben, Dokumentation und Ausnahmebehandlung. Wer einen Ersatz ohne Anpassung erwartet, bekommt einen teuren Anrufbeantworter. Wer einen neuen Kollegen mit Einarbeitung, Aufsicht und Feedback sieht, erhält wachsenden Nutzen. Mehr dazu im Vergleich KI-Frontoffice oder Rezeptionskraft einstellen.

Die unbequeme Zusammenfassung: Technologie ist selten noch die Grenze. Entscheidend ist die Bereitschaft, ein laufendes System zu verantworten statt einen Prototyp zu bewundern. Piloten sind billig und befriedigend. Regelbetrieb ist beides nicht, liefert aber als Einziger Ertrag.

Häufig gestellte Fragen

Warum erreichen die meisten KI-Piloten keinen Regelbetrieb?

Pilot und Betriebssystem sind unterschiedliche Produkte. Ein Pilot zeigt technische Machbarkeit mit ausgewählten Daten. Der Regelbetrieb braucht Zuständigkeit, führende Systemanbindungen, Eskalation, Überwachung, Rückfallweg und Ausgangsmessung. Das entsteht nicht im Machbarkeitstest. Deshalb ist die Lücke zur Praxis meist größer als der Pilot selbst.

Wie lange sollte ein KI-Machbarkeitstest dauern?

Zwei bis vier Wochen genügen meist. Längere Machbarkeitstests vermeiden oft Entscheidungen, statt sie vorzubereiten. Legen Sie Erfolg und Abbruchkriterien vorher fest, testen Sie reale historische Eingaben statt ausgesuchter Beispiele und entscheiden Sie am Ende verbindlich über Fortsetzung oder Stopp.

Was ist der stärkste Hinweis auf das Scheitern nach dem Start?

Es fehlt eine benannte Betriebsverantwortung. Ohne Aufgabe in einer Stellenbeschreibung prüft niemand Transkripte, bemerkt Abweichungen oder verteidigt das Budget. Zuständigkeit zählt mehr als Modellqualität: Ein wöchentlich optimiertes Durchschnittssystem schlägt ein hervorragendes unbetreutes.

KI intern entwickeln oder extern betreiben lassen?

Entwickeln Sie intern, wenn der Prozess wirklich differenziert und eine dauerhafte Betreuung finanzierbar ist. Externe Betreuung passt bei wichtigen Standardprozessen wie Telefonannahme oder Angebotsnachverfolgung, für die sich sonst eine Teilzeitstelle nicht rechtfertigen ließe. Entscheidend ist, wer im neunten Monat noch optimiert.

Was sollten wir ab dem ersten produktiven KI-Tag messen?

Anteil ohne Übergabe abgeschlossener Fälle, Eskalationen samt Gründen, relevante Geschäftsergebnisse wie Termine, qualifizierte Kontakte oder gelöste Tickets, Latenz und manuelle Stichprobenqualität. Erfassen Sie dieselben Zahlen vier Wochen vor dem Start. Ohne Ausgangswerte fehlen Nutzenbeleg und Budgetgrundlage.

Lohnt sich der Neustart eines bereits festgefahrenen Piloten?

Oft ja, aber nicht als Pilot. Starten Sie einen klar abgegrenzten produktiven Prozess mit Zuständigkeit, Kalender- oder CRM-Anbindung und Eskalation neu. Die technische Vorarbeit ist meist weiterhin brauchbar. Es fehlte das Betriebsmodell. Genau das sollte der Neustart liefern.