Warum KI-Projekte scheitern — und woran man es zu spät merkt

Zu Misserfolgsquoten bei KI-Projekten kursieren viele Zahlen, und sie messen selten dasselbe. Wir führen hier keine davon an, weil die interessantere Frage ohnehin eine andere ist: Was genau scheitert, und woran merkt man es?

In unserer Arbeit unterscheiden wir drei Scheitern-Kategorien. Die erste: formales Scheitern — das Projekt wird abgebrochen oder nie produktiv eingesetzt. Die zweite: stilles Scheitern — das System ist im Einsatz, aber niemand nutzt es wirklich. Die dritte: teures Scheitern — das System wird genutzt, aber erzeugt keine messbaren Verbesserungen gegenüber dem Status quo.

Nur die erste Kategorie wird in Berichten gezählt. Die anderen beiden bleiben unsichtbar, und nach unserer Erfahrung sind sie die häufigeren. Ein Werkzeug, das lizenziert, eingeführt und dann von einer Handvoll Leuten gelegentlich benutzt wird, erscheint in keiner Statistik. Ein Misserfolg ist es trotzdem — und ein teurer, weil er weiterläuft.

Der häufigste Fehler ist so basal, dass man ihn kaum glauben mag: Das Projekt beginnt mit einem Tool, nicht mit einem Problem. Das Unternehmen kauft eine KI-Lösung — oft wegen eines überzeugenden Vertriebsgesprächs, weil der Wettbewerb sie einführt oder weil ein Aufsichtsratsmitglied einen Artikel gelesen hat.

Von diesem Tool aus werden dann Use Cases gesucht. Die Frage lautet: ‚Wofür können wir das nutzen?' statt ‚Welches unserer konkreten Probleme ist mit KI lösbar?' Dieser Unterschied klingt subtil. Er ist fundamental.

Projekte, die von einem konkreten Problem starten — einem messbaren Engpass, einem klaren Qualitätsproblem, einem definierten Effizienzpotenzial — haben systematisch höhere Erfolgsraten als Tool-first-Projekte. Das ist keine These. Das ist eine Beobachtung aus über 150 Projekten.

Der zweithäufigste Fehler wurde in diesem Artikel bereits angesprochen — aber er verdient Wiederholung: Die menschliche Dimension wird systematisch unterschätzt. Budgets werden für Technologie allokiert, nicht für Adoption.

In den Budgets, die uns vorgelegt werden, entfällt der weitaus größte Teil auf Technologie und Integration, ein schmaler Rest auf Projektmanagement und ein noch schmalerer auf Schulung. Genaue Anteile nennen wir nicht, weil sie von Projekt zu Projekt schwanken — das Missverhältnis ist trotzdem jedes Mal dasselbe. Es sollte nahezu umgekehrt sein — zumindest wenn das Ziel nachhaltige Nutzung ist. Ein System, das perfekt implementiert, aber nicht genutzt wird, kostet nur Geld.

Wir haben gelernt, Adoption als eigenständigen Erfolgsfaktor zu behandeln — mit eigenem Budget, eigenen Metriken und eigenem Verantwortlichen. Der ‚Adoption Owner' ist kein HR-Thema und kein Change-Management-Anhang. Er ist ein strategischer Projektposten.

KI-Projekte werden in vielen Unternehmen als IT-Projekte behandelt und entsprechend an IT-Leiter oder CIOs delegiert. Das ist strukturell falsch — nicht weil IT-Führungskräfte inkompetent wären, sondern weil KI-Transformation keine technische, sondern eine organisatorische Aufgabe ist.

Wenn Führungskräfte außerhalb der IT nicht aktiv in KI-Projekte involviert sind, passiert Vorhersehbares: Das Projekt hat keine Priorisierung in der Tagesagenda. Entscheidungen, die Prozess- oder Kulturveränderungen erfordern, werden nicht getroffen. Das Projekt stagniert.

Erfolgreiche KI-Projekte haben in unserer Erfahrung immer einen Sponsor auf C-Level, der persönlich für den Projekterfolg einsteht — nicht nur formal, sondern operativ. Der Unterschied zwischen einem formal zugewiesenen Projektsponsor und einem aktiv involvierten ist für den Projekterfolg entscheidend.

Erfolgreiche KI-Projekte starten mit einem konkreten, messbaren Problem. Sie haben einen klar definierten Anwendungsfall mit definierten Erfolgskriterien. Sie haben die Prozessgrundlage gelegt, bevor die Technologieauswahl beginnt. Und sie haben einen Plan für Adoption, der nicht mit dem Go-Live endet.

Sie haben außerdem etwas, das sich nicht dokumentieren, aber erleben lässt: eine Grundhaltung im Führungsteam, die KI-Integration als strategische Priorität behandelt — nicht als Projekt unter vielen, sondern als Kernaufgabe der nächsten Phase.

Und sie sind bereit zu scheitern — klein. Pilotprojekte, die nicht funktionieren, werden als Lernmöglichkeit behandelt, nicht als Versagen. Diese Haltung macht den Unterschied zwischen Organisationen, die aus Misserfolgen lernen und vorankommen, und solchen, die nach dem ersten Scheitern KI als ‚nicht für uns geeignet' abschreiben.

Für Unternehmen, deren erstes KI-Projekt gescheitert ist: Der häufigste Fehler beim zweiten Versuch ist, denselben Weg nochmals zu gehen — nur mit einem anderen Tool oder einem anderen Anbieter. Das löst das Problem nicht.

Der zweite Versuch sollte mit einer ehrlichen Retrospektive beginnen: Was ist beim ersten Versuch wirklich schiefgelaufen? Nicht die offizielle Version — die tatsächliche. War das Tool falsch? War der Prozess nicht bereit? Fehlte die Führungsunterstützung? War die Adoption unterdimensioniert?

Erst wenn diese Fragen ehrlich beantwortet sind, ergibt der zweite Versuch Sinn. Mit derselben Ausgangslage liefert eine neue Technologie kein anderes Ergebnis. Mit einer veränderten Ausgangslage kann auch ein bescheidenes Tool transformative Wirkung entfalten.