Branchenübergreifend gilt ein Muster: Die meisten KI-Initiativen erreichen ein interessantes Demo und kommen dann ins Stocken. Deloitte, MIT Sloan und weitere Institutionen berichten, dass 75–95 % der KI-Projekte den geplanten Geschäftswert nicht realisieren. Die Zahl variiert je nach Definition des Scheiterns — die Richtung ist eindeutig.
Schlimmer noch: Diese Piloten scheitern nicht an der Technologie. Sie scheitern an Entscheidungen, die getroffen wurden, bevor die erste Zeile Code geschrieben wurde. Hier sind die häufigsten Ursachen — und was man anders machen kann.
Falle Nummer eins: Pilot ohne Produktionsplan
Das verbreitetste Muster sieht so aus: Das Team wählt einen Use-Case, baut in sechs Wochen eine Demo, die Führungsebene ist begeistert, das Projekt erhält grünes Licht für die nächste Phase — und dann zeigt sich, dass niemand darüber nachgedacht hat, was „nächste Phase" eigentlich bedeutet.
Ein Pilot ist keine Produktion. Ein Pilot läuft in einer isolierten Umgebung, mit handverlesenen Daten, ohne Last, ohne Sicherheitsanforderungen, ohne Integration in bestehende Systeme. Ein Pilot ist der Beweis, dass eine Idee physikalisch möglich ist. Kein Beweis, dass sie skalierbar, wartbar und sicher ist.
Ein Produktivsystem benötigt:
- Integration in Live-Datenquellen (CRM, ERP, Sensoren, Dokumentenablagen)
- Authentifizierung, Audit-Log, rollenbasierte Zugriffssteuerung
- Monitoring und Alerting, wenn sich das Modell anders verhält
- Einen Rollback-Plan für den Fehlerfall
- Einen Plan zur Modellaktualisierung, wenn sich die Domänendaten ändern
Keiner dieser Punkte entsteht aus einem Pilot heraus. Wenn der Produktionsplan nicht Teil des Pilotauftrags ist, ist der Pilot ein Hobby, keine Investition.
Was man anders machen sollte: Schreiben Sie vor dem Pilotstart eine Seite: „Wie sieht die Produktionsarchitektur aus? Wer ist ihr Eigentümer? Was ist der Plan für die Datenanbindung? Was ist das Erfolgskriterium am Ende von Phase 2?" Wenn niemand diese Fragen beantworten kann, verschieben Sie den Pilot — das spart Zeit und Geld.
Falle Nummer zwei: keine Daten, kein Eval
Der zweithäufigste Grund für das Scheitern: Das Team baut ein System, ohne vorab zu definieren, woran es erkennen will, ob es funktioniert.
Eine RAG-Pipeline liefert eine Antwort. Ist sie richtig? Relevant? Konsistent über fünf ähnliche Fragen hinweg? Ohne ein Eval-Set — eine Sammlung realer Fragen mit erwarteten Antworten — kann das niemand beantworten. Das ist ein Problem, denn ohne Eval-Set:
- Können Sie keine Systemversionen vergleichen (ist V2 besser als V1?)
- Können Sie keine Regression nach einer Modell- oder Datenänderung erkennen
- Können Sie Stakeholdern nicht belegen, dass das System funktioniert
- Können Sie nicht identifizieren, wo genau das System versagt
Ein Eval-Set muss nicht groß sein — 50–200 repräsentative Fälle mit markierter korrekter Antwort sind ein Anfang. Wichtig ist, dass es vor der Inbetriebnahme existiert, nicht danach.
Ein paralleles Problem sind die Daten selbst. Der Cisco AI Readiness Index gibt an, dass nur etwa ein Drittel der Unternehmen ihre Datenbereitschaft als ausreichend einschätzt. In der Praxis sieht das so aus: Dokumente liegen in verschiedenen Formaten vor, sind schlecht benannt, ohne Metadaten, an vier verschiedenen Orten gespeichert. Ein RAG-System über solchen Daten liefert Ergebnisse — nur keine guten. Und das Team merkt es nicht, weil das Eval-Set nicht existiert.
Was man anders machen sollte: Kartieren Sie vor dem Pilot die Datenquellen und beantworten Sie drei Fragen: Wo liegen die Daten, in welchem Zustand sind sie und wer ist ihr Eigentümer. Stellen Sie parallel dazu ein Eval-Set aus realen Fällen zusammen. Diese beiden Aktivitäten decken 80 % der Blocker auf, bevor Sie mit dem Bauen beginnen.
Falle Nummer drei: unklarer Eigentümer
KI-Piloten im Unternehmensumfeld leiden darunter, dass sie allen und niemandem gehören. Die IT-Abteilung hat die Architektur entworfen. Das Business-Team hat den Use-Case definiert. Die Führungsebene hat zugestimmt. Aber wer trägt die Verantwortung für das Ergebnis?
Die Forschung zeigt konsistent, dass Projekte mit einem starken, eindeutigen Executive Sponsor eine dramatisch höhere Erfolgsquote aufweisen. Ohne klaren Eigentümer passiert Folgendes:
- Jedes Team hat andere Prioritäten, und der Pilot wandert ans Ende der Warteschlange
- Niemand will Trade-off-Entscheidungen treffen (Geschwindigkeit vs. Genauigkeit, Kosten vs. Abdeckung)
- Wenn das System schlechtere Ergebnisse liefert, weiß niemand, wer das Problem lösen soll
- Wenn die Produktivschaltung ansteht, wartet jeder darauf, dass ein anderer den ersten Schritt macht
Was man anders machen sollte: Benennen Sie einen Projektverantwortlichen mit dem Mandat, Entscheidungen zu treffen — nicht nur zu koordinieren. Diese Person muss Business-Kontext haben (nicht nur technisches Wissen), Zugang zu Stakeholdern und die Kapazität, dem Projekt mindestens 20–30 % ihrer Zeit zu widmen. Ohne das ist der Pilot das Hobby von Freiwilligen.
Falle Nummer vier: unterschätzte Integration
In der Pilotphase läuft das System typischerweise auf einer vorbereiteten Datenstichprobe, mit manuellem Export, in einem Jupyter-Notebook oder Streamlit-Prototyp. In der Produktion muss es:
- Daten aus Live-Systemen in Echtzeit oder in definierter Frequenz lesen
- Ausgaben in Systeme schreiben, auf die andere Personen oder Prozesse warten
- Authentifizierung und Berechtigungen aus bestehenden Identity-Systemen respektieren
- Ausfälle, Verzögerungen und inkonsistente Formate von Eingabedaten bewältigen
Jeder dieser Punkte ist ein eigenständiges Projekt. Integration macht typischerweise 40–60 % der Gesamtkosten eines Produktivsystems aus — und die meisten Piloten rechnen damit überhaupt nicht.
Wir sehen auch den anderen Extremfall: Das Team hat drei Monate für die Integration aufgewendet, das Modell ist technisch an Live-Daten angebunden, aber niemand hat geprüft, ob die Daten in der Produktion dieselbe Qualität und Struktur haben wie die Daten aus dem Pilot. Die Antwort: haben sie nicht.
Was man anders machen sollte: Nehmen Sie in den Business Case des Pilots die geschätzten Integrationskosten auf. Ungewissheit ist in Ordnung — schreiben Sie eine Bandbreite. „Integration in SAP und SharePoint: geschätzter Aufwand 40–120 Ingenieurtage." Wenn diese Zahl die Führungsebene überrascht, ist es besser, das jetzt zu wissen als nach sechs Monaten Arbeit.
Falle Nummer fünf: unrealistische Erwartungen
Eine KI-Demo ist immer besser als die Produktion. Die Demo enthält sorgfältig ausgewählte Beispiele, bei denen das Modell am besten funktioniert. Die Produktion bekommt alles — auch Randfälle, schlecht formatierte Eingaben, Fragen außerhalb der trainierten Domäne.
Wenn ein Stakeholder die Demo gesehen hat und glaubt, dass das Produktivsystem ähnlich — oder besser, wenn es „mehr Daten" hat — funktionieren wird, entsteht ein Problem. In dem Moment, in dem das Produktivsystem eine schlechte Antwort liefert (und das wird es), entsteht ein Missverhältnis zwischen dem, was versprochen wurde, und dem, was das System tatsächlich leistet.
Ein verwandtes Problem ist die Erwartung eines sofortigen ROI. Umfragen zeigen, dass die meisten CEOs realistisch damit rechnen, dass eine positive Rendite länger als sechs Monate dauert. Bei komplexeren Use-Cases ist ein realistischer Horizont 12–24 Monate. Wenn ein Projekt unter Druck gerät, „bis zum Quartalsende sichtbare Ergebnisse" zu liefern, endet es entweder mit unrealistischen Metrik-Behauptungen oder mit vorzeitigem Abbruch.
Was man anders machen sollte: Setzen Sie vor dem Pilot explizit Erwartungen: „Die Demo zeigt das Potenzial. Das Produktivsystem wird eine Fehlerquote von X % haben. Einen ersten messbaren Wert sehen wir in Monat Y. Den vollständigen Return on Investment erwarten wir im Horizont Z." Wenn die Führungsebene mit diesen Zahlen nicht einverstanden ist, ist es besser, das jetzt zu wissen.
Falle Nummer sechs: die „Demo funktioniert"-Falle
Dies ist das am meisten unterschätzte Problem und verdient ein eigenes Kapitel.
Die Demo funktioniert. Das Modell beantwortet Fragen. Das Retrieval liefert relevante Dokumente. Der Prototyp ist auf Testservern bereitgestellt. Das Team feiert. Und dann... verlangsamt sich das Projekt. Nicht weil etwas nicht funktioniert — sondern weil niemand weiß, was als Nächstes kommen soll.
Ursachen:
- Die metrische Ziellinie fehlt: Der Pilot hatte keine Definition, was „erfolgreicher Pilot" bedeutet. Er endete als wissenschaftliches Experiment ohne Schlussfolgerungen.
- Produktionsreife ist nicht binär: Der Übergang vom Prototyp in die Produktion ist kein Deployment — es sind mehrere Monate Arbeit an Sicherheit, Stabilität, Monitoring, Dokumentation und Schulung.
- Prozessveränderung ist schwieriger als Technologiewechsel: Ein neues KI-Werkzeug erfordert, dass Menschen ihre Arbeitsweise ändern. Change Management wird typischerweise unterschätzt oder fehlt vollständig.
- Ein erfolgreiches Projekt erzeugt neue Komplexität: Wenn der Pilot funktioniert, möchte das Business mehr (mehr Use-Cases, mehr Nutzer, mehr Sprachen). Ohne skalierbare Architektur ist das keine Expansion — es ist technische Schuld.
Was man anders machen sollte: Definieren Sie Exit-Kriterien des Pilots im Voraus. „Der Pilot ist erfolgreich, wenn: (1) das Eval-Set eine Genauigkeit von ≥ X % erreicht, (2) die Latenz unter Y Sekunden liegt, (3) das Team die Produktionsarchitektur identifiziert und deren Kosten geschätzt hat." Ohne Exit-Kriterien wird der Pilot nie enden — er wird endlos „noch ein bisschen verbessert".
Was Teams richtig machen, denen es gelingt
Aus Projekten, bei denen der Übergang vom Pilot in die Produktion reibungslos verlief, gelten einige gemeinsame Muster:
- Sie begannen mit einem kleinen, klar abgegrenzten Use-Case. Nicht „KI für das gesamte Kundenzentrum" — sondern „KI beantwortet die erste Ebene von Anfragen zum Bestellstatus". Klarer Scope, messbares Ergebnis.
- Business-Metriken wurden vor dem Start definiert. Nicht „wir verbessern die Effizienz" — sondern „wir reduzieren die Zeit der Erstantwort von 4 Stunden auf 45 Minuten für Kategorie-X-Anfragen".
- Das Daten-Team war von Anfang an eingebunden, nicht erst in der Integrationsphase. Sie vermieden die Situation, in der Modell-Ingenieure sechs Wochen auf Datenzugang warten.
- Der Pilot hatte eine Produktionsarchitektur auf Papier noch vor dem ersten Code-Commit. Sie musste nicht final sein — aber sie existierte.
- Change Management war von Tag eins Teil des Projekts. Wer wird das System nutzen? Was ändert sich in ihrer täglichen Routine? Wer schult sie? Wer ist die Eskalationsstelle bei Problemen?
Projekte, bei denen all das vorhanden war, erzielen messbaren Wert — in den meisten Fällen innerhalb von sechs Monaten nach dem Produktionsstart. Projekte, bei denen es fehlte, drehen sich im Kreis der Piloten.
Wann ein Pilot sinnvoll ist — und wann nicht
Ein Pilot ist ein legitimes Werkzeug zur Reduktion von Unsicherheit. Wenn Sie nicht wissen, ob RAG über Ihren Dokumenten ausreichende Genauigkeit erreicht, ist ein Pilot die richtige Antwort. Wenn Sie nicht wissen, ob das Modell Ihre spezifische Terminologie bewältigt, klärt das ein Pilot schneller und günstiger als ein Vollausbau.
Ein Pilot ergibt keinen Sinn, wenn:
- Der Use-Case ausreichend erforscht ist (industrielle Dokumentation, Kundensupport, internes Q&A) — in diesem Fall gibt es genug Referenzimplementierungen, und ein Pilot verzögert nur die Entscheidung
- Das Team nicht die Kapazität hat, das Projekt bis in die Produktion zu führen — der Pilot landet in der Schublade
- Die Führungsebene nicht akzeptiert, dass die Produktion wesentlich mehr kostet als der Pilot — das ist besser vorab zu kommunizieren
Auf der anderen Seite sind Piloten beim Einstieg in KI im Unternehmen ein natürlicher Teil des Lernprozesses — vorausgesetzt, jeder Pilot hat ein klar definiertes Ziel und die daraus gezogenen Erkenntnisse werden systematisch in die nächste Iteration übertragen.
Wie man misst, ob ein Pilot die Investition wert ist
Beantworten Sie vor dem Pilotstart sechs Fragen:
- 1.Was genau misst den Erfolg? (konkrete Metrik, nicht „Verbesserung")
- 2.Wer ist der Eigentümer und hat das Mandat zu entscheiden?
- 3.Was sind die geschätzten Kosten der Produktionsphase? (zumindest eine Bandbreite)
- 4.Welche Daten stehen zur Verfügung und in welchem Zustand sind sie?
- 5.Wie wird das System in bestehende Tools und Prozesse integriert?
- 6.Was passiert, wenn der Pilot gut ausgeht — wer und wann entscheidet über die Produktion?
Wenn Sie eine dieser Fragen nicht beantworten können, starten Sie den Pilot nicht — investieren Sie die Zeit in die Vorbereitung. Paradoxerweise dauern gut vorbereitete Projekte weniger, nicht mehr.
Für einen tieferen Blick darauf, wie man den tatsächlichen Geschäftswert von KI-Initiativen messen kann, lesen Sie den Artikel zum ROI von KI-Projekten — einschließlich eines Rahmens für die laufende Nachverfolgung und das Reporting an Stakeholder.
Häufige Fragen
Wie lange dauert der Weg vom Pilot in die Produktion durchschnittlich?
In der Praxis reicht die Spanne von drei Monaten bei einfachen Use-Cases (internes Q&A über Dokumente) bis zu 12–18 Monaten bei Systemen mit tiefer ERP-Integration, regulatorischen Anforderungen oder dem Bedarf nach Fine-tuning. Der entscheidende Faktor ist nicht die technische Komplexität, sondern die organisatorische Bereitschaft — datenseitig, prozessseitig und personell.
Was kostet ein produktives KI-System im Vergleich zu einem Pilot?
Ein Pilot kostet typischerweise 5–20 % der Gesamtprojektkosten. Der Rest fließt in Integration, Sicherheit, Monitoring, Change Management und Wartung. Teams, die dieses Verhältnis unterschätzen, geraten in die Situation, dass der Business Case des Pilots gut aussieht, der Produktions-Business-Case aber niemand genehmigt — weil die Zahlen andere sind.
Was tun, wenn der Pilot gut war, Stakeholder aber nicht in die Produktion investieren wollen?
Das ist ein Signal, dass der Business Case vorab nicht ausreichend kommuniziert wurde. Der Pilot hatte nicht klar definiert, was nach dem Erfolg folgt. Lösung: Zu den konkreten Metriken zurückkehren, den Zusammenhang zwischen Pilotergebnis und Geschäftswert zeigen und den Produktionsplan mit einer Kostenbandbreite präsentieren. Wenn auch dann kein Konsens entsteht, ist der Use-Case wahrscheinlich keine ausreichende Priorität — und das ist eine wertvolle Information.
Wie wählt man den richtigen Use-Case für den ersten Pilot?
Der ideale erste Use-Case erfüllt vier Kriterien: (1) er ist klar abgegrenzt — eindeutige Ein- und Ausgaben, (2) es gibt eine verfügbare Datenbasis, (3) er ist messbar — man kann sagen, ob es funktioniert oder nicht, (4) er hat einen internen Fürsprecher — jemanden, der es wirklich will und das Ergebnis nutzen wird. Einen umfassenderen Rahmen zur Use-Case-Auswahl finden Sie im Artikel Wie man mit KI im Unternehmen startet.
Ist eine Fehlerquote eines KI-Systems in der Produktion akzeptabel?
Das hängt vom Use-Case ab. Für internes Q&A oder einen Assistenten bei der Dokumentenvorbereitung ist eine Fehlerquote von 5–10 % in der Regel akzeptabel, wenn das System gleichzeitig Zeit spart. Für Systeme, bei denen ein Fehler finanzielle oder sicherheitsrelevante Folgen hat, müssen Sie ein Human-in-the-Loop-Gate einrichten, und die Ziel-Fehlerquote muss vor der Inbetriebnahme besprochen werden. Es gibt keine universelle Norm — aber es gibt die Pflicht, sie vor der Produktion zu definieren.
*Wenn Sie vor der Entscheidung stehen, ob Ihr KI-Pilot es wert ist, bis in die Produktion geführt zu werden, oder wenn Sie einen Partner für die Beurteilung der architektonischen Bereitschaft und eines realistischen Business-Plans suchen, führt MP Industrial Solutions solche Beurteilungen im Rahmen einer Erstberatung durch — unverbindlich, mit konkreten Schlussfolgerungen.*