Warum scheitern KI-Projekte? Vom Pilot in die Produktion

Warum scheitern KI-Projekte? Selten am Sprachmodell. Meist wird der Pilot nie entscheidbar: Es fehlen eine Kennzahl für den Nutzen, eine verantwortliche Person, der Zugang zu echten Daten oder die Einbindung in den Arbeitsablauf. Ein Pilot kommt in die Produktion, wenn vor dem Start feststeht, welcher Wert erreicht sein muss, wer darüber entscheidet und wer die Lösung danach betreibt. Wer diese drei Punkte klärt, macht aus einer Demo ein Produkt.

Dieser Artikel ordnet eine viel zitierte Studie zum Thema ein, beschreibt sieben Ursachen, an denen KI-Piloten in der Praxis hängen bleiben, und zeigt einen Weg vom Pilot in den Betrieb. Grundlage sind zwei KI-Lösungen, die unser Gründer in verantwortlicher Rolle bei einem Premium-Automobilhersteller vom Prototyp in die Produktion gebracht hat, außerhalb von Amperbytes AI und nicht in deren Auftrag.

Was die MIT-Studie sagt und was nicht

Im August 2025 berichtete Fortune über einen Bericht des MIT-Projekts NANDA mit dem Titel „The GenAI Divide: State of AI in Business 2025“. Die Schlagzeile „95 Prozent der generativen KI-Piloten scheitern“ wird seitdem oft zitiert. Genauer steht dort: Etwa 5 Prozent der KI-Piloten erreichen eine schnelle Umsatzsteigerung, die große Mehrheit bleibt ohne messbaren Effekt auf das Geschäftsergebnis. Grundlage sind laut Fortune 150 Interviews mit Führungskräften, eine Befragung von 350 Beschäftigten und die Auswertung von 300 öffentlich bekannten KI-Einführungen.

Drei Punkte aus dem Bericht sind für die Praxis wichtiger als die Schlagzeile:

• Das Modell ist nicht das Problem. Als Kernursache nennt der Bericht eine Lernlücke bei Werkzeugen und Organisationen, nicht die Qualität der Modelle.
• Integration entscheidet. Allgemeine Werkzeuge helfen Einzelnen, bleiben im Unternehmen aber stecken, weil sie sich nicht an Arbeitsabläufe anpassen.
• Kaufen gelingt häufiger als Eigenbau. Lösungen von spezialisierten Anbietern und Partnerschaften gelingen laut Bericht in etwa 67 Prozent der Fälle, reine interne Eigenbauten nur etwa ein Drittel so oft.

„Scheitern“ heißt in dieser Studie also: kein schneller, messbarer Umsatzeffekt. Ob diese Piloten technisch funktionieren, misst die Studie nicht. Gemessen wird der Geschäftseffekt, und genau dieser Nachweis fehlt meist. Hier setzen die folgenden Ursachen an. Wann Kaufen und wann eine eigene Lösung passt, behandeln wir ausführlich im Artikel LLM Build vs. Buy für den Mittelstand.

Sieben Gründe, warum KI-Piloten stecken bleiben

1. Keine Kennzahl und kein Ist-Wert

Ein Pilot ohne vorher vereinbarte Kennzahl (KPI, Key Performance Indicator) kann nicht bestehen und nicht durchfallen. Am Ende steht ein Eindruck, und Eindrücke reichen nicht für ein Budget. Genauso wichtig ist der Ist-Wert: Wie lange dauert die Recherche heute, wie oft landet eine Frage beim Experten, wie hoch ist die Fehlerquote? Ohne diese Zahl lässt sich keine Verbesserung belegen.

2. Kein Verantwortlicher für Entscheidung und Betrieb

Piloten entstehen oft in einer Innovationseinheit oder als Nebenprojekt. Niemand im Fachbereich ist verantwortlich, und die IT sieht die Lösung erst, wenn sie betrieben werden soll. Es braucht eine Person, die über Ausrollen oder Stoppen entscheidet, und eine, die den Betrieb danach trägt. Oft ist das dieselbe Rolle: ein Product Owner, also die Person, die Ziele, Prioritäten und Abnahme eines Produkts verantwortet.

3. Kein Zugriff auf die echten Daten

