Die meisten KI-Pilotprojekte scheitern nicht, sondern bleiben stecken. Sie funktionieren, beeindrucken in der Demo, ernten Lob und gehen dann nie in Produktion. Sie verharren in einem Schwebezustand, in dem sie weder formell abgebrochen werden – ein Abbruch käme einem Eingeständnis eines Fehlers gleich – noch werden sie eingeführt – eine Einführung würde die Lösung von Problemen erfordern, die das Pilotprojekt bewusst vermieden hat.
Dieser Schwebezustand hat seinen Preis, der in keinem Bericht auftaucht: verbrauchtes Budget, verlorene interne Glaubwürdigkeit und vor allem die irrige Schlussfolgerung, dass «KI in unserer Branche nicht funktioniert».
Die Zahlen variieren stark je nachdem, wer misst und wie, daher ist es am besten, mehrere Quellen heranzuziehen, anstatt sich auf eine Schlagzeile zu verlassen.
Er IBMs CEO-Studie 2025, Die Studie, für die 2.000 CEOs aus 33 Ländern befragt wurden, ergab, dass nur 251 % der KI-Initiativen den erwarteten Erfolg brachten und lediglich 161 % auf Unternehmensebene skaliert wurden. Sie ist die methodisch solideste der drei Quellen.
S&P Global Market Intelligence Im März 2025 wurde veröffentlicht, dass 421.030 Unternehmen den Großteil ihrer KI-Initiativen aufgegeben hatten, im Vergleich zu 171.030 im Vorjahr, und dass durchschnittlich 461.030 Proof-of-Concept-Projekte verworfen wurden, bevor sie die Produktion erreichten.
Und dann ist da noch die Information, die am weitesten verbreitet wurde: der Bericht. MIT-Projekt NANDA Laut dem Bericht von 2025 erzielten rund 95,1 % der Organisationen keinen messbaren Nutzen aus generativer KI. Wichtig ist hierbei, ehrlich zu sein: Es handelt sich um einen vorläufigen, noch nicht von Fachkollegen begutachteten Bericht, der auf 52 Interviews und 153 Umfragen basiert und hinsichtlich des Messzeitraums und der Stichprobengröße erhebliche methodische Kritik erfahren hat. Die allgemeine Tendenz deckt sich mit anderen Quellen; das genaue Ausmaß bleibt jedoch unbestimmt.
Entscheidend ist nicht, welche der drei Zahlen stimmt. Entscheidend ist, dass alle drei auf denselben Wendepunkt hinweisen: Er liegt nicht in der Entwicklung des Pilotfilms, sondern im Übergang von der Pilotphase zur Serienproduktion.
Ursache | Was hat der Pilot vermieden? | Was wird für die Produktion benötigt? |
Daten | Ein sauberes und ausgewähltes Set | Reale, unvollständige und widersprüchliche Daten |
Genehmigungen | Ein Benutzer mit vollem Zugriff | Unterschiedliche Rollen, eingeschränkte Sichtbarkeit, Rückverfolgbarkeit |
Ausnahmen | Der glückliche Weg | Die 15-30% seltener Fälle, die nicht für die Planung vorgesehen waren |
Integration | Kopieren und Einfügen zwischen Bildschirmen | ERP-, CRM- und Identitätsintegration |
Eigentum | Ein Innovationsteam | Ein Geschäftsführer und ein Support-Team |
Kosten | Testvolumen | Stückkosten im realen Maßstab, mit Spitzenwerten |
Die Daten. Die Pilotphase läuft mit einem vorbereiteten Datenauszug. Im Produktivbetrieb treffen die Daten unvollständig, doppelt vorhanden und inkonsistent zwischen den Systemen ein. Das Modell versagt nicht sichtbar: Es wählt ohne Vorwarnung eine der widersprüchlichen Versionen aus.
Die Genehmigungen. Während der Testphase hat das System uneingeschränkten Zugriff. Im Produktivbetrieb hingegen kann ein Vertriebsmitarbeiter keine Margen einsehen, ein Techniker keine Gesundheitsdaten und ein externer Berater nur die ihm zugewiesenen Daten. Wenn das Berechtigungsmodell nicht von Anfang an vorgesehen war, handelt es sich nicht um eine Anpassung, sondern um eine grundlegende Überarbeitung.
Die Ausnahmen. Das Pilotprojekt demonstriert den erfolgreichen Weg, denn genau das lässt sich in zwanzig Minuten beweisen. Der eigentliche Betrieb besteht größtenteils darin, mit den nicht durchführbaren Aufgaben umzugehen. Dieser Anteil – zwischen 151 TP3T und 301 TP3T des Volumens in den meisten der von uns analysierten Prozesse – ist der Punkt, an dem die Automatisierung versagt und Entscheidungen darüber getroffen werden müssen, welche Aufgaben manuell skaliert werden und wie.
Integration. Eine Demoversion ermöglicht es dem Benutzer möglicherweise, Informationen zwischen Fenstern zu kopieren. Ein Produktivsystem hingegen muss den Betriebskontext erfassen und Aktionen innerhalb bestehender Systeme ausführen, dabei Berechtigungen beachten und ein Protokoll erstellen.
Das Anwesen. Piloten sind meist in die Welt der Innovation oder Technologie hineingeboren. Die Produktion hingegen erfordert einen Unternehmer: jemanden, dessen Jahresziel von einem reibungslosen Ablauf der Prozesse abhängt. Ohne diesen Unternehmer gibt es niemanden, der sich für das Budget der nächsten Phase einsetzt oder über Ausnahmen entscheidet.
Die Stückkosten. In der Pilotphase sind die Kosten aufgrund des geringen Volumens irrelevant. Im Vollausbau mit Spitzenlast und Wiederholungsversuchen können die Kosten pro Fall ein Projekt, das in der Demo hervorragend funktionierte, unwirtschaftlich machen. Diese Berechnung sollte im Vorfeld und nicht im Nachhinein erfolgen.
Wir haben den kompletten Ablauf zwischen beiden Phasen entwickelt in Vom KI-Proof-of-Concept zur Produktion
Die Lösung besteht nicht darin, Pilotprojekte zu vergrößern. Vielmehr geht es darum, sie von Anfang an unter den Produktionsbedingungen durchzuführen, wenn auch in reduziertem Umfang.
Definieren Sie die Geschäftskennzahl, bevor Sie beginnen. Nicht die Anzahl der Anfragen oder aktiven Nutzer, sondern Durchlaufzeit, Fehlerrate, Kosten pro Fall, Konversionsrate oder Marge zählen. Und es definiert den Schwellenwert, der über Fortführung oder Abbruch entscheidet. Ein Pilotprojekt ohne Abbruchkriterium ist kein Experiment, sondern ein verkappter Kompromiss.
Verwenden Sie von Anfang an reale Daten, auch wenn es nur wenige sind. Ein Pilot mit einhundert realen Fällen lehrt mehr als einer mit zehntausend sauberen Fällen, denn die einhundert realen Fälle beinhalten die Probleme, die Ihnen im Alltag begegnen werden.
Es beinhaltet eine tatsächliche Ausnahme im Geltungsbereich. Wählen Sie den häufigsten seltenen Fall und beheben Sie ihn innerhalb der Pilotphase. Wenn das Design nicht mit einer Ausnahme umgehen kann, wird es auch nicht mit dreißig umgehen können.
Der Geschäftsinhaber sollte vor dem technischen Team ernannt werden. Und dass es jemand ist, der die Verantwortung für das Ergebnis des Prozesses trägt, nicht für die Technologie.
Berechnen Sie die Stückkosten bei tatsächlichem Volumen. Hochrechnen Sie vom ersten Tag aus. Wenn die Zahl im größeren Maßstab nicht funktioniert, ist es am besten, dies bis zur zweiten Woche herauszufinden.
Füge ein Ablaufdatum hinzu. Vier Wochen reichen aus, um die Funktionsfähigkeit eines Projekts zu überprüfen, sind aber zu kurz, um es in ein Zombie-Projekt abgleiten zu lassen. Genau deshalb folgen unsere Machbarkeitsstudien diesem Format: ein voll funktionsfähiger Proof of Concept (PoC) innerhalb eines Monats, inklusive Sicherheitsvorkehrungen, Nachvollziehbarkeit und menschlicher Überwachung. Nicht etwa, weil es kommerziell attraktiv wäre, sondern weil uns der kurze Zeitrahmen zwingt, den Umfang auf etwas zu beschränken, das sich tatsächlich validieren lässt.
Falls das Pilotprogramm bereits existiert und nicht vorankommt, gibt es drei ehrliche Lösungen, und keine davon beinhaltet Warten.
Diagnostizieren und entscheiden. Eine Analyse von Modell, Daten, Integration und Kosten, die drei Fragen beantwortet: Was kann gerettet werden, was muss neu geschrieben werden und was muss gestoppt werden? Dies ist das Ziel einer KI-Projektprüfung , und ist in der Regel innerhalb weniger Wochen gelöst.
Reduzieren Sie den Umfang auf etwas, das tatsächlich umgesetzt werden kann. Oftmals liefert die ursprüngliche Version 20% den gewünschten Nutzen für die Version 80% und ist innerhalb eines Monats einsatzbereit. Der Widerstand dagegen ist politischer, nicht technischer Natur: Eine Reduzierung des Umfangs käme einem Eingeständnis eines Teilversagens gleich.
Hör damit auf und dokumentiere die Gründe. Es ist die am meisten unterschätzte Option. Ein Pilot, der seine Tätigkeit beendet hat und dessen Lernfortschritte lückenlos dokumentiert sind, ist ein Gewinn. Ein Pilot in der Schwebe ist hingegen eine Belastung, die jedes Quartal Aufmerksamkeit erfordert.
Bei der Analyse von Pilotprojekten, die in Schwierigkeiten gerieten, zeigte sich, dass fast keines aufgrund des Modells selbst scheiterte. Die Gründe für das Scheitern waren vielmehr die Daten, die Berechtigungen, die Ausnahmen, die Integration oder das Fehlen eines Verantwortlichen. Mit anderen Worten: Sie scheiterten aus denselben Gründen, aus denen Softwareprojekte in den letzten dreißig Jahren immer wieder gescheitert sind.
Das sind im Grunde gute Nachrichten. Es bedeutet, dass das Problem kein technologisches Rätsel ist, sondern vielmehr ein Problem der Ingenieurstätigkeit und der Projektsteuerung. Und wir wissen, wie wir diese Probleme lösen können.
Die Frage, die in der nächsten Ausschusssitzung behandelt werden sollte, ist nicht, ob KI funktioniert. Vielmehr geht es darum, was an unseren Daten, unseren Berechtigungen und unserer Integration verbessert werden muss, damit jede Automatisierung, ob mit oder ohne KI, produktiv eingesetzt werden kann.
Aus sechs immer wiederkehrenden Gründen: unvollständige und widersprüchliche reale Daten, ein Genehmigungsmodell, das der Pilot nicht berücksichtigt hat, nicht vorgesehene Ausnahmen, mangelnde Integration in bestehende Systeme, das Fehlen eines Geschäftsführers und Stückkosten, die in realem Umfang nicht tragbar sind.
Laut der IBM-CEO-Studie 2025 haben nur 251 % der KI-Initiativen den erwarteten Ertrag gebracht, und nur 161 % wurden skaliert. S&P Global schätzte im März 2025, dass 421 % der Unternehmen den Großteil ihrer KI-Initiativen aufgegeben haben. Diese Zahlen variieren je nach Methodik der Studie erheblich.
Etwa vier Wochen. Das reicht aus, um die Funktionalität des Konzepts anhand realer Daten zu überprüfen, ist aber zu kurz, als dass das Pilotprojekt sich zu einem unbefristeten Vorhaben ohne absehbares Ende ausweiten würde. Der kurze Zeitrahmen zwingt uns, den Umfang auf etwas Überprüfbares zu beschränken.
Vor Projektbeginn werden Geschäftskennzahlen wie Zykluszeit, Fehlerrate, Kosten pro Fall, Konversionsrate oder Marge definiert, mit einem expliziten Schwellenwert, der über die Fortsetzung oder den Abbruch des Projekts entscheidet. Die Anzahl der Anfragen oder aktiven Nutzer belegt nicht die geschäftliche Auswirkung.
Es gibt drei Lösungswege: Erstens, das Problem durch ein Audit analysieren, um festzustellen, was beibehalten, was überarbeitet und was eingestellt werden kann; zweitens, den Umfang auf den innerhalb weniger Wochen umsetzbaren Teil reduzieren; oder drittens, das Projekt stoppen und die gewonnenen Erkenntnisse dokumentieren. Nur das Belassen des Projekts in der Schwebe verursacht Kosten.
Diese Zahl stammt aus einem vorläufigen Bericht des MIT-Projekts NANDA aus dem Jahr 2025, der noch nicht von Fachkollegen begutachtet wurde, auf einer kleinen Stichprobe basiert und methodische Kritik erfahren hat. Andere, zuverlässigere Quellen, wie beispielsweise IBM, weisen in dieselbe Richtung, wenn auch mit unterschiedlichen Größenordnungen: Das Skalierungsproblem ist real, aber die genaue Größenordnung ist noch nicht ermittelt.
Hat Ihr KI-Pilot monatelang nicht gesessen? Wir analysieren Ihr Modell, Ihre Daten, Ihre Integration und Ihre Kosten und zeigen Ihnen, wo Sie sparen, was Sie überarbeiten und was Sie einstellen sollten. Wenn das Projekt realisierbar ist, entwickeln wir innerhalb von vier Wochen einen funktionsfähigen Proof of Concept (PoC) mit allen notwendigen Sicherheitsvorkehrungen und Nachvollziehbarkeit. Lass uns über deinen Fall sprechen → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
