Studie um Studie beziffert die Scheiterquote unternehmerischer KI-Initiativen auf irgendwo zwischen 70 und 85 Prozent, je nachdem, wie eng „Scheitern“ definiert wird. Die Technologie ist selten der Grund. Zieht man die Details eines einzelnen gescheiterten Vorhabens ab, tauchen immer wieder dieselben vier strukturellen Ursachen auf, und jede einzelne führt zurück zu derselben zugrunde liegenden Beschränkung: Geschwindigkeit und Zugang zum richtigen Talent, nicht die Technologie selbst.
Scheitermuster 1: Der Talent-Engpass
Die Menschen, die einen KI-Piloten von der funktionierenden Demo zu einem verlässlichen Produktivsystem bringen können, ML Engineers, die Deployment und Monitoring verstehen, nicht nur Modelltraining, Applied-AI-Spezialist:innen, die einen Geschäftsprozess in ein funktionierendes System übersetzen können, sind knapp, und der Markt für sie ist tatsächlich global. Ein Unternehmen, das sein Transformationsvorhaben mit einer Stellenausschreibung für einen Senior ML Engineer beginnt, blickt oft auf einen drei- bis sechsmonatigen Einstellungszyklus, in einem Markt, in dem die stärksten Kandidat:innen innerhalb weniger Wochen mehrere konkurrierende Angebote erhalten. In der Zwischenzeit wartet der Pilot, der den Anwendungsfall beweisen sollte, auf die Person, die ihn bauen soll. Bis die Einstellung steht, falls sie überhaupt steht, hat sich die Sponsorin aus der Geschäftsführung bereits einer anderen Priorität zugewandt, das Budgetfenster ist geschlossen, oder ein Wettbewerber hat bereits etwas Ähnliches ausgeliefert. Der Engpass ist nicht Wille oder Technologie, sondern die Geschwindigkeit, mit der die konkrete, knappe Fähigkeit für die Arbeit beschafft werden kann.
Scheitermuster 2: Die Führung behandelt es als Nebenprojekt
KI-Transformation wird mit echtem Anspruch angekündigt und dann wie ein Experiment ausgestattet: ein funktionsübergreifendes Gremium, das monatlich tagt, ein Budget, das aus dem freien Spielraum eines bestehenden Teams abgezweigt wird statt aus einer eigenen Budgetzeile, und eine Sponsorin aus der Geschäftsführung, deren eigentlicher Job ein anderer, größerer Unternehmensbereich ist. Alle Beteiligten machen das neben ihrem eigentlichen Job, was bedeutet, dass es genau dann echte Aufmerksamkeit bekommt, wenn nichts Dringenderes um dieselben Stunden konkurriert, selten. Ein Transformationsvorhaben, das wie ein Nebenprojekt ausgestattet ist, liefert Nebenprojekt-Ergebnisse: ein paar Workshops, ein Strategiepapier, vielleicht einen kleinen Piloten, der nie das Folgebudget für die Skalierung bekommt. Organisationen, die tatsächlich transformieren, geben dem Vorhaben eine echte Budgetzeile, einen echten Kopfzahlplan und eine Sponsorin, deren Leistungsbeurteilung vom Ergebnis abhängt, nicht nur von ihrem Wohlwollen gegenüber der Idee.
Scheitermuster 3: Pilotprojekte im Proof-of-Concept-Fegefeuer
Ein Pilot, der in einer Demo funktioniert, mit kuratierten Daten, manuell von einer Data-Scientist-Person gestartet, ist nicht dasselbe wie ein System, das verlässlich in Produktion läuft, überwacht, gewartet, in einen echten Workflow integriert, verantwortet von jemandem, nachdem die ursprüngliche Baumannschaft zum nächsten Projekt weitergezogen ist. Von einem zum anderen zu kommen, ist echte Engineering-Arbeit: Deployment-Infrastruktur, Monitoring, Fehlerbehandlung, Integration in bestehende Systeme, nichts davon ist glamourös, und alles davon braucht ein Team, nicht die eine oder zwei Personen, die den ursprünglichen Proof of Concept gebaut haben. Viele Organisationen haben eine Schublade voller KI-Pilotprojekte, die „funktioniert“ haben und nie ausgeliefert wurden, weil niemand die unglamouröse zweite Hälfte der Arbeit budgetiert oder besetzt hat. Die Demo wird zum Dauerzustand, in Präsentationen als Fortschrittsnachweis gezeigt, während sich am tatsächlichen Geschäftsbetrieb nichts ändert.
Scheitermuster 4: Unklare Verantwortung
Fragt man in einer ins Stocken geratenen Organisation, wer für eine bestimmte KI-Transformationsinitiative verantwortlich ist, lautet die ehrliche Antwort oft eine Liste von Namen aus IT, einem Datenteam, einem Fachbereich und einer Innovationseinheit, von denen jede:r ein Stück besitzt und niemand das Ergebnis oder die Befugnis über die Budgets und Prioritäten der anderen. Wenn etwas schnell gehen muss, ein Prozess sich ändern soll, eine Einstellung erfolgen muss, eine Datenzugriffsanfrage freigegeben werden muss, gibt es keine einzelne Person, die entscheiden kann, also geht es in ein Meeting, und dann in ein weiteres. Initiativen mit verteilter, unklarer Verantwortung scheitern nicht mit einem dramatischen Ende, sie verlieren still an Schwung, bis alle Beteiligten sich etwas mit klarerem Mandat zugewandt haben.
Der rote Faden: Geschwindigkeit und Talentzugang, nicht die Technologie
Betrachtet man alle vier Scheitermuster zusammen, ist der gemeinsame Nenner nicht das Modell, die Plattform oder der Anwendungsfall, sondern die Fähigkeit der Organisation, die richtigen Fähigkeiten zu beschaffen und die nötigen Entscheidungen schnell genug zu treffen, um zu handeln, solange die Gelegenheit und die Aufmerksamkeit der Geschäftsführung noch da sind. Die KI-Fähigkeiten haben sich schnell genug entwickelt, dass die technische Obergrenze dessen, was möglich ist, kaum noch die Beschränkung ist, die meisten tragfähigen Anwendungsfälle ließen sich mit heute verfügbaren Werkzeugen bauen. Was den meisten Organisationen fehlt, ist nicht die Technologie, sondern die Geschwindigkeit, das konkrete, knappe Talent einzustellen oder darauf zuzugreifen, die Ausstattungsdisziplin, das Vorhaben als echte Arbeit statt Nebenprojekt zu behandeln, die technische Konsequenz, einen funktionierenden Piloten zu operationalisieren, und die klare Verantwortung, Entscheidungen ohne sechswöchigen Gremienzyklus zu treffen. Jedes davon ist ein Talent- und Geschwindigkeitsproblem, kein Technologieproblem.
Was das Ergebnis tatsächlich verändert
- Talentzugang von Anfang an als kritischen Pfad behandeln: Wenn eine Festanstellung für eine knappe Rolle drei bis sechs Monate dauert, parallel Embedded- oder Forward-Deployed-Spezialist:innen hinzuziehen, damit der Pilot nicht auf einen Einstellungszyklus wartet, den er nicht kontrolliert.
- Das Vorhaben wie den Rest des echten Geschäfts ausstatten: eine eigene Budgetzeile, ein Kopfzahlplan und eine Sponsorin aus der Geschäftsführung, deren Leistung tatsächlich am Ergebnis hängt, kein monatlich tagendes Gremium.
- Von Anfang an für die unglamouröse zweite Hälfte besetzen: Budget und Kopfzahl für Deployment, Monitoring und Integration einplanen, bevor der erste Pilot überhaupt ausgeliefert wird, nicht erst, nachdem er in der Demo „funktioniert“.
- Für jede Initiative eine verantwortliche Person mit echter Befugnis über Budget und Prozessänderung benennen, verteilte Verantwortung ist der Weg, wie Initiativen still versanden.