Der Prototyp lief mit einem Export oder einer Handvoll Beispieldokumenten. Für den Pilot fehlt dann der Zugang zu den Quellsystemen, die Berechtigungen sind ungeklärt, oder die Datenschutzprüfung beginnt erst jetzt. Diese Fragen gehören an den Anfang, weil sie die Architektur bestimmen. Worauf es bei der Datenschutzprüfung ankommt, beschreiben wir unter DSGVO-konforme LLM-Integration.

4. Keine Integration in den Arbeitsablauf

Eine KI-Lösung in einem eigenen Browserfenster wird in der ersten Woche ausprobiert und dann vergessen. Genutzt wird sie, wenn sie dort erscheint, wo die Arbeit passiert: im Fachsystem, im Ticket, in der Maske, in der die Entscheidung fällt. Diese Integration ist meist mehr Aufwand als das Modell selbst und wird im Pilot gern aufgeschoben.

5. Kosten pro Antwort unbekannt

Im Pilot mit 20 Nutzern fallen Modellkosten kaum auf. Bei 2.000 Nutzern sieht das anders aus. Wer die Kosten pro Antwort (Modellaufrufe, Suche, Infrastruktur) nicht misst, kann Nutzen und Kosten nicht vergleichen. Spätestens beim Rollout fragt dann das Controlling nach.

6. Kein Test-Set für die Qualität

Ein Test-Set, auch Evaluationsset genannt, ist eine Liste echter Fragen oder Fälle mit abgenommenen Sollergebnissen. Ohne diese Liste diskutiert das Team über Einzelbeispiele, und jede Änderung an Prompt oder Modell kann unbemerkt andere Fälle verschlechtern. Wie ein solches Set für einen Assistenten mit Retrieval aufgebaut wird, zeigt unser Artikel Antwortqualität eines RAG-Assistenten messen.

7. Veränderung wird nicht begleitet

Nutzer müssen wissen, wofür die Lösung gedacht ist, wo ihre Grenzen liegen und was mit ihrem Feedback passiert. Fehlt diese Begleitung, bleibt die Nutzung bei den Neugierigen hängen. Skepsis ist dabei kein Hindernis, sondern eine Quelle: Wer Fehler meldet, liefert die Fälle für das Test-Set.

Aus der Praxis: zwei Lösungen vom Prototyp in die Produktion

Unser Gründer hat als Product Owner und Solution Architect eines microservice-basierten Diagnose-Service bei einem Premium-Automobilhersteller zwei KI-Lösungen vom Prototyp in die Produktion gebracht. Die Plattform, an der unser Gründer vor bzw. außerhalb von Amperbytes AI gearbeitet hat, nutzen über 15.000 Menschen pro Monat in Werken, Remote-Software-Update-Services und Aftersales. Beide Projekte wurden nicht im Auftrag von Amperbytes AI umgesetzt.

Ein LLM-Assistent mit Retrieval (RAG) über Diagnoseinhalte. RAG steht für Retrieval-Augmented Generation: Der Assistent sucht zuerst die passenden Inhalte und lässt das Sprachmodell auf dieser Basis antworten. Vor der Festlegung auf einen KI-Service wurden die Kandidaten nach Antwortqualität, Kosten, Latenz und Datenschutz bewertet. Die Qualität im Betrieb wurde mit definierten KPIs gemessen und in Grafana und Kibana sichtbar gemacht. Ausgerollt wurde schrittweise an die Bestandsnutzer. Details im Praxisbeispiel KI-Assistent mit Retrieval für die Fahrzeugdiagnose.

Ein ML-Empfehlungssystem für den Diagnoseprozess. Ein Prototyp mit Machine Learning hatte gezeigt, dass sich brauchbare Vorschläge für den nächsten Diagnoseschritt ableiten lassen, lief aber isoliert. Der Weg in die Produktion begann nicht mit Code, sondern mit einer gemeinsamen Definition mit dem Fachbereich, wann eine Empfehlung hilfreich ist. Daraus wurden KPIs, eine Datenpipeline und ein stufenweiser Rollout mit Messung nach jeder Stufe. Mehr dazu im Praxisbeispiel ML-Empfehlungssystem vom Prototyp in die Produktion.

Die gemeinsame Lehre aus beiden Projekten: Der entscheidende Schritt war kein technischer. Er bestand darin, dass Fachbereich und Entwicklung auf dieselben Kennzahlen schauen und Änderungen danach entscheiden, statt über Einzelfälle zu streiten.

Einen Pilot so zuschneiden, dass er entscheidbar ist

