Warum KI-Projekte scheitern: Ursachen und Gegenmaßnahmen

Das Wichtigste in Kürze:

• Laut MIT-Studie erzielen rund 95 Prozent der GenAI-Piloten keinen messbaren Nutzen.
• Die Ursachen liegen selten im Modell: unklare Ziele, falsche Use Cases, Datenprobleme, fehlende Integration, Akzeptanz.
• Die teuersten Fehler passieren vor der Entwicklung, etwa fehlendes Mandat oder ungeprüfte Datenlage.
• Drei Gates mit echter Stopp-Option machen Scheitern früh sichtbar und damit billiger.

Problem und Zielgruppe: Wenn KI-Projekte im Sande verlaufen

Ein Pilotprojekt startet mit Rückenwind. Ein Tool wird angeschafft, ein Team probiert es aus. Ein Jahr später ist niemand mehr sicher, ob es noch produktiv läuft. Kein spektakulärer Absturz, kein Fehlschlag mit Ansage. Das Projekt verläuft einfach im Sande.

Die Nutzung sinkt, die ursprünglichen Fürsprecher sind mit anderen Themen beschäftigt. Beim nächsten Anlauf heißt es: „Das haben wir schon probiert, hat nicht funktioniert.“ Genau dieses Muster begegnet mir in Gesprächen mit kleinen und mittleren Unternehmen deutlich häufiger als der laute Fehlschlag.

Das Ausmaß ist kein deutsches Nischenphänomen. Laut der MIT-Studie „The GenAI Divide: State of AI in Business 2025“ erzielen rund 95 Prozent der untersuchten Generative-AI-Pilotprojekte keinen messbaren wirtschaftlichen Nutzen. Nur etwa 5 Prozent ziehen aus einem Pilot echten operativen oder finanziellen Effekt. Die Studie wertet mehr als 300 öffentlich dokumentierte KI-Initiativen, 52 strukturierte Interviews und 153 Umfrageantworten von Führungskräften aus, erhoben zwischen Januar und Juni 2025.

Eine Detailzahl daraus ist bemerkenswert. Von Fachanbietern eingekaufte oder in Partnerschaft entwickelte Lösungen erreichen eine Erfolgsquote von rund 67 Prozent, intern selbst entwickelte nur rund ein Drittel davon. Das Problem liegt selten am Modell. Es liegt daran, wie Organisationen mit der Technik umgehen.

Gleichzeitig wächst der Nutzungsdruck. Die ifo-Konjunkturumfrage vom Mai 2026 zeigt: 54,5 Prozent der deutschen Unternehmen setzen KI in ihren Geschäftsprozessen ein, nach 40,9 Prozent im Vorjahr. Bei Großunternehmen sind es 67,2 Prozent, bei mittleren 47,2 Prozent, bei kleinen 51,2 Prozent. Wer nicht mitzieht, spürt Konkurrenzdruck. Wer mitzieht, ohne die Ursachen des Scheiterns zu kennen, riskiert genau die Erfahrung, die spätere Vorhaben blockiert.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU. Er hilft beim Lernen aus einem gescheiterten Anlauf und beim robusteren Aufsetzen eines neuen. Er ergänzt den Einstiegsartikel KI-Strategie um die Fehlerperspektive: nicht was zu tun ist, sondern was typischerweise schiefgeht und wie du es früh erkennst.

Begriffe und Abgrenzung: Scheitern ist nicht gleich Scheitern

„Scheitern“ wird in der Debatte zu unscharf verwendet. Für diesen Artikel unterscheide ich 3 Fälle mit unterschiedlichen Konsequenzen.

• Kontrolliertes Scheitern: Ein Pilot wird nach vorher definierten Kriterien beendet, weil er sie nicht erreicht hat. Das System funktioniert wie geplant, Ressourcen fließen nicht weiter in eine Sackgasse.
• Stilles Verlaufen: Das Projekt wird nie offiziell beendet, aber die Nutzung sinkt schleichend, bis niemand mehr aktiv damit arbeitet. Dieser Fall ist teuer, weil er am längsten unentdeckt bleibt und selten aus ihm gelernt wird.
• Aktiver Schaden: Die Lösung produziert falsche Ergebnisse, die unentdeckt in Entscheidungen oder Kundenkontakt einfließen. Das ist der seltenste, aber teuerste Fall.

