7 lehrreiche KI- und Daten-Fuckups

Scheitern ist kein Problem. Nicht darüber zu sprechen, sehr wohl.DC Studio | shutterstock.com



85 Prozent aller Data-Science- und KI-Projekte schaffen es nie in die Produktion. Das belegen etwa vielzitierte Zahlen von Gartner. Trotzdem wird auf Konferenzen sowie in Fachmedien fast ausschließlich über Erfolgsgeschichten berichtet.



Die, die weniger erfolgreich sind, schweigen hingegen. Und das hat seinen Preis: So machen andere Unternehmen dann dieselben teuren Fehler. Die Technologie ist dabei allerdings selten ursächlich dafür, dass Projekte dieser Art scheitern. Vielmehr liegt das an den immer gleichen, übergeordneten Mustern:




Technik und Business sprechen nicht über echte Ziele.



Teams und Management lassen tatsächliche Risiken aussen vor.



Unternehmen tauschen sich nicht untereinander über ihre Misserfolge aus.




Das ist auch deshalb so, weil Fehler, besonders im IT-Umfeld, häufig immer noch als Schwäche wahrgenommen werden, statt als Lernquelle. Solange das so bleibt, werden Daten- und KI-Projekte in Organisationen stets an denselben Stellen scheitern. Der erste Schritt zur Besserung wäre dabei denkbar einfach: Man müsste beim nächsten Projekt-Review einfach nur ehrlich miteinander darüber sprechen, was schiefgelaufen ist – und warum.



Das hätte vielleicht auch den sieben Unternehmen geholfen, denen die folgenden anonymisierten Fuckups entsprungen sind. Sie alle repräsentieren die vorgenannten Fail-Muster und verdeutlichen, wie sich Kommunikationsfehler zwar in unterschiedlicher Ausprägung, aber unabhängig von Branche oder Unternehmensgröße, immer wieder wiederholen.



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 dafür war jedoch kein konkretes betriebliches Problem, sondern ein CEO, der von einem Kongress zurückkehrte – voller Begeisterung darüber, was andere machen.



Vor Projektstart wurde kein einziger Use Case definiert, der Fachbereich nie befragt und Data Owner existierten lediglich auf dem Papier. Nach zwölf Monaten erfolgte dann der Go-Live. Und der Fachbereich wunderte sich, wo seine Reportings zu finden sind. Diese gab es schlicht nicht mehr. Sechs Monate später nutzten dann ganze drei Personen das System. 22 Monate später wurde das Projekt schließlich beerdigt. Die alten Excel-Sheets, die damit hätten ersetzt werden sollen, leben bis heute weiter.



Learning: Ohne mindestens drei konkrete Anwendungsfälle mit benannten Nutzern und messbaren KPIs sollte deshalb keine Infrastrukturentscheidung getroffen werden. Eine Datenplattform ist Infrastruktur, kein Produkt. Der Ansatz „Platform first, use cases later“ funktioniert deshalb nicht – beziehungsweise nie. Die entscheidende Frage vor jedem Projektstart lautet: „Wer ändert sein Verhalten, wenn das System live ist?“



2. Der schöne Schein des POC



Ein Handelsunternehmen wollte seine Nachfrageprognosen automatisieren. Ein externer ML-Dienstleister lieferte im Rahmen eines Piloten einen Genauigkeitswert von 94 Prozent – alle jubelten, die erwartete Einsparung bei den Lagerkosten lag bei 30 Prozent.



Was allerdings niemand hinterfragt hatte: Besagter POC lief auf bereinigten, historischen Daten, nicht denen der Produktion. Saisonale Besonderheiten und Promo-Aktionen waren im Trainingsset deshalb nicht repräsentiert, neue Artikel anzulegen, erst gar nicht vorgesehen. Zum Rollout des Systems brach dessen Genauigkeit auf 61 Prozent ein. Die Fehlbestellungen und Lagerkosten stiegen, das Vertrauen der Belegschaft in das Modell war nach drei Monaten zerstört.



Learning: POC und Produktion benötigen dieselbe Datenrealität – und Erfolgsmetriken müssen vor einem Proof of Concept definiert werden, nicht danach. Ansonsten beantwortet der Pilot zwar Fragen, aber eben die falschen.



3. Geschwindigkeitsgier mit verheerenden Folgekosten



