Warum KI-Projekte scheitern

Erweiterte Web-Fassung des im Red Stack Magazin 03/2025 erschienenen Artikels, basierend auf dem Vortrag bei der KI-Navigator-Konferenz 2024.

KI-Projekte scheitern selten an der Technik. Sie scheitern an Menschen und Organisationen — an widersprüchlichen Erwartungen, fehlender Strategie und technologischem Wildwuchs ohne Governance. Dieser Beitrag zeigt die Muster, die in regulierten Branchen am häufigsten zu Stillstand führen, und die Stellschrauben, an denen erfolgreiche Programme drehen.

Auf einen Blick

• KI-Projekte scheitern an unrealistischen Erwartungen, Strategielücken und einer Führungsebene, die mit der technischen Tiefe selten in Berührung kommt.
• Technologie-Wildwuchs und Vendor-Lock-In sind vorhersehbare Fallen, nicht unglückliche Zufälle.
• Ein stabiles Fundament aus Datenstrategie, organisatorischer Reife und offenen Standards ist entscheidend.
• Open Source first ist in regulierten Konzernen die strategisch tragfähigere Wahl — wegen Auditierbarkeit, Souveränität und Total Cost of Ownership.

Die drei Akte des KI-Scheiterns

Akt 1: Die Diagnose

Wer KI-Projekte über Jahre begleitet, sieht dasselbe Bild: Im Maschinenraum funktioniert die Technik. Auf der Brücke geht der Kompass verloren. Die Ursachen liegen fast nie in den Modellen, sondern in den Akteuren, die mit unterschiedlichen Erwartungen und Agenden im selben Projekt aufeinandertreffen.

Medien und Tech-Evangelisten verkünden täglich neue Durchbrüche; selbst guten Journalisten fehlt dabei oft die technische Tiefe, weil Sensation den Klick belohnt und Differenzierung nicht. Das Ergebnis ist ein Hype-Geräusch, das Vorständen das Gefühl gibt, sie müssten dringend etwas tun, ohne dass klar wäre, was.

Die Führungsebene reagiert auf diesen Druck mit der Angst, den Anschluss zu verlieren — und erwartet schnelle Erfolge, die in der Realität nicht möglich sind. Strukturell verschärft sich das in Deutschland: In software-nativen Unternehmen prägt der Engineering-Hintergrund der Gründer auch die heutige Führungsebene. In etablierten deutschen Konzernen führen die typischen Karrierepfade — Vertrieb, Finanzen, Recht — IT-Erfahrung dagegen selten bis in den Vorstand. Das ist kein individueller Vorwurf, sondern eine Strukturfrage. Die Folge ist eine Unsicherheit im Umgang mit der technischen Tiefe — und damit Empfänglichkeit für Tools, die glänzen, aber nicht tragen.

Die KI-Beratung schließlich kennt die neuesten Technologien — und muss sie verkaufen. Sie sieht die Diskrepanz zwischen Realität und Kundenwunsch und steht zugleich unter enormem technischem Druck: Allein das Feld der Sprachmodelle wurde in den letzten zwölf Jahren dreimal komplett umgekrempelt — von Word2Vec und GloVe über die Transformer-Architektur und BERT bis zu den heutigen großen Sprachmodellen wie GPT-4 und Llama. Wer diese Wellen nicht selbst gerudert hat, verkauft entweder überholte Architekturen oder die nächste Vendor-Versprechung.

Akt 2: Die Muster

In der Beratungspraxis tauchen drei Muster immer wieder auf — unabhängig von Branche und Unternehmensgröße.

Das erste Muster ist das Prototyp-Dilemma: sechs Monate Entwicklung, drei Jahre Diskussion. Der Prototyp funktioniert im Labor. Niemand hat an die Produktivumgebung gedacht, die Datenqualität im Echtbetrieb sieht völlig anders aus, organisatorische Prozesse passen nicht zur Technologie, und Change Management war von Anfang an nicht Teil des Projekts. Was bleibt, ist ein Demo-Video und eine Roadmap, die niemand mehr glaubt.

Das zweite Muster ist die Insellösung: Marketing baut auf Tool A für Content-Generierung, IT entwickelt Tool B für Datenanalyse, HR testet Tool C für Recruiting. Jede Abteilung hat ihren eigenen Vendor, ihre eigene Datendefinition, ihren eigenen Vertrag. Was entsteht, ist Technologie-Wildwuchs ohne gemeinsame Infrastruktur — fragmentierte Datenflüsse, keine Skalierbarkeit und eine Compliance-Landschaft, die niemand mehr überblickt. In regulierten Branchen ist dieses Muster besonders teuer, weil jede Insel eigene Audit-Pfade erzeugt.