Die meisten öffentlich diskutierten „gescheiterten KI-Projekte“ fallen in die zweite Kategorie. Die zentrale Frage ist deshalb nicht, wie sich ein spektakulärer Fehlschlag verhindern lässt. Sie lautet: Wie erkenne ich früh, dass ein Projekt in Kategorie zwei abrutscht, und wie hole ich es zurück oder beende es kontrolliert?

Was sind häufige Ursachen?

Über die 3 hier zitierten Quellen hinweg wiederholt sich ein Muster. Die Ursache liegt selten im Modell selbst. Fünf Ursachenblöcke tauchen immer wieder auf.

Unklare Geschäftsziele. Das Projekt beginnt mit einer Technologie-Entscheidung („Wir brauchen KI“) statt mit einem Geschäftsproblem. Ohne definiertes Ziel fehlt der Maßstab für Erfolg oder Misserfolg. Das Projekt kann nicht einmal richtig scheitern, weil nie definiert war, woran es gemessen wird. Genau das macht das stille Verlaufen so wahrscheinlich.

Ein falsch gewählter Use Case. Der spektakulärste, nicht der machbarste Anwendungsfall wird zuerst angegangen. Details dazu stehen weiter unten im Abschnitt zur Use-Case-Erkennung.

Datenqualität und -zugänglichkeit. Gartner-Analystin Rita Sallam nannte in einer Prognose vom Juli 2024 ausufernde Kosten, unklaren Geschäftswert, schlechte Datenqualität und unzureichende Risikokontrollen als Hauptgründe für Abbrüche. Unternehmen stellen demnach mindestens 30 Prozent ihrer Generative-AI-Projekte nach der Proof-of-Concept-Phase wieder ein. Datenqualität ist darin kein Randthema, sondern einer der am häufigsten genannten Gründe.

Fehlende Integration in bestehende Prozesse. Ein Pilot, der im Testsystem gut läuft, aber nie an echte Arbeitsabläufe, Systeme und Verantwortlichkeiten angebunden wird, bleibt ein Experiment. Genau hier trennt die MIT-Studie die 5 Prozent erfolgreicher von den 95 Prozent wirkungsloser Piloten. Erfolgreiche Vorhaben lernen aus dem Kontext und passen sich an Arbeitsabläufe an. Generische Tools ohne diese Anpassung bleiben stecken.

Fehlende Akzeptanz. Selbst eine technisch funktionierende Lösung scheitert, wenn die Menschen sie nicht nutzen wollen oder können. Dazu mehr im übernächsten Abschnitt.

Diese fünf Ursachen wirken selten einzeln. In Beratungsgesprächen sehe ich, wie sie sich gegenseitig verstärken. Ein unklares Ziel begünstigt einen falschen Use Case, und ein falscher Use Case trifft häufiger auf schlechte Datenlage. Ohne klares Ziel fehlt zudem die Grundlage, um Akzeptanz im Team überzeugend zu begründen.

Welche Fehler entstehen vor der Entwicklung?

Die teuersten Fehler passieren vor der ersten Zeile Konfiguration oder Code. Sie lassen sich später kaum korrigieren, ohne von vorn zu beginnen. Diese 5 Muster sehe ich am häufigsten.

• Kein Mandat: Niemand in der Geschäftsführung trägt die Priorisierungsentscheidung mit. Sobald das Projekt mit dem Tagesgeschäft konkurriert, verliert es.

• Kein Owner im Fachbereich: Die IT setzt eine Lösung um, für die niemand im betroffenen Prozess Verantwortung übernimmt. Ohne fachlichen Owner schaut nach dem Go-Live niemand mehr hin.

• Keine Erfolgskriterien vor dem Start: Wird Erfolg erst nach dem Piloten definiert, wird praktisch jedes Ergebnis im Nachhinein als „irgendwie positiv“ interpretiert. Oder das Projekt verläuft sich, weil niemand sagen kann, ob es funktioniert.

• Ungeprüfte Datenlage: Erst im laufenden Projekt zeigt sich, dass die benötigten Informationen unvollständig, veraltet oder über mehrere Systeme verstreut sind. Das kostet Zeit und untergräbt das Vertrauen ins Vorhaben.

• Zu großer Scope beim ersten Anlauf: Statt eines eng begrenzten Piloten wird gleich eine unternehmensweite Lösung angestrebt. Je größer der erste Wurf, desto später die erste sichtbare Wirkung und desto eher ist die Geduld vorher aufgebraucht.

