Warum 95 Prozent der KI-Projekte scheitern, und wie man seines rettet

Die Zahl, über die niemand gerne spricht

Im August 2025 hat die MIT NANDA Initiative eine Studie veröffentlicht, die in der Branche für lange Gesichter gesorgt hat. Die Kernaussage: 95 % der enterprise GenAI-Pilotprojekte liefern keinen messbaren Profit-and-Loss-Impact. Nur rund 5 % erreichen tatsächlich eine Umsatzbeschleunigung. Die Methodik war solide: 150 Interviews, 350 Mitarbeiter-Umfrage, 300 ausgewertete Public Deployments.

Die Zahl steht nicht allein. Gartner schätzt, dass 50 % aller GenAI-Projekte nach dem Proof-of-Concept abgebrochen werden. Nur 48 % der AI-Initiativen überwinden überhaupt die Pilotphase. Der Weg vom Prototyp zur Produktion dauert im Schnitt 8 Monate. Bis Ende 2026 sollen laut Prognose 60 % der AI-Projekte ohne AI-ready data komplett eingestellt werden.

S&P Global bestätigt die Dynamik: 42 % der Unternehmen haben 2025 die meisten ihrer KI-Initiativen abgebrochen, 2024 waren es noch 17 %. Die Boston Consulting Group fand in ihrer Studie „Build for the Future 2025" (1.250 Unternehmen), dass nur 5 % AI-Wert at scale erzielen, 60 % keinerlei materiellen Nutzen sehen, und 35 % zu langsam skalieren. RAND Corporation nennt eine 80 %-Scheiterquote für KI-Projekte, doppelt so hoch wie bei klassischen IT-Projekten.

Die gute Nachricht: Die Scheitergründe sind gut dokumentiert. Das meiste ist reparierbar. Aber nur, wenn man weiß, wo man hinschauen muss.

Warum KI-Projekte scheitern, die fünf häufigsten Muster

1. Datenqualität ist das wahre Problem

Gartner führt 85 % aller KI-Fehlschläge auf schlechte Datenqualität zurück. Bei KMU im DACH-Raum ist das Bild eindeutig: 76 % kämpfen mit unzureichender Datenqualität und Datensilos, 83 % haben keine Datenstrategie.

Das bedeutet in der Praxis: Ein RAG-System wird auf 500 PDFs losgelassen, in denen sich dieselbe Information in drei verschiedenen, teilweise widersprüchlichen Versionen findet. Das System antwortet dann irgendwas, es kann ja nicht entscheiden, was richtig ist. Die Halluzinationsquote liegt laut Messungen bei 52 % bei ungepflegten Wissensbasen und nähert sich null bei kuratierten Daten. Der Unterschied kommt nicht vom Modell. Er kommt von der Vorarbeit.

2. Organisation schlägt Technik

Die MIT-Studie und Harvard Business Review aus November 2025 sind deutlich: Die Modelle sind nicht das Problem. Es fehlen Integration, Prozesse, Governance. Eine HBR/Fortune-Umfrage von Dezember 2025 zeigt, dass nur 6 % der Unternehmen AI-Agents Kernprozesse zutrauen. Es liegt nicht an technischen Grenzen. Es fehlt das Vertrauen in die Kontrollmechanismen.

Ein KI-System, das ohne klare Prozess-Integration, Governance und menschliche Letztentscheidung eingeführt wird, scheitert nicht technisch. Es scheitert, weil niemand weiß, wem es in welcher Situation gehört.

3. Build oder Buy, und die Falle des Mittelwegs

Die MIT-Daten zeigen einen auffälligen Unterschied: Spezialisierte Vendor-Tools haben eine Erfolgsquote von 67 %. Interne Eigenbauten kommen auf nur 22 %.

Das liegt nicht daran, dass interne Teams schlechter arbeiten. Eigenbau-Projekte starten oft ohne klares Produktverständnis. Es wird „etwas mit KI" gebaut, ohne dass das Problem, das es lösen soll, vorher klar definiert war. Vendor-Tools kommen mit einem fokussierten Scope. Eigenbau-Projekte neigen zum Feature-Wachstum ohne Abschluss-Kriterium.

Der gefährlichste Mittelweg: Vibe-Coded MVPs, die mit Tools wie Lovable, Cursor oder Replit in wenigen Tagen entstehen und dann in Produktion gehen. Die kommen schnell, sehen gut aus und haben eine ganze Reihe von Problemen, die erst spät sichtbar werden.

4. Vibe-Coding: Schnell gebaut, schwer zu reparieren

Ein Phänomen, das 2024/2025 große Verbreitung gefunden hat: Geschäftsführer, Marketing-Leute, technisch interessierte Mitarbeiter bauen mit Lovable, Claude Code, Cursor, Replit, Devin, v0 Anwendungen, die sie vor einem Jahr noch nicht hätten bauen können. Manches davon ist großartig. Manches davon ist ein Sicherheitsalbtraum.

Konkrete Belege:

