Warum KI-Projekte scheitern: Ursachen und Gegenmaßnahmen

Problem und Zielgruppe: Wenn KI-Projekte im Sande verlaufen

Ein Pilotprojekt startet mit Rückenwind, ein Tool wird angeschafft, ein Team probiert es aus – und 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: Nutzung sinkt, die ursprünglichen Fürsprecher sind mit anderen Themen beschäftigt, und 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 in Unternehmen keinen messbaren wirtschaftlichen Nutzen – nur etwa 5 Prozent schaffen es, aus einem Pilot echten operativen oder finanziellen Effekt zu ziehen. Die Studie beruht auf einer Auswertung von mehr als 300 öffentlich dokumentierten KI-Initiativen, 52 strukturierten Interviews und 153 Umfrageantworten von Führungskräften, erhoben zwischen Januar und Juni 2025. Bemerkenswert ist eine Detailzahl daraus: Von Fachanbietern eingekaufte oder in Partnerschaft entwickelte Lösungen erreichen eine Erfolgsquote von rund 67 Prozent, intern selbst entwickelte Lösungen 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, dass inzwischen 54,5 Prozent der deutschen Unternehmen KI in ihren Geschäftsprozessen einsetzen, gegenüber 40,9 Prozent im Vorjahr – bei Großunternehmen sind es bereits 67,2 Prozent, bei mittleren Unternehmen 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 im Unternehmen blockiert.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die entweder aus einem gescheiterten Anlauf lernen oder einen neuen Anlauf von vornherein robuster aufsetzen wollen. 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 um KI-Projekte zu unscharf verwendet. Für diesen Artikel unterscheide ich drei Fälle, die unterschiedliche Konsequenzen haben:

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

Die meisten der öffentlich diskutierten „gescheiterten KI-Projekte” fallen in die zweite Kategorie. Deshalb ist die zentrale Frage dieses Artikels nicht „Wie verhindere ich einen spektakulären Fehlschlag?”, sondern „Wie erkenne ich frühzeitig, 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 drei hier zitierten Quellen hinweg wiederholt sich ein Muster: Die Ursache liegt selten im Modell selbst. Fünf Ursachenblöcke tauchen immer wieder auf.

1. Unklare Geschäftsziele. Das Projekt beginnt mit einer Technologie-Entscheidung („Wir brauchen KI”) statt mit einem Geschäftsproblem. Ohne definiertes Ziel gibt es auch keinen Maßstab, an dem sich später Erfolg oder Misserfolg festmachen lässt – das Projekt kann gar nicht scheitern, weil es nie definiert war, woran es gemessen wird. Genau das macht Kategorie zwei, das stille Verlaufen, so wahrscheinlich.

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

3. Datenqualität und -zugänglichkeit. Nach Angaben von Gartner-Analystin Rita Sallam, zitiert in einer Prognose vom Juli 2024, gehören ausufernde Kosten, unklarer Geschäftswert, schlechte Datenqualität und unzureichende Risikokontrollen zu den Hauptgründen, warum Unternehmen mindestens 30 Prozent ihrer Generative-AI-Projekte nach der Proof-of-Concept-Phase wieder einstellen. Datenqualität ist darin kein Randthema, sondern einer der am häufigsten genannten Gründe.

4. Fehlende Integration in bestehende Prozesse. Ein Pilot, der im Testsystem gut funktioniert, aber nie an die tatsächlichen Arbeitsabläufe, Systeme und Verantwortlichkeiten angebunden wird, bleibt ein Experiment. Genau das beschreibt die MIT-Studie als zentralen Unterschied zwischen den 5 Prozent erfolgreicher und den 95 Prozent wirkungsloser Pilotprojekte: Erfolgreiche Vorhaben lernen aus dem Kontext und passen sich an Arbeitsabläufe an, generische Tools ohne diese Anpassung bleiben stecken.

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

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

Welche Fehler entstehen vor der Entwicklung?

Die teuersten Fehler passieren, bevor die erste Zeile Konfiguration oder Code geschrieben wird – weil sie sich später kaum noch korrigieren lassen, ohne von vorn zu beginnen.