In meiner Arbeit sehe ich diese Fehler fast nie isoliert. Typisch ist die Kombination aus fehlendem Mandat und zu großem Scope. Ohne Sponsor, der Prioritäten setzt, wächst der Anspruch des Projekts, weil niemand den Umfang zu begrenzen wagt. „Wenn wir das schon machen, dann richtig“ ist der Satz, der mehr Piloten das Genick bricht als jede technische Hürde.

Warum scheitert Akzeptanz?

Akzeptanzprobleme werden oft als Change-Management-Frage abgetan und damit kleingeredet. Tatsächlich gehören sie zu den am häufigsten unterschätzten Gründen, warum technisch funktionierende Lösungen still verlaufen. 3 Muster wiederholen sich.

Fehlende Einbindung. Wird eine Lösung „für“ statt „mit“ den Betroffenen entwickelt, fehlt das Wissen über die tatsächliche Arbeitsrealität. Es fehlt auch die Identifikation mit dem Ergebnis. Menschen nutzen selten enthusiastisch, was ihnen ohne Beteiligung vorgesetzt wird.

Unklarer persönlicher Nutzen. „Das spart dem Unternehmen Geld“ motiviert einzelne Mitarbeitende selten zur aktiven Nutzung. Was zählt, ist die konkrete Frage: Wird meine Arbeit leichter, schneller, weniger frustrierend, oder wird zusätzlicher Aufwand auf mich verlagert, ohne dass ich etwas davon habe?

Unadressierte Sorgen. Die Sorge um den Arbeitsplatz, um Kontrollverlust oder um Verantwortung für KI-Fehler verschwindet nicht durch Schweigen. Sie äußert sich in stiller Verweigerung: Das Tool wird formal genutzt, aber nicht wirklich in den Arbeitsalltag integriert.

Genau hier setzt die im EU AI Act verankerte KI-Kompetenzpflicht an, nicht nur als rechtliche Vorgabe, sondern als praktischer Hebel. Wer versteht, was ein System kann und wo seine Grenzen liegen, hat weniger unbegründete Angst und mehr begründetes Vertrauen. Strukturierte Schulungen wirken doppelt: als Kompetenzaufbau und als Akzeptanzarbeit in einem.

Die wirksamste Gegenmaßnahme ist unspektakulär. Früh einbinden, ehrlich über Grenzen sprechen, und den Nutzen so konkret wie möglich an der Arbeit der jeweiligen Person festmachen statt an Unternehmenskennzahlen.

Wie erkennt man einen falschen Use Case?

Ein falscher Use Case ist selten von Anfang an offensichtlich falsch, sonst würde ihn niemand wählen. Er zeigt sich an 5 Warnsignalen, die sich schon vor dem Projektstart prüfen lassen.

• Kein klarer Prozessbezug: „KI im Kundenservice“ ist kein Use Case, sondern eine Themenüberschrift. Ohne konkret benannten, abgegrenzten Arbeitsschritt lässt sich weder Aufwand noch Nutzen seriös schätzen.

• Keine Vorher-Nachher-Messbarkeit: Lässt sich vorher nicht sagen, woran Erfolg erkennbar wäre, lässt es sich hinterher auch nicht bewerten. Der Use Case bleibt beliebig interpretierbar.

• Hohe Fehlerkosten bei geringer Prüfbarkeit: Aufgaben, bei denen eine falsche KI-Ausgabe ungeprüft nach außen oder in eine folgenreiche Entscheidung wirkt, eignen sich nicht für den Einstieg. Der theoretische Nutzen ändert daran nichts.

• Schlechte oder nicht zugängliche Datenlage: Liegen die benötigten Informationen nicht digital, aktuell und zugänglich vor, ist der Use Case nicht reif. Wie überzeugend die Idee klingt, spielt dann keine Rolle.

• Der Use Case soll vor allem beeindrucken: Das Vorhaben beruht primär auf einer Demo oder einem Konferenzbeitrag statt auf einem echten internen Engpass. So ein Projekt hat selten einen Owner, der es über die Pilotphase hinaus trägt.

Wer diese 5 Punkte vor dem Start prüft, sortiert die meisten Fehlkandidaten aus, bevor sie Ressourcen binden. Eine strukturierte Bewertung mehrerer Kandidaten ersetzt das nicht. Dafür eignet sich eine Scoring-Matrix mit den Kriterien Nutzen, Machbarkeit, Datenlage, Risiko und Messbarkeit besser. Der schnelle Realitäts-Check kommt aber vor jeder Priorisierung.

Welche Gates helfen?

