Skalieren, nachbessern oder stoppen: Wie entscheiden Sie nach dem KI-Pilot?
Ein Kriterienraster für die Entscheidung nach dem Pilotprojekt: welche Bereiche ein Geschäftsführer prüfen muss, bevor er Skalieren, Nachbessern oder Stoppen wählt.
95 Prozent der unternehmensinternen Generative-KI-Piloten erzielen keinen messbaren Ergebnisbeitrag. Das zeigt eine Auswertung von MIT NANDA, zitiert in Fortune (18.08.2025). Diese Zahl belegt nicht, dass generative KI im Mittelstand grundsätzlich scheitert. Sie zeigt, dass der Übergang vom Pilot in den Alltag ein eigener Entscheidungsschritt ist, der sich vom Pilotverlauf selbst unterscheidet, und dass diese Entscheidung eine eigene, vorbereitete Grundlage braucht, statt sich beiläufig aus dem Projektverlauf zu ergeben.
Genau diese Entscheidung, skalieren, nachbessern oder stoppen, ist der Gegenstand dieses Beitrags. Sie kommt zu spät, wenn sie erst gestellt wird, nachdem der Pilot als „erfolgreich“ gefeiert wurde. Sie gehört an den Anfang: als Raster, gegen das der Pilot am Ende gemessen wird.
Warum die dritte Option meistens fehlt
Nach IDC-Daten, ausgewertet für eine Lenovo-Studie und zitiert in CIO.com (25.03.2025), schafft es nur ein kleiner Teil der gestarteten KI-Proof-of-Concepts überhaupt bis in die Produktivstufe. Als Gründe nennt die Auswertung fehlende Datenreife, fehlende Prozesse und fehlende IT-Infrastruktur, nicht in erster Linie die Modellqualität. Ergänzend zeigt eine Auswertung von S&P Global Market Intelligence, zitiert in CIO Dive (14.03.2025): 2025 haben 42 Prozent der befragten Unternehmen den Großteil ihrer KI-Initiativen abgebrochen, gegenüber 17 Prozent im Jahr zuvor; im Schnitt wurden 46 Prozent aller KI-Proof-of-Concepts vor der Produktivsetzung verworfen.
Die drei Quellen beschreiben aus unabhängigen Blickwinkeln denselben Engpass. Der Ausfall passiert nicht am Ende einer laufenden Produktion, sondern am Übergang dorthin. Wenn dieser Übergang binär gedacht wird, weiterlaufen lassen oder abschalten, fehlt eine dritte Option: gezielt nachbessern und erst danach neu entscheiden. Ein Raster mit drei statt zwei Ausgängen zwingt dazu, das Ergebnis in Teilfragen zu zerlegen, statt es in einem Urteil zusammenzufassen.
Woran Sie die Entscheidung objektiv festmachen
Vor jeder Lösungsdiskussion stehen fünf Fragen: Existiert das Problem überhaupt? Wie groß ist es wirklich? Was ist die eigentliche Ursache? Muss es überhaupt gelöst werden? Ist KI dafür überhaupt die richtige Antwort? Für die Skalierungsentscheidung nach einem Piloten braucht es danach ein zweites Raster, das den Piloten selbst prüft, unabhängig von den fünf Vorfragen. Das Raster umfasst folgende Bereiche:
- Datenbasis: Trägt die Datenqualität eine zehnfache Last, oder war der Pilot auf handverlesene, saubere Eingaben angewiesen?
- Systemintegration: Läuft das System an den Schnittstellen zu ERP, WMS oder Fachanwendung stabil, oder wurde im Piloten manuell nachgeholfen?
- Betriebsverantwortung: Gibt es einen benannten Verantwortlichen für den laufenden Betrieb, oder trägt ihn implizit noch das Projektteam?
- Wirtschaftlicher Nutzen: Lässt sich der Nutzen an einer Kennzahl festmachen, die vor dem Piloten definiert wurde, oder wird der Erfolg im Nachhinein erzählt?
- Organisatorischer Rückhalt: Wird das System von denen genutzt, die damit arbeiten sollen, oder nur von denen, die es eingeführt haben?
In jeden dieser Punkte gehören Integration, Schulung, Betrieb, Abhängigkeiten und Erweiterbarkeit, nicht nur die ursprüngliche Projektsumme. Ein Pilot, der günstig war, weil er diese Kosten noch nicht getragen hat, ist damit noch keine wirtschaftliche Entscheidung.
Wann Skalieren die richtige Entscheidung ist
Skalieren ist vertretbar, wenn die genannten Bereiche überwiegend tragen und die verbleibenden Lücken benennbar und klein sind, etwa eine noch fehlende, aber bereits geplante Schnittstelle. Wichtig ist dabei die Trennung von technischer Machbarkeit und wirtschaftlichem Nutzen: Ein System kann technisch stabil laufen und trotzdem wirtschaftlich nicht tragen, wenn der Nutzen nicht an eine Kennzahl gebunden ist, die vor der Skalierung feststand. Jede technische Aussage gehört in eine wirtschaftliche Konsequenz übersetzt, weil ein Geschäftsführer am Ende eine Zahl braucht, die er gegenüber Gesellschaftern, Mitarbeitenden und Kunden vertreten kann, samt Kriterien, an denen sich der Erfolg überprüfen lässt.
Wann Nachbessern der richtige Weg ist
Nachbessern ist die richtige Wahl, wenn genau ein oder zwei Bereiche des Rasters nicht tragen und die Lücke sich mit angemessenem Aufwand schließen lässt, etwa eine fehlende Betriebsverantwortung, die sich durch eine klare Zuweisung beheben lässt, oder eine Datenbasis, die zunächst bereinigt werden muss. Der Unterschied zum Sofort-Skalieren ist die Reihenfolge: Erst die benannte Lücke schließen, dann neu gegen dasselbe Raster prüfen, nicht parallel skalieren und hoffen, dass sich die Lücke von selbst löst. Wer nachbessert, ohne die übrigen Bereiche erneut zu prüfen, wiederholt denselben Fehler, der den Piloten überhaupt erst in diese Lage gebracht hat.
Wann Stoppen die richtige Entscheidung ist
Ein System wird nicht bei der Abnahme beurteilt, sondern nach Monaten im Alltag; produktiver Betrieb, Wartung, Datenqualität und organisatorische Einführung bestimmen den tatsächlichen Nutzen. Wenn nach dieser Zeit mehrere Bereiche des Rasters gleichzeitig nicht tragen, insbesondere Betriebsverantwortung und organisatorischer Rückhalt, ist Stoppen keine Notlösung. Es ist die konsequente Anwendung derselben Prüfung, die auch zum Skalieren geführt hätte. „Nichts verändern“ ist ein Ergebnis, kein Scheitern der Beratung. Dabei zählt keine Erfolgsstatistik und keine Bindung an eine bestimmte Lösung: Geprüft werden Technik, Kosten und Risiken, und daraus entsteht eine Entscheidungsgrundlage, die auch lauten kann, das Projekt an dieser Stelle zu beenden, bevor die laufenden Kosten die eingesparten übersteigen.
Schnittstellen und Abhängigkeiten sind dabei wirtschaftlich mindestens so bedeutend wie einzelne Funktionen: Ein Pilot, der isoliert überzeugt, aber jede zusätzliche Schnittstelle als Sonderfall behandelt, trägt die Kosten der Skalierung nicht im Piloten, sondern erst danach. Das Raster aus Datenbasis, Systemintegration, Betriebsverantwortung, wirtschaftlichem Nutzen und organisatorischem Rückhalt macht diese Kosten vor der Entscheidung sichtbar, nicht erst danach.