• 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 gibt es niemanden, der nach dem Go-Live noch hinschaut.
• 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 stellt sich heraus, dass die benötigten Informationen unvollständig, veraltet oder über mehrere Systeme verstreut sind. Das kostet nicht nur Zeit, sondern untergräbt das Vertrauen ins Vorhaben insgesamt.
• 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 größer das Risiko, dass die Geduld vorher aufgebraucht ist.

In meiner Arbeit sehe ich diese Fehler fast nie isoliert. Typisch ist eine Kombination aus fehlendem Mandat und zu großem Scope: Ohne einen Sponsor, der Prioritäten setzt, wächst der Anspruch des Projekts, weil sich niemand traut, den Umfang zu begrenzen – „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 sind sie einer der am häufigsten unterschätzten Gründe, warum technisch funktionierende Lösungen trotzdem in Kategorie zwei landen, dem stillen Verlaufen. Drei Muster wiederholen sich:

Fehlende Einbindung. Wenn eine Lösung „für” statt „mit” den Betroffenen entwickelt wird, fehlt das Wissen über die tatsächliche Arbeitsrealität – und es fehlt 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 dadurch leichter, schneller, weniger frustrierend – oder wird zusätzlicher Aufwand auf mich verlagert, ohne dass ich etwas davon habe?

Unadressierte Sorgen. Die Sorge um den eigenen Arbeitsplatz, um Kontrollverlust oder um Verantwortung für Fehler, die die KI gemacht hat, verschwindet nicht durch Schweigen. Sie äußert sich stattdessen in stiller Verweigerung: Das Tool wird formal genutzt, aber nicht wirklich in den Arbeitsalltag integriert. Genau hier setzt auch 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 hier doppelt – als Kompetenzaufbau und als Akzeptanzarbeit in einem.

Der 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 bestimmten 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 einen konkret benannten, abgegrenzten Arbeitsschritt lässt sich weder Aufwand noch Nutzen seriös schätzen.
• Keine Vorher-Nachher-Messbarkeit. Wenn sich vorher nicht sagen lässt, 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 direkt und ungeprüft nach außen oder in eine folgenreiche Entscheidung wirkt, sind für den Einstieg ungeeignet – unabhängig vom theoretischen Nutzen.
• Schlechte oder nicht zugängliche Datenlage. Wenn die benötigten Informationen nicht in digitaler, aktueller und zugänglicher Form vorliegen, ist der Use Case nicht reif – unabhängig davon, wie überzeugend die Idee klingt.
• Der Use Case soll vor allem beeindrucken. Ein Vorhaben, das primär auf einer Demo oder einem Konferenzbeitrag beruht statt auf einem echten internen Engpass, hat selten einen Owner, der es über die Pilotphase hinaus trägt.

Wer diese fünf Punkte vor dem Start prüft, sortiert die meisten Fehlkandidaten aus, bevor sie Ressourcen binden. Das ist kein Ersatz für eine strukturierte Bewertung mehrerer Kandidaten – dafür eignet sich eine Scoring-Matrix mit den Kriterien Nutzen, Machbarkeit, Datenlage, Risiko und Messbarkeit besser –, aber es ist der schnelle Realitäts-Check, bevor überhaupt priorisiert wird.

Welche Gates helfen?

Ein Gate ist ein fest eingeplanter Punkt im Projekt, an dem eine begründete Entscheidung getroffen wird: weitermachen, anpassen oder stoppen. Der Unterschied zwischen Projekten, die kontrolliert scheitern (unproblematisch), und Projekten, die still verlaufen (teuer), liegt fast immer darin, ob solche Gates real sind oder nur auf dem Papier stehen.

Drei Gates decken die kritischsten Punkte ab:

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

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

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

Entscheidend ist, dass an jedem Gate „Stopp” eine ebenso legitime Entscheidung 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 dadurch, dass sie aus dem Pilotkontext lernen und anpassen – ein Prozess, der ohne echte Entscheidungspunkte gar nicht stattfinden kann.

Risikomatrix: Ursachen und Gegenmaßnahmen

Die folgende Matrix fasst die in diesem Artikel behandelten Ursachen, ihre typischen Warnsignale und die wirksamste Gegenmaßnahme zusammen. Sie eignet sich als Kurzcheck vor dem Start eines neuen KI-Vorhabens.

