Wer KI-Pilotprojekte skalieren will, steht im Mittelstand regelmäßig vor einem Phänomen, das in der Fachliteratur als „Pilot Purgatory“ bezeichnet wird: Ein Proof of Concept liefert überzeugende Ergebnisse, findet aber nie den Weg in den produktiven Regelbetrieb. Die Ursachen liegen selten in der zugrunde liegenden Modellqualität, sondern in fehlender organisatorischer Vorbereitung auf den Schritt vom kontrollierten Testumfeld in die tägliche Betriebspraxis. Ein Pilot läuft üblicherweise mit einem eng abgegrenzten Datensatz, wenigen Anwendern und ohne Anbindung an kritische Bestandssysteme, während der produktive Betrieb Schnittstellen, Berechtigungskonzepte, Monitoring und eine tragfähige Kostenstruktur erfordert. Ohne einen klar definierten Übergangsprozess bleibt der Pilot ein isoliertes Leuchtturmprojekt, dessen Nutzen sich nie auf die Breite des Unternehmens überträgt. Dieser Beitrag beschreibt, welche organisatorischen und technischen Voraussetzungen für die Skalierung erfüllt sein müssen, mit welchem Stage-Gate-Modell sich der Übergang strukturieren lässt und welche Stolperfallen in der Praxis am häufigsten zum Scheitern der Skalierung führen.
Warum die meisten KI-Pilotprojekte im Pilotstadium stecken bleiben
Ein Pilotprojekt wird in der Regel bewusst klein und risikoarm angelegt, um technische Machbarkeit und fachlichen Nutzen mit überschaubarem Aufwand zu belegen. Genau diese Verkleinerung wird jedoch zum Problem, wenn sie nicht von Anfang an als temporärer Zustand kommuniziert wird, sondern implizit als Blaupause für den späteren Regelbetrieb missverstanden wird. Häufig fehlt bereits im Pilotdesign die Betrachtung der Fragen, wer das System nach Abschluss des Projekts fachlich und technisch verantwortet, welche Datenquellen im Produktivbetrieb tatsächlich verfügbar sind und welche Kosten pro verarbeiteter Einheit im Vollbetrieb realistisch anfallen. In vielen Mittelständlern kommt hinzu, dass Piloten von einzelnen Fachbereichen oder externen Dienstleistern getrieben werden, ohne dass IT-Betrieb und Informationssicherheit von Beginn an eingebunden sind. Der Übergang in den Produktivbetrieb wird dadurch zu einem zweiten, eigenständigen Projekt mit eigenem Budget, eigenem Zeitplan und eigenen Freigabeprozessen, das in der ursprünglichen Planung meist nicht vorgesehen war.
Voraussetzungen für die Skalierung: Governance, Dateninfrastruktur, Verantwortlichkeiten
Bevor ein Pilot in die Fläche gebracht wird, sollte eine strukturierte Bestandsaufnahme klären, ob die technischen und organisatorischen Grundlagen für den Regelbetrieb tatsächlich vorhanden sind. Diese Bestandsaufnahme unterscheidet sich deutlich von der reinen Erfolgsmessung des Piloten, da sie nicht die erzielten Ergebnisse bewertet, sondern die Tragfähigkeit der zugrunde liegenden Struktur für einen deutlich größeren Nutzerkreis und Datenumfang.
Datenqualität und Zugriffsrechte als Skalierungsbremse
Piloten arbeiten häufig mit bereinigten, manuell kuratierten Datensätzen, die im Produktivbetrieb in dieser Form nicht mehr zur Verfügung stehen. Sobald das System auf Live-Daten aus ERP-, CRM- oder Dokumentenmanagementsystemen zugreifen muss, treten Inkonsistenzen, veraltete Datenfelder und uneinheitliche Formatierungen zutage, die im kleinen Pilotdatensatz nicht sichtbar waren. Zusätzlich verändert sich mit der Skalierung die Anforderung an Zugriffsrechte: Ein Pilot mit drei Testanwendern benötigt kein granulares Berechtigungskonzept, ein unternehmensweiter Rollout mit mehreren hundert Nutzern und unterschiedlichen Datenschutzklassen dagegen zwingend. Wird dieses Berechtigungskonzept erst nach der Pilotphase entwickelt, verzögert sich die Skalierung regelmäßig um mehrere Monate.
Ownership: Wer verantwortet ein KI-System nach dem Piloten?
Ein häufig unterschätzter Faktor ist die Frage der dauerhaften Verantwortlichkeit. Während der Pilotphase trägt meist eine einzelne Person oder ein kleines Projektteam die Verantwortung, im Produktivbetrieb muss diese Rolle jedoch in bestehende Organisationsstrukturen überführt werden, etwa in Form eines Produktverantwortlichen, der Modellqualität, Nutzerfeedback und Weiterentwicklung dauerhaft steuert. Ohne eine solche Rolle verwaist das System nach dem offiziellen Projektabschluss häufig, Modellaktualisierungen bleiben aus und die Akzeptanz sinkt schrittweise, weil sich niemand für auftretende Fehler zuständig fühlt.
In der Praxis bewährt sich die Verankerung dieser Verantwortung nicht als zusätzliche Vollzeitstelle, sondern als klar definierter Aufgabenanteil innerhalb einer bestehenden Fachabteilungsrolle, ergänzt um einen technischen Ansprechpartner aus der IT. Wichtig ist, dass beide Rollen namentlich benannt und im internen Organigramm sichtbar hinterlegt werden, statt informell „irgendwo im Projektteam“ zu verbleiben. Nur so lässt sich im Störungsfall schnell klären, wer über Anpassungen am System entscheidet und wer Anfragen aus den Fachbereichen entgegennimmt.
Das Stage-Gate-Modell für den Übergang vom Pilot zum Produktivbetrieb
Ein bewährter Ansatz zur Strukturierung der Skalierung ist die Übertragung des aus der Produktentwicklung bekannten Stage-Gate-Modells auf KI-Projekte. Jede Phase endet mit einem klar definierten Entscheidungspunkt, an dem auf Basis vorab festgelegter Kriterien über Fortsetzung, Anpassung oder Abbruch entschieden wird, statt eine Skalierung informell und schrittweise geschehen zu lassen.
| Phase | Zentrale Fragestellung | Typisches Freigabekriterium |
|---|---|---|
| Discovery | Ist der fachliche Anwendungsfall klar abgegrenzt? | Dokumentierter Business Case mit Erfolgskennzahlen |
| Pilot | Funktioniert die Lösung technisch und fachlich im Kleinen? | Erreichte Qualitäts- und Nutzenschwelle im Testbetrieb |
| Produktionsreife | Sind Datenanbindung, Sicherheit und Betrieb abgesichert? | Bestandene IT-Sicherheits- und Betriebsfreigabe |
| Kontrollierter Rollout | Skaliert die Lösung auf einen größeren Nutzerkreis? | Stabile Kennzahlen über einen definierten Beobachtungszeitraum |
| Regelbetrieb | Ist die dauerhafte Betreuung organisatorisch verankert? | Benannter Produktverantwortlicher und Supportprozess |
Zentral an diesem Modell ist, dass jede Phase über eigene Freigabekriterien verfügt und ein Übergang in die nächste Phase nicht allein von technischer Machbarkeit, sondern auch von organisatorischer Reife abhängt. In vielen Mittelständlern lohnt es sich, diese Freigabepunkte an ein bestehendes Projektportfolio-Gremium zu koppeln, damit die Entscheidung über eine Skalierung nicht allein beim ursprünglichen Projektteam verbleibt, sondern eine unternehmensweite Priorisierung erfährt.
Technische Integration in die bestehende IT-Landschaft
Die technische Skalierung eines KI-Systems unterscheidet sich grundlegend von der Erweiterung klassischer Software, da Modelle regelmäßig nachtrainiert, überwacht und bei Bedarf zurückgerollt werden müssen. Für den Produktivbetrieb empfiehlt sich daher der Aufbau grundlegender MLOps-Praktiken, auch wenn diese im Mittelstand selten in der Ausprägung großer Technologiekonzerne umgesetzt werden können. Dazu gehört mindestens ein automatisiertes Monitoring der Modellgüte im laufenden Betrieb, damit ein schleichender Qualitätsverlust, das sogenannte Modell-Drift, frühzeitig erkannt wird, statt erst durch Beschwerden von Anwendern aufzufallen. Ebenso wichtig ist eine dokumentierte Rollback-Strategie, mit der bei Fehlfunktionen kurzfristig auf eine vorherige, stabile Modellversion oder auf den bisherigen manuellen Prozess zurückgeschaltet werden kann. Die Integration in bestehende Schnittstellen sollte nach Möglichkeit auf etablierten API-Standards erfolgen, um die Lösung nicht dauerhaft an einen einzelnen Anbieter oder ein einzelnes Modell zu binden.
Für viele Mittelständler stellt sich zusätzlich die Frage, ob ein KI-Modell selbst betrieben oder als externer Dienst eingebunden wird. Der Eigenbetrieb bietet mehr Kontrolle über Daten und Anpassbarkeit, erfordert jedoch entsprechendes Fachpersonal für Betrieb und Wartung, das in kleineren IT-Abteilungen häufig nicht in ausreichendem Umfang vorhanden ist. Die Einbindung externer Dienste reduziert den internen Betriebsaufwand, verlagert aber Fragen der Datenverarbeitung und Vertraulichkeit an einen Dritten, deren vertragliche Absicherung, etwa über Auftragsverarbeitungsverträge, vor der Skalierung zwingend geklärt sein sollte. In der Praxis hat sich ein hybrider Ansatz bewährt, bei dem unkritische, standardisierte Funktionen extern bezogen werden, während Anwendungen mit sensiblen Unternehmensdaten auf einer intern kontrollierten Infrastruktur betrieben werden.
Kosten-Nutzen-Bewertung und Business Case für den Skalierungsschritt
Die Kostenstruktur eines Piloten unterscheidet sich erheblich von der eines produktiven Systems, da mit der Nutzerzahl auch Rechenkosten, Lizenzgebühren und Betreuungsaufwand steigen, während der Grenznutzen pro zusätzlichem Anwender häufig sinkt. Ein tragfähiger Business Case für die Skalierungsentscheidung sollte deshalb nicht die im Piloten erzielten Effekte linear hochrechnen, sondern realistische Annahmen zu Betriebskosten, Wartungsaufwand und notwendigen Schulungsmaßnahmen für einen größeren Nutzerkreis enthalten. In vielen Mittelständlern zeigt sich an dieser Stelle, dass sich eine Skalierung erst ab einer bestimmten Mindestgröße des betroffenen Prozesses wirtschaftlich rechnet, etwa weil der Personalaufwand für Modellpflege und Support unterhalb dieser Schwelle den erzielten Effizienzgewinn übersteigt. Eine ehrliche, auch negative Bewertung an dieser Stelle ist wirtschaftlich sinnvoller, als eine Skalierung allein aus Prestigegründen fortzuführen.
Zur Kostenseite gehört außerdem eine realistische Einschätzung der laufenden Modellpflege, die häufig unterschätzt wird, weil sie im Pilotbetrieb kaum ins Gewicht fällt. Ändern sich Geschäftsprozesse, Produktsortimente oder gesetzliche Rahmenbedingungen, muss ein produktiv eingesetztes Modell in vielen Fällen nachjustiert oder neu trainiert werden, was wiederkehrenden Aufwand erzeugt, der im ursprünglichen Pilotbudget selten eingeplant war. Ein tragfähiger Business Case weist diesen Wartungsaufwand deshalb als eigene, wiederkehrende Kostenposition aus und nicht nur als einmalige Einführungsinvestition. Ergänzend empfiehlt sich eine Sensitivitätsanalyse, die zeigt, wie robust der wirtschaftliche Nutzen bei einer geringeren als der im Piloten gemessenen Trefferquote tatsächlich ausfällt, da produktive Datenbestände selten exakt die Qualität des kuratierten Pilotdatensatzes erreichen.
Change Management und Akzeptanz bei der Skalierung
Während ein Pilot häufig von besonders aufgeschlossenen Mitarbeitenden getragen wird, trifft die Skalierung auf die gesamte Breite der Belegschaft, einschließlich derjenigen, die dem Einsatz von KI-Systemen skeptisch gegenüberstehen. Diese Gruppe wird in der Projektplanung häufig unterschätzt, obwohl ihre Akzeptanz maßgeblich über den tatsächlichen Nutzungsgrad des skalierten Systems entscheidet. Bewährt hat sich, Mitarbeitende aus unterschiedlichen Bereichen bereits in der Phase des kontrollierten Rollouts als Multiplikatoren einzubinden, damit Erfahrungswerte aus der Praxis in verständlicher Sprache weitergegeben werden, statt ausschließlich von der Projektleitung zu kommen.
„Skalierung ist kein technisches, sondern in erster Linie ein organisatorisches Problem. Die Modelle, die im Piloten funktionieren, funktionieren in aller Regel auch im Regelbetrieb, wenn Daten, Prozesse und Verantwortlichkeiten sauber definiert sind.“
Ein weiterer, in der Skalierungsphase oft vernachlässigter Aspekt ist die Frage, wie mit sogenannten Grenzfällen umgegangen wird, also mit Ergebnissen, bei denen das System selbst eine geringe Konfidenz aufweist. Wird dem System in dieser Situation zu viel Autonomie eingeräumt, sinkt das Vertrauen der Anwender schnell, sobald erkennbar fehlerhafte Ausgaben ungeprüft in nachgelagerte Prozesse einfließen. Bewährt hat sich, für solche Grenzfälle einen definierten Eskalationsweg an eine menschliche Prüfinstanz vorzusehen und diese Schwelle transparent zu kommunizieren, damit Anwender nachvollziehen können, wann und warum das System eine Entscheidung nicht automatisiert trifft. Diese Transparenz reduziert die verbreitete Sorge, ausschließlich einer nicht überprüfbaren „Black Box“ ausgeliefert zu sein, erheblich.
Praxisbeispiel: Von der Rechnungsprüfung zum unternehmensweiten Rollout
Ein mittelständisches Unternehmen testet zunächst mit einer kleinen Gruppe aus der Kreditorenbuchhaltung ein KI-gestütztes System zur automatisierten Prüfung eingehender Rechnungen gegen Bestellungen und Lieferscheine. Der Pilot läuft erfolgreich, weil die Testgruppe mit einem sauber vorbereiteten, homogenen Rechnungsbestand eines einzelnen Lieferanten arbeitet. Beim Versuch, das System auf alle Lieferanten und Standorte auszuweiten, zeigt sich, dass die Rechnungsformate stark variieren und ein erheblicher Teil der Belege zunächst nicht zuverlässig verarbeitet werden kann. Statt die Skalierung abzubrechen, definiert das Projektteam eine gestaffelte Einführung nach Lieferantengruppen, beginnend mit standardisierten Formaten, und ergänzt für abweichende Formate einen manuellen Prüfschritt als Übergangslösung. Nach rund sechs Monaten deckt das System den überwiegenden Teil des Rechnungsvolumens automatisiert ab, während für Sonderfälle weiterhin eine manuelle Kontrolle vorgesehen bleibt. Dieses Beispiel zeigt exemplarisch, dass eine gestaffelte, an der tatsächlichen Datenrealität orientierte Skalierung erfolgreicher ist als ein einmaliger, vollständiger Rollout. Entscheidend war zudem, dass die Kreditorenbuchhaltung von Beginn an regelmäßig über den Fortschritt informiert wurde, sodass auch Mitarbeitende an Standorten, die erst später an das System angebunden wurden, den Rollout als geplanten Prozess und nicht als plötzliche Umstellung wahrnahmen.
Typische Stolperfallen bei der Skalierung von KI-Pilotprojekten
Aus der Praxis lassen sich wiederkehrende Fehlerquellen ableiten, die bei der Skalierung von Pilotprojekten besondere Aufmerksamkeit verdienen.
- Fehlende Klärung der dauerhaften Verantwortlichkeit für das System nach Projektabschluss.
- Unterschätzung der Datenqualitätsunterschiede zwischen kuratiertem Pilotdatensatz und Live-Daten aus Bestandssystemen.
- Fehlendes Berechtigungs- und Datenschutzkonzept für einen größeren, heterogenen Nutzerkreis.
- Keine dokumentierte Rollback-Strategie für den Fall von Qualitätsproblemen im laufenden Betrieb.
- Lineare Hochrechnung des Pilotnutzens ohne realistische Betrachtung steigender Betriebskosten.
- Fehlende Einbindung von IT-Betrieb und Informationssicherheit bereits in der Pilotphase.
Schritt-für-Schritt-Vorgehen für die Skalierungsentscheidung
Für die praktische Umsetzung hat sich eine strukturierte Abfolge bewährt, die sich unabhängig von der konkreten Anwendung auf die meisten KI-Pilotprojekte im Mittelstand übertragen lässt.
- Dokumentation der im Piloten erzielten Ergebnisse anhand vorab definierter, messbarer Kriterien.
- Bestandsaufnahme der Datenqualität und Systemlandschaft für den geplanten Skalierungsumfang.
- Entwicklung eines Berechtigungs- und Datenschutzkonzepts gemeinsam mit IT-Sicherheit und Datenschutzbeauftragten.
- Erstellung eines realistischen Business Case mit Betriebskosten für den vollen Nutzerkreis.
- Benennung eines dauerhaften Produktverantwortlichen vor Beginn des Rollouts.
- Gestaffelter Rollout mit definierten Beobachtungszeiträumen statt vollständiger Einführung an einem Stichtag.
Ergänzende Orientierung zur strukturierten Weiterentwicklung von Innovationsvorhaben bietet der Beitrag zu strukturierten Innovationsprozessen. Praxisnahe Unterstützung bei der Bewertung und Begleitung von KI-Pilotprojekten im Mittelstand bieten außerdem die vom Bundeswirtschaftsministerium geförderten Mittelstand-Digital Zentren, die kostenfreie Beratung zu Digitalisierungs- und KI-Vorhaben anbieten.
FAQ
Warum scheitern viele KI-Pilotprojekte an der Skalierung?
Meist nicht an der Modellqualität, sondern an fehlender Datenanbindung, ungeklärter Verantwortlichkeit und unterschätzten Betriebskosten im produktiven Maßstab.
Was unterscheidet einen Piloten vom Produktivbetrieb?
Der Produktivbetrieb erfordert stabile Schnittstellen, ein Berechtigungskonzept für den vollen Nutzerkreis, Monitoring und eine dauerhafte organisatorische Betreuung.
Was ist ein Stage-Gate-Modell im Kontext von KI-Projekten?
Ein Phasenmodell mit klar definierten Freigabekriterien an jedem Übergang, das verhindert, dass eine Skalierung allein informell und schrittweise erfolgt.
Wer sollte nach der Pilotphase die Verantwortung für ein KI-System übernehmen?
Ein benannter Produktverantwortlicher, der Modellqualität, Nutzerfeedback und Weiterentwicklung dauerhaft steuert, statt das System nach Projektende unbetreut zu lassen.
Wie lässt sich das Risiko eines gescheiterten Rollouts reduzieren?
Durch eine gestaffelte Einführung nach Teilgruppen mit definierten Beobachtungszeiträumen statt einer vollständigen Einführung an einem einzigen Stichtag.
Welche Rolle spielt MLOps im Mittelstand?
MLOps-Grundpraktiken wie Modellmonitoring und Rollback-Strategien sind auch im Mittelstand sinnvoll, müssen aber nicht in der Komplexität großer Technologiekonzerne umgesetzt werden.
Aktuelle Beiträge
- Meldepflicht bei Datenschutzverletzungen im Unternehmen
- Lead-Recycling im B2B-Vertrieb
- Steuerliche Haftung der Geschäftsführung