Anfang 2023 kam ein CEO aus dem Urlaub zurück, in dem er sich mit dem damals gerade neu veröffentlichten ChatGPT beschäftigt hatte. Seine Schlussfolgerung: „Das brauchen wir für unseren Kundendienst – und zwar bis zum Ende dieses Quartals.“



Also wurde ein LLM-Chatbot auf Basis einer internen Dokumentation aufgesetzt – ohne Data Governance, Grounding auf validierten Daten oder strukturierte Testphase. Das Ergebnis: Der Bot gab falsche Preise aus, erfand Produkteigenschaften und widersprach den AGBs des Unternehmens. Nach drei Kundenbeschwerden in der ersten Woche erfolgte der sofortige Rückzug aus dem Projekt. Was blieb, war ein nachhaltiger Reputationsschaden. Zudem wurde das Vertrauen der Belegschaft in KI-Projekte auf Monate hinaus erschüttert.



Learning: Ein LLM ohne Grounding auf validierten Daten – heute typischerweise über RAG-Architekturen realisiert – ist kein Kundenservice-Tool, sondern ein unkontrolliertes Risiko. Die Erkenntnis: Wer überstürzt vorgeht, für den wird das Projekt langfristig deutlich teurer. Ein bedächtiger und dafür durchdachter Ansatz 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 aufwendig und professionell gestaltet. Drei Monate später lag die Adoptionsrate allerdings bei unter fünf Prozent. Die Fachabteilungen arbeiteten lieber weiterhin mit ihren eigenen Excel-Auswertungen. Der Grund war ernüchternd: Die neue Plattform konnte die Probleme der Anwender nicht lösen.



Learning: 70 Prozent aller Transformationsprojekte scheitern daran, dass sie von den Benutzern nicht angenommen werden. Um das zu ändern, gilt es, Stakeholder ab Tag eins einzubinden, nicht erst zur Abnahme. Anders ausgedrückt: Change Management ist kein Add-On, das am Projektende hinzugefügt wird, sondern stellt ab Projektbeginn eine Kernaufgabe dar.



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 hochkomplexe Microservices-Architektur mit zwölf Services – für eine Anwendung mit anfangs 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 mehr das System warten. Also wurde es letztlich 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 – auch wenn letztere auf dem Papier eleganter wirken. 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 verschiedenen Schreibweisen, inkonsistente Datumsformate, fehlende Werte in Schlüsselfeldern, keine klaren Datenverantwortlichkeiten.



Das Data-Science-Team verbrachte anschließend rund 70 Prozent seiner Zeit damit, Daten zu bereinigen – statt mit der Modellentwicklung. Das Projektziel verschob sich daraufhin um ganze neun Monate.



Learning: Garbage In, Garbage Out – die Formel ist bekannt. Leider werden dennoch selten entsprechende Konsequenzen gezogen: Datenqualitätsprüfungen gehören an den Anfang eines jedes Projekts, nicht „irgendwo in die Mitte“. Data Ownership ist etwas, das vor Projektstart geregelt sein muss. 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. Die Erwartung seitens des Managements war klar: 99 Prozent Genauigkeit wie im Forschungs-Whitepaper, sofort einsatzbereit, komplett ohne menschliche Nachkontrolle.



Das beste Modell erreichte auf realen Produktionsdaten dann 78 Prozent – für die Branche ein solides Ergebnis, das signifikante Kosteneinsparungen ermöglicht hätte. Das Management betrachtete das Projekt dennoch als Misserfolg und stellte es ein.



Learning: KI-Modelle aus akademischen Publikationen funktionieren auf bereinigten Benchmark-Datensätzen unter Laborbedingungen – nicht zwingend auf der eigenen Produktionsumgebung mit all ihren Unschärfen. Deshalb sollten realistische Erwartungen möglichst früh, explizit und schriftlich festgehalten werden. Das Human-in-the-Loop-Konzept ist dabei oft keine Schwäche, sondern im Sinne der Qualitätssicherung notwendig. Außerdem gilt der MVP-Ansatz auch für KI: 80 Prozent Genauigkeit sind oft gut genug – wenn das Ziel von Anfang an klar definiert ist. (fm)



Dieser Beitrag wurde im Rahmen des deutschsprachigen Experten-Netzwerks von Foundry veröffentlicht. Lust mitzumachen? Jetzt bewerben!