Ein Gate ist ein fest eingeplanter Entscheidungspunkt im Projekt: weitermachen, anpassen oder stoppen. Kontrolliert scheiternde Projekte unterscheiden sich von still verlaufenden fast immer darin, ob solche Gates real sind oder nur auf dem Papier stehen. 3 Gates decken die kritischsten Punkte ab.

Gate 1: nach der Analyse, vor der Priorisierung. Die Prüffrage: Ist das Geschäftsproblem klar, ist eine Person mit Mandat benannt, sind Daten, Systeme und Kompetenzen grob geklärt? Wenn nicht: zurück in die Analyse, nicht weiter in die Umsetzung.

Gate 2: vor dem Pilotstart. Die Prüffrage: Gibt es definierte Erfolgskriterien, einen engen Scope, einen Owner und eine feste Laufzeit? Ein Pilot ohne diese vier Elemente ist ein unbefristeter Testbetrieb ohne Enddatum. Genau der verläuft am ehesten still.

Gate 3: vor der Skalierung. Die Prüffragen: Wurden die Erfolgskriterien mit echten Zahlen statt gefühltem Eindruck erreicht? Ist eine dauerhafte Betriebsverantwortung benannt? Gibt es einen Plan für Schulung und Integration in weitere Teams? Ist eine dieser Fragen offen, ist „skalieren“ verfrüht.

Entscheidend ist, dass an jedem Gate „Stopp“ ebenso legitim ist wie „Weiter“. Ein Gate, an dem faktisch nie gestoppt wird, erzeugt nur den Anschein von Kontrolle. Die MIT-Studie liefert dafür indirekt eine Erklärung. Erfolgreiche Organisationen unterscheiden sich von den 95 Prozent ohne messbaren Effekt vor allem darin, dass sie aus dem Pilotkontext lernen und anpassen. Ohne echte Entscheidungspunkte kann dieser Prozess gar nicht stattfinden.

Risikomatrix: Ursachen und Gegenmaßnahmen

Diese Übersicht fasst 8 Ursachen zusammen. Zu jeder gehören das typische Warnsignal, die wirksamste Gegenmaßnahme und der Prüfzeitpunkt. Sie eignet sich als Kurzcheck vor dem Start eines neuen KI-Vorhabens.

• Unklare Geschäftsziele: Warnsignal ist ein Projekt, das mit „Wir brauchen KI“ statt mit einem Prozessproblem beginnt. Gegenmaßnahme: Geschäftsproblem und Erfolgskriterium vor jeder Tool-Entscheidung festlegen, geprüft vor Gate 1.

• Falscher Use Case: Warnsignal ist die Wahl des spektakulärsten statt des machbarsten Kandidaten. Gegenmaßnahme: Bewertung nach Nutzen, Machbarkeit, Datenlage, Risiko und Messbarkeit, geprüft vor Gate 1 und 2.

• Schlechte Datenqualität: Warnsignal sind verstreute, veraltete oder unzugängliche Informationen. Gegenmaßnahme: Datenlage pro Use Case vor Gate 2 explizit prüfen, nicht annehmen.

• Fehlende Prozessintegration: Warnsignal ist eine Lösung, die im Test läuft, aber nicht im echten Arbeitsablauf. Gegenmaßnahme: den Piloten von Anfang an im realen Workflow testen, nicht in Isolation.

• Fehlende Akzeptanz: Warnsignal ist formale Nutzung ohne echte Integration in den Arbeitsalltag. Gegenmaßnahme: Betroffene vor und während des Piloten einbinden, Nutzen an ihrer Arbeit festmachen.

• Kein Mandat, kein Owner: Warnsignal ist ein Projekt, das bei der ersten Ressourcenkonkurrenz verliert. Gegenmaßnahme: Sponsor in der Geschäftsführung und Owner im Fachbereich vor Gate 1 benennen.

• Zu großer Scope: Warnsignal ist ein fehlendes sichtbares Ergebnis nach mehreren Monaten. Gegenmaßnahme: den Scope vor Gate 2 auf einen Prozess und ein Team begrenzen.

• Gates ohne echte Stopp-Option: Warnsignal sind Projekte, die nie beendet, nur „pausiert“ werden. Gegenmaßnahme: Stopp an jedem Gate als gleichwertiges Ergebnis definieren und kommunizieren.

Eigene Risikomatrix Philogic Labs, zusammengestellt aus den in diesem Artikel zitierten Quellen und eigener Beratungspraxis.

Umsetzung: So senkst du das Scheiternrisiko konkret

Aus den vorherigen Abschnitten folgt ein pragmatisches Vorgehen in 6 Schritten.