Das dritte Muster ist der Vendor-Lock-In. Viele Unternehmen setzen auf proprietäre Cloud-Services, ohne die unbequemen Fragen zu stellen: Was passiert bei der nächsten Preiserhöhung? Wie kommen wir wieder raus, wenn das Modell sich verschlechtert oder die Konditionen sich ändern? Wo liegen am Ende unsere Daten — und was geht im Worst Case verloren?

Akt 3: Die Erfolgsfaktoren

Erfolgreiche KI-Implementierungen sehen sich überraschend ähnlich. Drei Achsen ziehen sich durch fast jede gelungene Transformation, die ich begleitet habe.

Auf der Achse Menschen entscheidet die Reihenfolge. Stakeholder werden früh eingebunden, vom Tech-Team bis ins C-Level. Erwartungen werden realistisch gesetzt — was kann KI heute, was nicht. Change Management ist integraler Bestandteil des Programms, nicht ein Nachgedanke, der drei Wochen vor Go-Live aktiviert wird.

Auf der technischen Achse trägt eine Open-Source-first-Architektur. Sie schafft Flexibilität und Kontrolle, sie erlaubt es, neue Modelle modular zu integrieren, und sie liefert Auditierbarkeit, die in regulierten Umgebungen nicht verhandelbar ist. Die ausführliche Argumentation, warum offene Modelle in Enterprise-Kontexten ökonomisch und regulatorisch die erwachsenere Wahl sind, trägt der Beitrag Stop Waiting, Start Shipping. Dazu kommt Qualitätssicherung von Anfang an: Evaluation und Monitoring werden mit dem ersten Modell aufgesetzt, nicht nach dem ersten Incident.

Auf der organisatorischen Achse kommt die Datenstrategie vor dem Tool-Shopping: Was haben wir, was brauchen wir, in welcher Qualität. Governance ist klar — wer entscheidet was, wann und wie. Und die Herangehensweise ist iterativ: kleine Schritte, schnelle Learnings, ehrliche Korrekturen.

Was erfolgreiche KI-Transformationen auszeichnet

Nach über zehn Jahren in der Data-Science-Community und hunderten Projektkontakten sehe ich einen Faktor, der sich nicht aus Methodologie-Büchern ableitet: Die erfolgreichsten KI-Implementierungen entstehen dort, wo Wissen über Domänengrenzen hinweg fließt.

In der Python-Community erlebe ich seit 2014, wie Menschen aus völlig unterschiedlichen Bereichen gemeinsam an Problemen arbeiten — von der Europäischen Weltraumorganisation bis zu FinTech-Startups, von der Klimaforschung bis zur industriellen Bildverarbeitung. Auf einer PyData-Konferenz übernimmt eine Engineerin aus dem Banking-Umfeld eine Pipeline-Idee aus der Astronomie, weil dieselbe Klasse von Zeitreihen-Problemen dort schon zehn Jahre länger gelöst wird. Diese Quervernetzung führt zu besseren Lösungen, weil viele scheinbar neue Probleme in anderen Feldern längst durchgearbeitet sind. Genau das ist die Aufgabe einer Beratung, die nicht nur die letzte Tool-Generation kennt, sondern weiß, welche Muster sich übertragen lassen.

Konkrete Handlungsempfehlungen

1. Bevor Sie in Tools investieren: Analysieren Sie, was Ihre Leute wirklich brauchen — und was die regulatorische Landschaft erlaubt. 2. Entwickeln Sie eine Datenstrategie, bevor Sie KI-Modelle trainieren. 3. Setzen Sie auf offene Standards — sie sichern Optionalität, Auditierbarkeit und Verhandlungsposition. In regulierten Umgebungen ist Open Source die strategisch erwachsenere Wahl, nicht die Sparvariante. 4. Bauen Sie interne Expertise auf: Externe Beratung kann den Weg zeigen, gehen müssen Sie ihn selbst. 5. Fangen Sie klein an: Ein funktionierender Pilot ist mehr wert als zehn gescheiterte Visionen.

Fazit

KI-Projekte scheitern nicht an der Technologie, sondern an Strategielücken, organisatorischem Wildwuchs und fehlender Governance. Wer ein stabiles Fundament aus klarer Priorisierung, datenzentrierter Planung und Open-Source-first-Architektur schafft, schafft die Voraussetzung für nachhaltige Erfolge.

Die Technologie ist da. Die Frage ist: Sind Sie organisatorisch und strategisch bereit dafür?

Ausgewählte Slides

Aus Akt 1 — die Akteurs-Diagnose. Aus Akt 2 — wiederkehrende Muster aus der Beratungspraxis. Aus Akt 2 — wiederkehrende Muster aus der Beratungspraxis. Aus Akt 3 — die drei Achsen erfolgreicher Implementierungen.