• Lovable Security-Desaster: Von 1.645 untersuchten Lovable-Apps hatten 170 (über 10 %) kritische Row-Level-Security-Lücken in der Datenbank (CVE-2025-48757). Drei dokumentierte Vorfälle mit exponiertem Source Code, Datenbank-Credentials und Userdaten. Eine BOLA-Vulnerability blieb 48 Tage offen.
• Tenzai-Benchmark (5 Tools, 15 identische Anwendungen gebaut): 69 Vulnerabilities, davon 6 kritische. Getestet wurden Claude Code, OpenAI Codex, Cursor, Replit, Devin.
• Cursor CurXecute (CVE-2025-54135): Remote Command Execution über manipulierten Kontext.
• Claude Code (CVE-2025-55284): Datenexfiltration via DNS bei Prompt-Injection über automatisch ausgeführte Utilities.

Allgemein: Studien zeigen, dass 40 bis 62 % des AI-generierten Codes Security-Vulnerabilities enthält. Der Code-Churn steigt um 41 %, die Code-Duplizierung vervierfacht sich, und 63 % der Entwickler verbringen mehr Zeit mit Debugging, als sie durch KI-Unterstützung sparen.

Das heißt nicht, dass diese Tools unbrauchbar sind. Es heißt, dass das, was in 3 Tagen entsteht, nicht ohne Review in Produktion gehen sollte. Wer sich einen Chatbot, eine interne App oder einen Workflow mit diesen Werkzeugen baut, hat einen Prototyp, keinen Produktionsstand.

5. Wenn no-code in Produktion bricht

Auch bei No-Code-Automatisierungen (n8n, Make, Zapier) gibt es typische Bruchstellen, die im Test unentdeckt bleiben und in Produktion teuer werden:

• API-Rate-Limits (HTTP 429), die unter Last plötzlich greifen und Workflows zum Fallen bringen
• Breaking Changes in externen APIs, die ohne Warnung durchschlagen
• Credential- und Umgebungsvariablen-Drift beim Export und Import
• Memory-Exhaustion bei komplexen Loops ohne Batching
• Stille Fehler: In der Community dokumentierter Fall, ein DataForSEO-Workflow war 11 Tage lang kaputt, niemand bemerkte es. Kein globaler Error-Trigger, kein Logging, keine Alarmierung.

Die empfohlene Gegenmaßnahme: Drei-Schichten-Fehlerbehandlung (Node-Retry auf Operationsebene, globaler Error-Workflow als Sicherheitsnetz, zentrales Logging). Das wird in den meisten DIY-Workflows übersprungen, weil es mühsam ist. Dann bricht die Automatisierung irgendwann, und niemand merkt es, bis der Lieferant anruft.

RAG-Halluzinationen im Detail

Für Unternehmen, die einen internen KI-Assistenten (CompanyGPT, Support-Bot, Wissensbasis) eingeführt haben, ist Halluzination der häufigste Schmerzpunkt. Die aktuelle Forschungslage (u. a. MDPI Review 2025, Future AGI 2025) identifiziert drei dominante Muster:

Fabricated Statistics: Das Modell erfindet Zahlen aus abgerufenen Textpassagen, statt sie zu berechnen. Typisch: Eine Quelle enthält „im letzten Jahr stiegen die Umsätze um 15 %"; das Modell zitiert dann in einer völlig anderen Antwort „die Umsätze sind um 15 % gestiegen", obwohl das für den aktuellen Kontext gar nicht zutrifft.

Incomplete Retrieval: Die Vektorsuche verpasst die relevanten Chunks. Gründe: zu grobe Chunk-Größe, schlechte Embedding-Qualität, zu niedriges Top-k, fehlende Hybrid-Suche mit Keywords. Das Modell bekommt dann Kontext, der nur teilweise passt, und ergänzt das Fehlende aus dem eigenen Training.

Out-of-Domain Fabrication: Bei fehlenden Daten liefert das Retrieval „ähnlich aussehende" Treffer, und das LLM halluziniert darauf. Statt „Dazu finde ich keine Information" gibt es eine plausibel klingende Antwort ohne echte Grundlage.

Moderne Ansätze (MEGA-RAG und ähnliche Multi-Evidence-Frameworks, 2025) erreichen eine Reduktion der Halluzinationen um über 40 % gegenüber Baseline. Die Architektur-Upgrades sind überschaubar, aber sie müssen gemacht werden.

Reparieren oder neu bauen?

Wenn ein KI-Projekt nicht funktioniert, steht die Frage: Lohnt sich die Reparatur, oder ist ein Neuaufbau günstiger?

Die Literatur (u. a. das Vikram-Rao-Framework und der SoftwareSeni CTO-Guide 2025) bietet sechs Leitfragen:

1. Ist die Architektur tragfähig? Kann das System bei moderaten Erweiterungen noch gewartet werden, oder ist es in sich selbst verfangen?
2. Versteht das Team das System noch? Wenn niemand erklärt, was der Code tut, ist jede Reparatur ein Glücksspiel.
3. Kann inkrementell geliefert werden? Kleine Fixes, die sofort Wert bringen, vs. ein monatelanger Big-Bang-Rewrite.
4. Wie kritisch ist Continuity? Ein System in Produktion mit echten Nutzern ist anders zu behandeln als ein Prototyp ohne Last.
5. Wurde Refactoring schon versucht? Und wie ist es gelaufen? Wiederholtes Scheitern beim Refactoring ist ein Signal.
6. Gibt es Sicherheitsprobleme, die sofort adressiert werden müssen? Bei aktiven Vulnerabilities kann eine Neuentwicklung die einzige sichere Option sein.

