Branchenanalysen und Umfragen kommen seit Jahren wiederholt zum Befund, dass ein großer Teil der KI-Projekte, oft als Mehrheit berichtet, nie in Produktion geht oder nie messbaren Geschäftswert liefert. Die genauen Prozentzahlen unterscheiden sich je nach Studie und Definition von Scheitern, und gegenüber jeder einzelnen Schlagzeilen-Zahl ist Skepsis angebracht. Deutlich konsistenter als die Statistiken ist, was dahinter liegt: Wenn KI-Projekte scheitern, scheitern sie auf dieselbe Handvoll Arten, und fast keine davon hat mit den Modellen zu tun. Es geht um Problemdefinition, Daten, Menschen und Verantwortung, und das ist eine gute Nachricht, denn für jede dieser Ursachen gibt es eine bekannte Gegenmaßnahme.
Zu den Statistiken über das Scheitern
Zahlen, wonach die meisten KI-Projekte scheitern, kursieren seit Jahren, von Analystenhäusern, akademischen Umfragen und Anbieterstudien gleichermaßen. Behandeln Sie sie als Richtungssignal, nicht als Präzisionsmessung: Die Studien definieren Scheitern unterschiedlich (nie deployt, deployt aber aufgegeben, deployt aber ohne messbaren ROI), untersuchen unterschiedliche Populationen und sind manchmal Marketing dessen, der sie durchgeführt hat. Die Richtung ist allerdings konsistent und ernst zu nehmen: Ein erheblicher Teil der KI-Initiativen verbraucht echtes Budget und gibt nie Wert zurück. Die produktive Frage ist nicht „wie hoch ist die exakte Prozentzahl“, sondern „was haben die gescheiterten gemeinsam“, und dort konvergiert die Evidenz, auch das, was wir in Besetzungsgesprächen im DACH-Markt sehen, auf fünf Muster.
Grund 1: Technologie vor dem Geschäftsproblem gewählt
Das häufigste Scheitern beginnt, bevor Code existiert: Ein Unternehmen beschließt, dass es „KI“ braucht, und sucht dann nach einem Problem, statt von einem teuren, messbaren Geschäftsproblem auszugehen und zu fragen, ob KI das richtige Werkzeug ist. So geborene Projekte haben keine Erfolgsmetrik, die jemand in Euro, Stunden oder Fehlerraten nennen könnte, sie lassen sich weder steuern noch für fertig erklären, und sie driften, bis das Budget aufgebraucht ist. Gegenmaßnahme: Kein KI-Projekt besetzen oder finanzieren, das den Satz „dieses Projekt ist erfolgreich, wenn sich Metrik X um Y innerhalb von Z Monaten bewegt“ nicht vervollständigen kann. Lässt sich der Satz nicht vervollständigen, ist der nächste Schritt Problemfindung mit dem Fachbereich, nicht Einstellung.
Grund 2: Datenqualität zu spät entdeckt
Auf dem Papier verfügt das Unternehmen über Jahre reichhaltiger Daten; im dritten Monat entdeckt das Team, dass die Felder inkonsistent gefüllt sind, die Historie Lücken hat, die Labels abbilden, was bequem zu erfassen war, statt dem, was geschah, und dass das eine System mit den guten Daten keine API hat. Die Datenrealität, die erst nach der Budgetfreigabe eintrifft, ist einer der verlässlichsten Projektkiller, denn dann sind Zeitplan und Versprechen bereits öffentlich. Gegenmaßnahme: eine kurze technische Dateninspektion, ein echter Engineer schaut auf echte Datensätze, zur Vorbedingung des Budgets machen, nicht zum ersten Sprint. Sie kostet Tage, verändert regelmäßig den Plan und ist dramatisch billiger, als dieselben Fakten unter Termindruck zu entdecken.
Grund 3: Fehlende Skills im Team
Viele gescheiterte KI-Projekte waren mit Intelligenz und Enthusiasmus besetzt, aber ohne eine einzige Person, die je ein vergleichbares System in Produktion gebracht hatte. Das Ergebnis ist vorhersehbar: starke Demos, schwache Systeme, keine Evaluationsdisziplin, kein Gespür für die Fehlermodi probabilistischer Software und eine Architektur, die den Kontakt mit realer Last nicht überlebt. Dieses Scheitern ist leise, alle arbeiten hart, bis der Produktionstermin kommt. Gegenmaßnahme: sicherstellen, dass mindestens eine Person im Team schon Produktions-KI ausgeliefert hat, eingestellt, embedded oder fractional, und sie die technischen Entscheidungen früh prägen lassen, solange Kurskorrekturen billig sind. Diese Lücke in Tagen statt Monaten zu schließen ist exakt das Problem, für das spezialisierte KI-Personalvermittlung, Aiporate eingeschlossen, existiert.
Grund 4: Piloten ohne Pfad in die Produktion
Ein Pilot gelingt, die Stakeholder applaudieren, und nichts passiert, keine Budgetlinie für die Produktionalisierung, kein Integrationsplan, kein Betriebs-Owner, weil der Pilot als Demonstration konstruiert war und nicht als erste Scheibe eines Systems. So sammeln Organisationen Friedhöfe erfolgreicher Piloten an und null produktive KI. Gegenmaßnahme: den Produktionspfad vor dem Pilotstart entwerfen, vorab entscheiden, welches Ergebnis die Produktionalisierung auslöst, wer sie finanziert, mit welchen Systemen integriert werden muss, und den Piloten auf den echten Daten und nahe der echten Infrastruktur bauen, damit der Aufstieg ein Engineering-Schritt ist, kein Neustart.
Grund 5: Keine Verantwortung nach dem Launch
KI-Systeme verfallen ohne Aufmerksamkeit: Daten driften, Modelle und APIs ändern sich, Randfälle häufen sich, Nutzer:innen verlieren nach unerklärten Regressionen das Vertrauen. Wenn sich das Projektteam zum Go-live auflöst und kein:e benannte:r Owner bleibt, sinkt die Qualität, bis jemand das Feature stillschweigend abschaltet, die langsamste und vollständigste Form des Scheiterns, denn sie tritt ein, nachdem das gesamte Geld ausgegeben ist. Gegenmaßnahme: Owner und Betriebsbudget für die Zeit nach dem Launch vor dem Go-live benennen, mit Monitoring und Evaluation als Launch-Kriterien, nicht als Nacharbeiten. Wenn niemand bereit ist, das System in seinem zweiten Jahr zu verantworten, ist das ein Urteil über das Projekt, das man besser im Monat null hört.
