Das Muster wiederholt sich in vielen Unternehmen: Ein Team baut einen KI-Prototypen, die Vorführung im Management überzeugt, es gibt Applaus und ein Budget für den nächsten Schritt. Ein Jahr später lässt sich kaum benennen, welchen messbaren Beitrag die Lösung im Tagesgeschäft leistet. Analysen zu solchen Vorhaben verorten die Ursache selten in der Technologie selbst, sondern in der Distanz zwischen einer kontrollierten Demo und einem produktiven Alltag mit echten Daten, echten Nutzern und echter Verantwortung.
Diese Distanz ist kein Detailproblem. Eine Demo darf Rahmenbedingungen wählen: aufbereitete Beispieldaten, ein wohlgesinntes Publikum, ein enger Anwendungsfall, keine Vertretungsregelung, kein Nachtbetrieb, keine Revision. Der Produktivbetrieb darf das nicht. Er muss mit unvollständigen Datensätzen, widersprüchlichen Zuständigkeiten, Urlaubszeiten und Sonderfällen umgehen, die in keiner Präsentation vorkommen.
Warum Piloten stecken bleiben
In der Praxis lassen sich vier typische Bruchstellen beobachten.
- Der Anwendungsfall ist beeindruckend, aber nicht relevant. Was sich gut zeigen lässt, ist nicht automatisch das, was im Unternehmen Zeit oder Kosten bindet. Ein Pilot ohne klaren Bezug zu einem Engpass im Prozess produziert Erkenntnis, aber keinen Wert.
- Die Daten waren im Pilot ein Sonderfall. Für die Demo wurden Daten einmalig exportiert und bereinigt. Für den Betrieb braucht es eine dauerhafte, überwachte Anbindung an die Systeme, in denen die Daten tatsächlich entstehen.
- Die Lösung steht neben dem Prozess, nicht darin. Wenn Mitarbeitende ein zusätzliches Werkzeug öffnen, Inhalte kopieren und Ergebnisse manuell zurücktragen müssen, wird das Werkzeug im Stress zuerst weggelassen.
- Niemand ist für den Betrieb zuständig. Nach dem Projektabschluss fehlt eine Rolle, die Qualität beobachtet, Modelle oder Prompts nachjustiert und auf Änderungen in den Quellsystemen reagiert.
Datenanbindung: der unterschätzte Anteil
Der größte Aufwand liegt meist nicht im Modell, sondern davor. Produktive KI braucht Zugriff auf aktuelle Inhalte aus Fachanwendungen, Content-Management-Systemen, Dokumentenablagen oder ERP-Systemen — und zwar über Schnittstellen, die auch dann funktionieren, wenn ein System aktualisiert wird.
Dazu gehören Fragen, die in Demos gern übersprungen werden: Welche Daten dürfen verarbeitet werden, und von wem? Wie werden Berechtigungen abgebildet, damit eine Auskunftsfunktion nicht plötzlich Inhalte zeigt, die für die anfragende Person nicht bestimmt sind? Wie wird erkannt, dass eine Quelle seit Wochen keine neuen Daten liefert? Ohne Antworten darauf entsteht eine Lösung, die im Regelfall überzeugt und im Ausnahmefall Vertrauen zerstört.
Prozessintegration: KI dort, wo gearbeitet wird
Nutzen entsteht erst, wenn ein Arbeitsschritt tatsächlich anders abläuft als vorher. Das setzt voraus, dass die Funktion an der Stelle auftaucht, an der die Arbeit stattfindet — im Redaktionswerkzeug, im Ticketsystem, im Angebotsprozess — und nicht in einer separaten Oberfläche.
Genauso wichtig ist die Klärung, wer entscheidet. Bei Vorschlägen, die Menschen prüfen, ist die Verantwortung eindeutig, aber der Zeitgewinn begrenzt. Bei automatisierten Schritten steigt der Hebel, gleichzeitig braucht es definierte Grenzen, Protokollierung und einen Weg, Ergebnisse zu korrigieren. Diese Entscheidung ist keine technische, sondern eine organisatorische — und sie gehört vor die Umsetzung, nicht danach.
Betrieb: der Punkt, an dem Projekte zu Produkten werden
Eine KI-Funktion verhält sich nicht wie ein statisches Formular. Datenbestände wachsen, Formulierungen ändern sich, Anbieter aktualisieren Modelle, Nutzende entwickeln neue Erwartungen. Wer produktiv betreibt, braucht deshalb dieselbe Disziplin wie bei jeder anderen Fachanwendung: definierte Qualitätskriterien, Monitoring, ein Verfahren für Rückmeldungen aus der Fachabteilung, eine Versionierung der Konfiguration und einen Plan für den Fall, dass eine Komponente ausfällt oder ersetzt werden muss.
Dazu kommt der Kostenblick. Nutzungsabhängige Abrechnung macht Kosten planbar erst dann, wenn Volumen und Nutzungsmuster bekannt sind. Auch das ist ein Argument, früh mit einem begrenzten, aber echten Produktivbetrieb zu beginnen, statt lange in der Pilotphase zu verharren.
Woran sich ein Partner messen lässt
Bei der Auswahl externer Unterstützung ist weniger die Zahl vorzeigbarer Prototypen aussagekräftig als die Frage, was nach der Demo passiert. Nützliche Prüffragen sind: Welche bestehenden Systeme werden angebunden, und wie? Welche Kennzahl soll sich verändern, und wie wird sie gemessen? Wer übernimmt Wartung und Weiterentwicklung? Wie wird verhindert, dass eine Abhängigkeit entsteht, aus der das Unternehmen später nicht mehr herauskommt?
Ein pragmatischer Weg beginnt mit einem eng geschnittenen Anwendungsfall, der einen realen Engpass adressiert, wird von Anfang an an die produktiven Datenquellen angebunden und mit einer kleinen Nutzergruppe im Alltag erprobt. Erst wenn dort Qualität und Akzeptanz belegt sind, lohnt die Ausweitung.
Was das für Web- und Softwareprojekte bedeutet
KI-Funktionen sind kein Sonderfall, sondern ein weiterer Bestandteil der bestehenden Systemlandschaft — und sie erben deren Schwächen bei Schnittstellen, Datenqualität und Berechtigungen. Wer in Webprojekten früh über Datenanbindung, Rollen und Betriebsverantwortung spricht, verkürzt den Weg von der Demo zum Nutzen deutlich. Der entscheidende Erfolgsmaßstab ist nicht die Vorführung, sondern die Frage, ob ein Arbeitsschritt drei Monate später messbar anders abläuft.