Wenn drei oder mehr dieser Fragen in Richtung Rewrite zeigen, ist ein Neuaufbau zu erwägen. Die Strangler-Pattern-Strategie, das alte System Stück für Stück durch neue Komponenten ersetzen, während beides parallel läuft, ist in den meisten Fällen die sicherere Wahl als ein Big-Bang-Rewrite. Letzterer hat historisch eine extrem hohe Scheiterquote und Budget-Überschreitungen, die sich über Jahre ziehen.

Eine praxisnahe Heuristik: „Bad code that delivers value is not the same as bad code that blocks the business." Nur letzteres rechtfertigt einen Rewrite. Funktionierender, aber unschöner Code ist in den meisten Fällen besser als ein gestoppter Neuaufbau nach sechs Monaten.

Typische Reparatur-Pfade

Aus der Praxis lassen sich drei Muster unterscheiden, die sich meistens wirtschaftlich reparieren lassen:

Der halluzinierte Chatbot

Ursache meistens: schlechte Retrieval-Qualität, fehlende Hybrid-Suche, kein Metadaten-Filter, zu große Chunks. Die Reparatur umfasst typischerweise: Neuindexierung mit besserer Chunk-Strategie, Umstellung auf Hybrid Retrieval, Einführung von Source-Citations und einer Fallback-Antwort („Dazu finde ich keine verlässliche Information"). Aufwand: oft 1 bis 3 Wochen, kein Neubau nötig.

Der brechende Workflow

Ursache meistens: fehlende Fehlerbehandlung, ungeschützte API-Calls ohne Retry, keine Alarmierung. Die Reparatur: Drei-Schichten-Fehlerbehandlung einziehen, Logging auf einen zentralen Punkt, Monitoring mit echten Alerts. Oft lassen sich bestehende Workflows rekonstruieren, nur mit den Schutzmechanismen, die von Anfang an hätten dabei sein müssen.

Der Security-Nightmare aus Vibe-Coding

Ursache meistens: exponierte API-Keys im Frontend, keine Row-Level-Security in der Datenbank, fehlende Input-Validierung, keine Auth. Hier ist der ehrliche Blick nötig: Manchmal ist ein Refactor möglich (Backend neu bauen, Frontend behalten). Manchmal ist ein Neuaufbau schneller und sicherer. Die Entscheidung hängt davon ab, wie tief die Sicherheitsprobleme strukturell im Code sitzen, und wie schnell sie geschlossen werden müssen.

Was ein belastbares „KI-Doktor"-Setup liefert

Ein sauberes Reparatur-Projekt umfasst:

• Diagnose statt Aktionismus: Was wurde gebaut, wie wurde es gebaut, wo liegen die Probleme, wie kritisch sind sie?
• Ehrliche Einschätzung: Reparieren, umbauen oder neu aufsetzen, mit realistischer Aufwandsschätzung. Kein Up-Selling, keine unnötige Komplexität.
• Umsetzung mit klarem Abschluss-Kriterium: Was muss funktionieren, damit das Projekt als erledigt gilt?
• Dokumentation der Änderungen inklusive Begründung, damit die Lösung ohne den reparierenden Dienstleister weiter wartbar bleibt.
• Keine Einbahnstraße in ein Abo: Wer danach Wartung möchte, kann eine optionale monatliche Wartungspauschale buchen, aber die meisten Kunden brauchen das nach der Reparatur nicht.

Was bleibt

Die Zahl der gescheiterten KI-Projekte ist beeindruckend, aber sie ist nicht zwingend. Wer die typischen Muster kennt, Datenqualität, Organisation, Governance, Security, Fehlerbehandlung, kann die eigenen Projekte gezielt prüfen und oft mit überschaubarem Aufwand reparieren.

Drei Grundregeln helfen:

1. Daten-Readiness vor Modell-Wahl. In fast allen Fehlschlägen ist die eigentliche Ursache hier zu finden.
2. Das, was in 3 Tagen entsteht, ist ein Prototyp. Es soll in Produktion nur, wenn jemand es davor gereviewt hat, mit Fokus auf Security, Fehlerbehandlung und Betriebsstabilität.
3. Ehrlich entscheiden, ob reparieren oder neu bauen. Rewrites sind oft langsamer als Refactoring. Aber manchmal ist der Neubau schneller, wenn die Substanz strukturell bricht.

Wer eine bestehende KI-Lösung hat, die nicht stabil läuft, findet einen Einstiegspunkt über die Landingpage zum KI-Doktor. Eine Übersicht über alle fünf Productized Services gibt es unter /loesungen. Eine vertiefende Diskussion, warum die meisten KI-Projekte eigentlich klassische Automatisierung bräuchten, findet sich unter 80 Prozent der KI-Projekte brauchen eigentlich klassische Automatisierung.