Ein guter Pilot beantwortet eine Frage: Rollen wir aus oder nicht? Dafür braucht er echte Daten, echte Nutzer, eine feste Laufzeit und vorher vereinbarte Kriterien.

• Ein Prozess, eine Nutzergruppe. Lieber 20 Nutzer mit einem klaren Engpass als 200 Nutzer mit „probiert es mal aus“.
• Echte Daten statt Beispieldaten. Nur so zeigt sich, ob Berechtigungen, Datenqualität und Aktualität tragen.
• Feste Laufzeit mit Entscheidungstermin. Der Termin steht im Kalender der Person, die entscheidet.
• Abbruchkriterien vorab. Schriftlich festgehalten, bevor das erste Ergebnis vorliegt.

Ein No-Go ist kein Misserfolg, wenn es früh und begründet fällt. Teuer wird der Pilot, der ohne Entscheidung weiterläuft.

Vom Pilot in den Betrieb: fünf Schritte

1. Qualität dauerhaft messen. Das Test-Set läuft bei jeder Änderung an Prompt, Modell oder Daten mit. Im Betrieb kommen Dashboards, Alarme und Nutzerfeedback hinzu.
2. Integration fertigstellen. Die Lösung erscheint im Fachsystem, übernimmt die Berechtigungen der Quellsysteme und protokolliert, was sie tut.
3. Stufenweise ausrollen. Nutzergruppe für Nutzergruppe, mit Prüfung der Kennzahlen nach jeder Stufe, bevor die nächste freigegeben wird.
4. Modellwechsel einplanen. Sprachmodelle werden abgekündigt und ersetzt. Eine gekapselte Anbindung an die Modell-Schnittstelle und das Test-Set machen einen Wechsel zu einer geprüften Änderung statt zu einem Risiko.
5. Feedback-Schleife verankern. Negative Bewertungen und gemeldete Fehler landen im Backlog und als neue Fälle im Test-Set. Ein fester Termin, etwa monatlich, bespricht die Kennzahlen mit dem Fachbereich.

Rollen: Wer was verantwortet

Die Rollen müssen nicht mit neuen Stellen besetzt werden. Sie müssen benannt sein. Wenn die Auswahl des passenden Anwendungsfalls selbst noch offen ist, hilft ein strukturierter Einstieg über eine KI-Beratung mit Potenzialanalyse.

Checkliste: Ist Ihr Pilot bereit für die Produktion?

• Die Ziel-KPI und der Ist-Wert sind schriftlich festgehalten.
• Eine Person entscheidet über Ausrollen oder Stoppen und hat einen Termin dafür.
• Die Lösung arbeitet mit echten Daten und den Berechtigungen der Quellsysteme.
• Ein Test-Set mit abgenommenen Sollergebnissen liegt vor und läuft bei jeder Änderung.
• Die Kosten pro Antwort sind gemessen und auf die geplante Nutzerzahl hochgerechnet.
• Die Lösung ist dort eingebunden, wo die Arbeit passiert.
• Monitoring, Feedback-Weg und Verantwortlicher für den Betrieb stehen vor dem Rollout.
• Die Nutzer wissen, wofür die Lösung gedacht ist und wo ihre Grenzen liegen.

Fehlt einer der ersten vier Punkte, ist der Pilot nicht entscheidbar. Klären Sie diese Punkte, bevor Sie ihn verlängern.

Fazit

KI-Projekte scheitern meist nicht an der Technik, sondern daran, dass niemand festgelegt hat, woran Erfolg gemessen wird und wer entscheidet. Das passt zum MIT-Bericht: Als Kernursache nennt er eine Lernlücke bei Werkzeugen und Organisationen und die fehlende Anpassung an Arbeitsabläufe, nicht die Qualität der Modelle. Ein Pilot mit Ziel-KPI, Test-Set, gemessenen Kosten pro Antwort und benanntem Verantwortlichen lässt sich entscheiden und sauber in den Betrieb überführen. Das gilt für einen RAG-Assistenten genauso wie für ein ML-Empfehlungssystem.

Steckt Ihr KI-Pilot fest, oder wollen Sie einen neuen so aufsetzen, dass er in die Produktion kommt? Wir unterstützen Sie mit KI-Entwicklung aus der Region München, von Test-Set und Integration bis zum Monitoring. Schildern Sie uns Ihren Stand über das Kontaktformular.