Ursache	Typisches Warnsignal	Wirksamste Gegenmaßnahme	Wann prüfen
Unklare Geschäftsziele	Projekt beginnt mit „Wir brauchen KI”, nicht mit einem Prozessproblem	Konkretes Geschäftsproblem und Erfolgskriterium vor jeder Tool-Entscheidung festlegen	Vor Gate 1
Falscher Use Case	Spektakulärster statt machbarster Kandidat wird gewählt	Bewertung nach Nutzen, Machbarkeit, Datenlage, Risiko, Messbarkeit	Vor Gate 1/2
Schlechte Datenqualität	Informationen verstreut, veraltet oder nicht zugänglich	Datenlage pro Use Case explizit prüfen, nicht annehmen	Vor Gate 2
Fehlende Prozessintegration	Lösung läuft im Test, aber nicht im echten Arbeitsablauf	Pilot von Anfang an im realen Workflow testen, nicht in Isolation	Während Pilot
Fehlende Akzeptanz	Formale Nutzung ohne echte Integration in den Arbeitsalltag	Betroffene früh einbinden, Nutzen konkret an ihrer Arbeit festmachen	Vor und während Pilot
Kein Mandat / kein Owner	Projekt verliert bei erster Ressourcenkonkurrenz	Sponsor in der Geschäftsführung und Owner im Fachbereich vor Start benennen	Vor Gate 1
Zu großer Scope	Kein sichtbares Ergebnis nach mehreren Monaten	Scope auf einen Prozess, ein Team begrenzen	Vor Gate 2
Gates ohne echte Stopp-Option	Projekte werden nie beendet, nur „pausiert”	Stopp als gleichwertiges Ergebnis jedes Gates definieren und kommunizieren	An jedem Gate

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 lässt sich ein pragmatisches Vorgehen ableiten, das sich mit überschaubarem Aufwand umsetzen lässt:

1. Vor dem Start: Geschäftsproblem, Sponsor und Owner schriftlich festhalten – auf einer Seite, nicht in einem Konzeptdokument. Wenn diese drei Punkte nicht klar benennbar sind, ist es zu früh für einen Piloten.
2. Use-Case-Auswahl: Kandidaten anhand der fünf Warnsignale aus dem Abschnitt zum falschen Use Case grob vorsortieren, dann die verbleibenden zwei bis drei mit einer Scoring-Matrix vergleichen.
3. Datencheck vor Zusage: Für den favorisierten Use Case 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. Wo Unsicherheit besteht, 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.

Wer an diesem Vorgehen unsicher ist, wo im eigenen Unternehmen die größten Risiken liegen, bekommt in einem kostenlosen Erstgespräch eine erste Einschätzung, ohne Verpflichtung.

Risiken & Grenzen

Auch dieses Vorgehen garantiert kein Gelingen – dafür sind Ausgangslagen zu unterschiedlich. Ein paar 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, nicht eine Erfolgsgarantie.
• Die zitierten Studien beziehen sich überwiegend auf größere Stichproben und teils auf US-amerikanische oder international gemischte Unternehmen. Die grundsätzlichen Muster – unklare Ziele, Datenprobleme, fehlende Integration, Akzeptanzlücken – decken sich mit dem, was ich in deutschen KMU sehe, aber die genauen Prozentwerte lassen sich nicht eins zu eins auf jedes einzelne Unternehmen übertragen.
• Manche Ursachen liegen außerhalb des Einflussbereichs eines einzelnen Projekts. Wenn die grundlegende IT-Infrastruktur fehlt oder die Unternehmenskultur Fehler grundsätzlich sanktioniert statt aus ihnen zu lernen, wirkt kein noch so gutes Gate-Modell vollständig.
• Kosten und Zeit für die Umsetzung der hier beschriebenen Maßnahmen hängen stark vom Einzelfall ab – von der Zahl der Beteiligten, der Komplexität des Prozesses und dem Ausgangszustand der Daten. Belastbare Zahlen dafür liefert nur eine konkrete Analyse im eigenen Unternehmen, keine allgemeine Bandbreite.

Checkliste: KI-Projekte vor dem Scheitern bewahren

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 eines falschen Use Case 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.

Wenn du bei mehreren Punkten unsicher bist, lohnt sich ein Blick auf den Cluster-Artikel KI-Strategie für das vollständige Vorgehen von der Analyse bis zur Skalierung – oder ein kostenloser Erstcheck, der genau diese Punkte für dein Unternehmen konkret durchgeht.