95 Prozent der KI-Pilotprojekte in Unternehmen erzielen keinen messbaren finanziellen Effekt. Drei unabhängige Studien aus 2026 kommen auf dieselbe Zahl, was ungewöhnlich genug ist, um sie ernst zu nehmen. Was in der Berichterstattung fehlt, ist die Frage, wo diese Projekte tatsächlich sterben. Am Modell liegt es fast nie. In den Projekten, in die ich gerufen werde, ist es das Security-Review, und zu diesem Zeitpunkt ist das Vorhaben seit Monaten tot, weil niemand die Arbeit eingeplant hat, die zu einem bestandenen Review führt.
Die Zahl stammt aus dem Project NANDA des MIT, aus einer Feldstudie von Domino Data Lab mit 639 Befragten und aus einer akademischen Auswertung von rund 4,5 Millionen Produktionstests aus diesem Jahr. Verschiedene Methoden, verschiedene Grundgesamtheiten, dieselbe Antwort. Die Begleitzahlen weisen in dieselbe Richtung. S&P Global fand, dass 42 Prozent der Unternehmen 2025 die Mehrzahl ihrer KI-Projekte aufgegeben haben. Eine IBM-Studie unter Vorstandsvorsitzenden fand, dass nur ein Viertel der Initiativen den erwarteten Ertrag lieferte. Morgan Stanley berichtete für Ende 2025, dass nur 21 Prozent der S&P-500-Unternehmen einen messbaren KI-Nutzen benennen konnten. Gemessen an geschätzten 30 bis 40 Milliarden Dollar Unternehmensausgaben ist das eine teure Menge Nichts.
Der Reflex ist, darin ein Urteil über die Technologie zu sehen. Das ist es nicht. Es ist ein Urteil über den Zuschnitt der Projekte.
Wo die Pilotprojekte wirklich sterben
Ich werde zu einem bestimmten Zeitpunkt gerufen. Der Prototyp funktioniert, jemand aus der Leitung fand ihn gut, und jetzt soll er in den Produktivbetrieb. Genau dann trifft das Projekt zum ersten Mal auf Security, Identity, Netzwerk und Compliance, und meist ist es das erste Mal, dass jemand die Fragen stellt, die diese vier Bereiche stellen.
Erreicht das System die Anwendungen, die es braucht, von dort aus, wo es tatsächlich laufen wird? Welches Credential hält es, worauf ist dieses Credential eingeschränkt, und wer rotiert es? Wenn es um drei Uhr nachts etwas Falsches tut, was stoppt es, und wer wird alarmiert? Und wenn in sechs Monaten jemand fragt, was es an einem bestimmten Tag mit einem bestimmten Datensatz gemacht hat, können Sie das mit Nachweisen beantworten statt aus der Erinnerung?
Keine dieser Fragen ist eine KI-Frage. Jede einzelne habe ich vielfach zu einer Firewall-Änderung, einem neuen Segment oder einem Servicekonto gestellt, zu dem sich niemand bekennen wollte. Neu ist nur, dass die Antworten jetzt für ein System vorliegen müssen, das aus eigenem Antrieb handelt, und der Prototyp war nie darauf ausgelegt, sie zu liefern. Ein Praktiker hat es diesen Monat auf X treffend formuliert: Der Engpass in der Produktion ist Governance, nicht Intelligenz, denn die meisten Projekte scheitern beim Übergang, weil Risiko, Security und Recht das Verhalten des Systems weder prüfen noch begrenzen können. Das deckt sich fast vollständig mit meiner Erfahrung.
Die 80 Prozent, die niemand eingeplant hat
Etwa 80 Prozent der Arbeit zwischen einem funktionierenden Prototyp und einem Produktivsystem sind Data Engineering, Governance, Integration in Arbeitsabläufe und Messinfrastruktur. Diese Schätzung taucht in den Analysen aus 2026 immer wieder auf, und sie deckt sich damit, wie sich die Arbeit von innen anfühlt.
Das Problem an diesem Verhältnis ist ein budgetäres. Das Pilotbudget deckt die 20 Prozent ab, denn die 20 Prozent erzeugen den Prototyp, und der Prototyp bewilligt die nächste Tranche. Für die 80 Prozent gibt es keine Position, keinen Sponsor und, am folgenreichsten, keinen Verantwortlichen. Also wird daraus eine zähe Diskussion zwischen vier Abteilungen, von denen jede überzeugt ist, dass es zu einer der anderen drei gehört. Abgebrochen wird das Projekt selten. Es kommt höflich zum Stillstand, und achtzehn Monate später erscheint es in einer Umfrage als Pilot ohne messbaren finanziellen Effekt.
| Die Frage | Was der Pilot beantwortet hat | Was die Produktion verlangt | Wer verantwortlich ist |
|---|---|---|---|
| Liefert es gute Ergebnisse? | Ja, auf kuratierten Eingaben | Notwendig, bei Weitem nicht hinreichend | Data Science |
| Erreicht es die echten Systeme? | Meist simuliert oder exportiert | Echte Integration, echte Credentials, echter Netzpfad | Plattform und Netzwerk |
| Können Sie es begrenzen? | Wird selten gefragt | Eingeschränkte Identität, Autorisierungsgrenze, Notaus | Security |
| Können Sie belegen, was es tat? | Nein | Ein Nachweispfad, der eine externe Frage übersteht | Compliance |
| Hat es eine Kennzahl bewegt? | Nicht gemessen | Eine vor dem Start erhobene Baseline | Die Fachverantwortung |
Punktuelle Intelligenz ist keine institutionelle
Die präziseste Erklärung, die ich dieses Jahr gelesen habe, stammt aus einer Smartsheet-Analyse, die im Juli über Axios erschien. Unternehmen haben zwei verschiedene Dinge verwechselt: punktuelle Intelligenz, die eine Mitarbeiterin bei einer Aufgabe schneller macht, und institutionelle Intelligenz, die die Organisation im Lauf der Zeit klüger macht. Gebaut wurde das Erste, in großem Maßstab, und Transformation genannt. Der zuständige KI-Vorstand sagte es unumwunden: Das Erledigen einzelner Aufgaben sei leichter geworden, die Zusammenarbeit über Systeme und Teams hinweg dagegen keinen Deut besser.
Diese Unterscheidung löst den scheinbaren Widerspruch in den Umfragedaten auf, in denen die Belegschaft echte Begeisterung meldet und das Rechnungswesen keinen Effekt sieht. Beides stimmt. Alle sind tatsächlich schneller. Nichts davon summiert sich, weil nichts eine Systemgrenze überschreitet, und das Überschreiten von Systemgrenzen ist genau der Teil, der die Integrations-, Identitäts- und Governance-Arbeit braucht, die niemand finanziert hat. Es ist dasselbe Muster wie bei einer Kontrolle, die grün meldet und nichts schützt, das ich in Sicherheitskontrollen, die lautlos versagen beschrieben habe.
Was in einem deutschen Projekt anders ist
Wer die amerikanische Berichterstattung liest und einen Rollout in Deutschland plant, übersieht drei Randbedingungen, die den Zeitplan spürbar verändern.
Der Betriebsrat ist ein Beteiligter, keine Formalie. Die betriebliche Mitbestimmung gibt Betriebsräten Rechte bei der Einführung technischer Einrichtungen, die zur Überwachung von Leistung und Verhalten geeignet sind, und ein Werkzeug, das Eingaben, Ausgaben und die einreichende Person protokolliert, fällt eindeutig darunter. Das ist kein Hindernis, das man umgeht, sondern eine Abstimmung, die man einplant. Teams, die das erst nach dem Piloten entdecken, verlieren ein Quartal. Teams, die den Betriebsrat einbeziehen, solange der Pilot noch ein Pilot ist, verlieren in der Regel gar nichts.
Die Compliance-Uhr läuft bereits. Das deutsche NIS2-Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten und zieht rund 29.500 Unternehmen in ein Dokumentations- und Meldewesen, dessen Registrierungsfrist bereits hinter uns liegt. Unabhängig davon sind die Transparenzpflichten der EU-KI-Verordnung seit dem 2. August 2026 durchsetzbar. Berührt Ihr KI-System einen erfassten Dienst, sind die Nachweispflichten kein Thema für nächstes Jahr. Wie unvorbereitet große Teile des Mittelstands auf den ersten dieser Punkte sind, habe ich bereits beschrieben, und KI-Projekte landen nicht neben dieser Lücke, sondern obendrauf.
Die Dokumentationskultur ist ein Vorteil, wenn jemand sie auf das Projekt richtet. Deutsche Unternehmen sind im internationalen Vergleich meist besser darin, einen Nachweispfad zu erzeugen, weil die Regulierung es ihnen seit Jahren abverlangt. Das Versagen, das ich sehe, besteht darin, dass diese Disziplin auf jedes System angewandt wird außer auf das KI-System, das als Experiment gilt und von den üblichen Regeln ausgenommen wird, genau bis zu dem Moment, in dem es das eben nicht mehr ist.
Was die erfolgreiche Minderheit anders gemacht hat
Die Organisationen mit Ertrag zeichnen sich nicht durch bessere Modelle aus. Alle haben Zugang zu denselben Modellen. Sie zeichnen sich dadurch aus, dass sie vor dem Produktivstart vier unspektakuläre Dinge getan haben: Sie haben zuerst in die Infrastruktur investiert, die Governance-Dokumentation vor dem Piloten geschrieben statt danach, Baseline-Kennzahlen erhoben, bevor irgendetwas eingeschaltet wurde, und dem eingeführten System eine namentlich benannte Fachverantwortung gegeben, die auch nach der Übergabe blieb. Diese Liste stammt von einem Praktiker, der einen autonomen Agenten seit über 300 Tagen produktiv betreibt, und sie ist nützlicher als die meisten Anbieterempfehlungen, weil sich bei jedem Punkt prüfen lässt, ob er erledigt wurde.
Die Baseline würde ich am entschiedensten verteidigen. Wer den Prozess vor der Veränderung nicht gemessen hat, kann die Verbesserung danach nicht belegen, und „kein messbarer finanzieller Effekt“ wird buchstäblich wahr, ganz gleich wie gut das System gearbeitet hat. Die Organisationen mit Ertrag beziffern ihn auf rund 3,70 Dollar je eingesetztem Dollar, und jede einzelne kann die Frage „verglichen womit“ beantworten.
Was ich vor dem nächsten Piloten prüfen würde
Fünf Dinge, von denen keines ein Strategieprogramm erfordert.
Benennen Sie die Verantwortung für die 80 Prozent vor dem Prototyp, nicht danach. Eine Person, namentlich, verantwortlich für Integration, Identität, Nachweise und Messung. Wenn sie niemand übernehmen will, haben Sie etwas Wichtiges gelernt, solange es noch billig zu lernen ist.
Setzen Sie Security in den Piloten, nicht ins Review. Eine Sicherheitsarchitektin, die ab Woche eins im Raum sitzt, kostet ein paar Stunden. Dieselbe Person, die dem System erstmals am Produktivtor begegnet, kostet ein Quartal und liefert eine schlechtere Antwort, weil die Architektur bis dahin um Annahmen herum ausgehärtet ist, die niemand hinterfragt hat.
Erheben Sie die Baseline in derselben Woche, in der Sie den Piloten zuschneiden. Was auch immer das System verbessern soll, messen Sie es jetzt. Das ist der billigste Punkt auf dieser Liste und der am häufigsten übersprungene.
Schreiben Sie auf, was das System tun darf. Nicht, was es tun soll, sondern was es darf, ausgedrückt als Identität mit einem Geltungsbereich. Ein handelndes KI-System ist ein Konto mit dauerhaftem Zugriff, mit den Folgen, die ich in Wildwuchs nicht-menschlicher Identitäten beschrieben habe. Lautet die Antwort „ein geteilter Schlüssel mit weiten Rechten“, wird das Security-Review das Projekt beenden, und es wird recht damit haben.
Terminieren Sie das Gespräch mit dem Betriebsrat auf Tag eins. Nicht als Compliance-Schritt kurz vor Schluss, sondern als Konstruktionsvorgabe, denn es verändert, was Sie protokollieren und wie, und das nachträglich einzubauen ist deutlich teurer, als es von vornherein vorzusehen.
Was davon bleibt
Nichts davon sagt, dass die Technologie nicht funktioniert. Es sagt, dass die Ausfallquote die organisatorische Reife misst und sie als KI-Leistung ausweist. Diese Unterscheidung ist wichtig, weil beide völlig unterschiedliche Abhilfen verlangen. Das eine bräuchte ein besseres Modell, worauf Sie keinen Einfluss haben. Das andere braucht jemanden, der die langweiligen 80 Prozent verantwortet, und das können Sie diese Woche regeln.
Die 95 Prozent sind kein Beleg für eine Blase. Sie sind ein Beleg dafür, dass die meisten Organisationen KI-Projekte so betreiben, wie sie Netzwerkprojekte betrieben haben, bevor Änderungsmanagement eine Disziplin wurde: beeindruckend im Labor, undokumentiert im Betrieb, und hinterher nicht nachweisbar. Das haben wir schon einmal repariert, und die Lehren lassen sich übertragen, wie ich in was Security- und Compliance-Arbeit tatsächlich lehrt dargelegt habe. Dieselbe Reparatur steht auch hier zur Verfügung, und sie ist kein Technologiekauf.
Wenn Ihr Pilot funktioniert und der Produktivstart immer wieder verrutscht, liegt der Engpass meist bei Integration, Identität und Nachweisen, nicht am Modell. Fragen Sie ein Review an, und Sie bekommen eine Einschätzung von außen, welcher Teil der 80 Prozent fehlt.