85 Prozent aller Data-Science- und KI-Projekte schaffen es nie in den Produktivbetrieb. Über die Gründe wird kaum gesprochen, denn Misserfolge gelten in der IT-Branche nach wie vor als Schwäche – nicht als Lernquelle. Die Folge: Organisationen wiederholen dieselben teuren Fehler, obwohl sich klare Muster erkennen lassen. Die folgenden sieben KI- und Datenfehlschläge aus dem deutschsprachigen Raum zeigen, woran Projekte wirklich scheitern.
Sieben KI- und Datenfehlschläge: Wo typische Fehler entstehen
Was sind die häufigsten Gründe für das Scheitern von KI- und Datenprojekten? Es sind selten technische Defizite. Entscheidend sind fehlende Use Cases, unklare Verantwortlichkeiten, mangelnde Datenqualität, unrealistische Erwartungen und eine unzureichende Einbindung der späteren Nutzer. Diese Muster treten unabhängig von Branche und Unternehmensgröße auf, wie die folgenden sieben Fälle zeigen.
1. Die neue, nutzlose Plattform
Ein mittelständisches Fertigungsunternehmen mit rund 3.000 Beschäftigten investierte 2,5 Millionen Euro in einen Data Lake auf Azure. Auslöser war kein konkretes betriebliches Problem, sondern ein CEO, der von einem Kongress zurückkehrte und begeistert davon war, was andere Unternehmen mit ihren Datenplattformen machen.
Vor dem Projektstart wurde kein einziger Use Case definiert. Die Fachabteilung wurde nicht befragt, und die Data Owner existierten nur auf dem Papier. Nach zwölf Monaten ging das System live – und der Fachbereich fragte vergeblich nach seinen Reportings. Sechs Monate später nutzten lediglich drei Personen das System. Nach 22 Monaten wurde das Projekt beerdigt. Die Excel-Tabellen, die es ersetzen sollte, werden bis heute gepflegt.
Learning: Ohne mindestens drei konkrete Anwendungsfälle mit benannten Nutzern und messbaren KPIs sollte keine Infrastrukturentscheidung getroffen werden. Eine Datenplattform ist Infrastruktur, kein Produkt. Der Ansatz „Platform first, use cases later“ funktioniert nicht. Die entscheidende Frage vor jedem Projektstart lautet: Wer ändert sein Verhalten, wenn das System live ist?
2. Der schöne Schein des Proof of Concept
Ein Handelsunternehmen wollte seine Nachfrageprognosen automatisieren. Ein externer ML-Dienstleister lieferte im Rahmen eines Piloten eine Genauigkeit von 94 Prozent. Alle jubelten, die erwarteten Einsparungen bei den Lagerkosten lagen bei 30 Prozent.
Was niemand hinterfragt hatte: Der Pilot lief auf bereinigten historischen Daten, nicht auf Produktionsdaten. Saisonale Besonderheiten und Promo-Aktionen waren im Trainingsset nicht repräsentiert, und neue Artikel anzulegen war überhaupt nicht vorgesehen. Beim Rollout brach die Genauigkeit auf 61 Prozent ein. Fehlbestellungen und Lagerkosten stiegen, und das Vertrauen der Belegschaft in das Modell war nach drei Monaten zerstört.
Learning: Ein Proof of Concept und die spätere Produktion müssen dieselbe Datenrealität verwenden. Erfolgsmetriken sind vor dem Pilotprojekt zu definieren, nicht danach. Sonst beantwortet der Pilot zwar Fragen – aber die falschen.
3. Geschwindigkeitsgier mit verheerenden Folgekosten
Anfang 2023 kam ein CEO aus dem Urlaub zurück, in dem er sich mit dem damals neuen ChatGPT beschäftigt hatte. Seine Schlussfolgerung: „Das brauchen wir für unseren Kundendienst – und zwar bis Ende des Quartals.“
So wurde ein LLM-Chatbot auf Basis einer internen Dokumentation aufgesetzt – ohne Data Governance, ohne Grounding auf validierten Daten und ohne strukturierte Testphase. Das Ergebnis: Der Bot gab falsche Preise aus, erfand Produkteigenschaften und widersprach den eigenen AGB. Nach drei Kundenbeschwerden in der ersten Woche wurde das Projekt sofort gestoppt. Zurück blieb ein Reputationsschaden und eine Belegschaft, die KI-Projekten gegenüber nachhaltig verunsichert war.
Learning: Ein LLM ohne Grounding auf validierten Daten ist kein Kundenservice-Tool, sondern ein unkontrolliertes Risiko. Wer überstürzt vorgeht, macht das Projekt langfristig teurer. Ein bedächtiger Ansatz mit durchdachter Architektur, etwa über RAG-Verfahren, lohnt sich hingegen.
4. Das funktionale System, das niemand wollte
Ein Logistikunternehmen ließ über zwölf Monate ein umfassendes BI-Dashboard entwickeln – weitgehend ohne Einbindung der späteren Nutzer. Der interne Launch war professionell aufgesetzt. Drei Monate später lag die Adoptionsrate jedoch bei unter fünf Prozent. Die Fachabteilungen arbeiteten weiterhin mit ihren eigenen Excel-Auswertungen, weil die neue Plattform ihre tatsächlichen Probleme nicht löste.
Learning: Rund 70 Prozent aller Transformationsprojekte scheitern an mangelnder Nutzerakzeptanz. Um das zu verhindern, müssen Stakeholder ab Tag eins eingebunden werden, nicht erst zur Abnahme. Change Management ist kein Add-on für das Projektende, sondern eine Kernaufgabe von Beginn an.
5. Die Architektur, die das System überlebte
Ein Industrieunternehmen entwickelte ein ML-Modell zur Qualitätskontrolle, das in der Pilotphase hervorragend funktionierte. Für die Skalierung entschied sich das Team für eine Microservices-Architektur mit zwölf Services – für eine Anwendung mit zunächst 30 internen Nutzern.
Die Setup-Zeit betrug acht Monate, die Kosten lagen deutlich über Plan. Als der ursprüngliche Architekt das Unternehmen verließ, konnte niemand das System mehr warten. Also wurde es abgeschaltet.
Learning: Over-Engineering ist eine systematisch unterschätzte Projektfalle. Was man heute braucht, schlägt fast immer das, was man in fünf Jahren vielleicht brauchen könnte. Einfache Architekturen, die das Team versteht und warten kann, sind komplexen Konstrukten vorzuziehen. Maintainability schlägt den schönen Schein.
6. Eingeholt von der Datenqualität
Ein Konsumgüterhersteller startete ein ambitioniertes Predictive-Analytics-Projekt. Erst nach drei Monaten Modellentwicklung stellte sich heraus, dass die Quelldaten in einem desolaten Zustand waren: Kundennamen in fünf Schreibweisen, inkonsistente Datumsformate, fehlende Werte in Schlüsselfeldern, keine klaren Verantwortlichkeiten.
Das Data-Science-Team verbrachte rund 70 Prozent seiner Zeit mit der Bereinigung der Daten, statt mit der Modellentwicklung. Das Projektziel verschob sich um neun Monate.
Learning: Garbage in, Garbage out ist eine bekannte Formel, wird aber selten beherzigt. Datenqualitätsprüfungen gehören an den Anfang eines Projekts, nicht in die Mitte. Data Ownership muss vor dem Start geklärt sein, und mindestens 30 Prozent des Budgets sollten realistischerweise für Data Engineering eingeplant werden.
7. Wenn Management-Erwartungen auf die Realität treffen
Ein Finanzdienstleister startete ein KI-Projekt zur Betrugserkennung. Das Management erwartete 99 Prozent Genauigkeit wie im Forschungs-Whitepaper – sofort einsatzbereit und ohne menschliche Nachkontrolle.
Das beste Modell erreichte auf realen Produktionsdaten 78 Prozent. Für die Branche ist das ein solides Ergebnis, das deutliche Kosteneinsparungen ermöglicht hätte. Das Management betrachtete das Projekt jedoch als Misserfolg und stellte es ein.
Learning: KI-Modelle aus akademischen Publikationen funktionieren auf bereinigten Benchmark-Daten unter Laborbedingungen – nicht zwingend in der eigenen Produktionsumgebung. Realistische Erwartungen sollten deshalb früh und schriftlich festgehalten werden. Ein Human-in-the-Loop-Konzept ist keine Schwäche, sondern notwendige Qualitätssicherung. Und der MVP-Ansatz gilt auch für KI: 80 Prozent Genauigkeit sind oft gut genug, wenn das Ziel von Anfang an klar ist.
Die Fallanalysen machen deutlich: Technologie ist selten das eigentliche Hindernis. Es sind die organisationalen Muster, die Projekte scheitern lassen – fehlende Zielklarheit, ausweichende Kommunikation und eine Kultur, in der Fehler verschwiegen werden. Unternehmen, die ihre KI-Initiativen retten wollen, brauchen keine besseren Algorithmen, sondern ehrliche Reviews und eine Führung, die Misserfolge als Datenquelle betrachtet.