1. Vor dem Start: Geschäftsproblem, Sponsor und Owner auf einer Seite schriftlich festhalten, nicht in einem Konzeptdokument. Sind diese drei Punkte nicht klar benennbar, ist es zu früh für einen Piloten.

2. Use-Case-Auswahl: Kandidaten anhand der 5 Warnsignale grob vorsortieren, dann die verbleibenden zwei bis drei mit einer Scoring-Matrix vergleichen.

3. Datencheck vor Zusage: Für den Favoriten konkret prüfen, ob die benötigten Informationen digital, aktuell und zugänglich vorliegen. Nicht annehmen, sondern nachsehen.

4. Pilot mit echtem Gate: Erfolgskriterien, Scope und Laufzeit vor dem Start festlegen und nach Ende tatsächlich messen, nicht subjektiv einschätzen.

5. Akzeptanz von Anfang an mitdenken: Betroffene in die Pilotplanung einbeziehen, nicht erst zur Einführung informieren. Bei Unsicherheit offen über Grenzen der Lösung sprechen, statt sie zu übergehen.

6. Skalierung nur nach bestandenem Gate 3: Betriebsverantwortung, Schulung und Integration klären, bevor weitere Teams folgen.

Du bist unsicher, wo im eigenen Unternehmen die größten Risiken liegen? Ein kostenloses Erstgespräch liefert eine erste Einschätzung, ohne Verpflichtung.

Risiken & Grenzen

Auch dieses Vorgehen garantiert kein Gelingen. Dafür sind Ausgangslagen zu unterschiedlich. Hier sind 4 ehrliche Einschränkungen.

• Gates verhindern kein Scheitern, sie machen es sichtbar und billiger. Ein Projekt, das an Gate 2 gestoppt wird, hat weniger gekostet als eines, das erst nach der Skalierung als Fehlschlag erkannt wird. Das ist der eigentliche Nutzen, keine Erfolgsgarantie.

• Die zitierten Studien beruhen auf größeren, teils internationalen Stichproben. Die grundsätzlichen Muster decken sich mit dem, was ich in deutschen KMU sehe. Die genauen Prozentwerte lassen sich aber nicht eins zu eins auf jedes einzelne Unternehmen übertragen.

• Manche Ursachen liegen außerhalb des einzelnen Projekts. Fehlt die grundlegende IT-Infrastruktur oder sanktioniert die Unternehmenskultur Fehler, statt aus ihnen zu lernen, wirkt kein noch so gutes Gate-Modell vollständig.

• Kosten und Zeit hängen stark vom Einzelfall ab: von der Zahl der Beteiligten, der Komplexität des Prozesses und dem Ausgangszustand der Daten. Belastbare Zahlen liefert nur eine konkrete Analyse im eigenen Unternehmen, keine allgemeine Bandbreite.

Checkliste: KI-Projekte vor dem Scheitern bewahren

Diese 10 Punkte fassen den Artikel zusammen.

1. Das Geschäftsproblem ist konkret benannt: nicht „Wir brauchen KI“, sondern ein abgegrenzter Prozess mit messbarem Schmerzpunkt.

2. Es gibt einen Sponsor in der Geschäftsführung und einen Owner im Fachbereich mit realem Zeitbudget.

3. Der Use Case wurde gegen die fünf Warnsignale geprüft, nicht nur intuitiv gewählt.

4. Die Datenlage wurde konkret geprüft, nicht angenommen.

5. Erfolgskriterien stehen fest, bevor der Pilot beginnt, nicht erst danach.

6. Der Pilot hat einen engen Scope, eine feste Laufzeit und ist im realen Arbeitsablauf eingebettet, nicht isoliert getestet.

7. Betroffene wurden früh eingebunden, nicht erst zur Einführung informiert.

8. Gate 1, 2 und 3 sind terminiert, und „Stopp“ ist an jedem Gate eine akzeptierte, kommunizierte Option.

9. Nach dem Pilot wird tatsächlich gemessen, nicht subjektiv eingeschätzt.

10. Für die Skalierung sind Betriebsverantwortung, Schulung und Integration geklärt, bevor weitere Teams folgen.

Bei mehreren offenen Punkten lohnt ein Blick auf den Cluster-Artikel KI-Strategie mit dem vollständigen Vorgehen von der Analyse bis zur Skalierung. Oder du nutzt einen kostenlosen Erstcheck, der genau diese Punkte für dein Unternehmen konkret durchgeht.