Die Zahlen sind seit Jahren konsistent, und sie werden nicht besser. Unabhängige Analysen von McKinsey, Gartner und MIT Sloan Management Review kommen zum gleichen Befund: Der überwiegende Teil aller KI-Initiativen in großen Organisationen erreicht nie den produktiven Enterprise-Betrieb. Die Piloten funktionieren. Die Demos überzeugen. Der Vorstand ist begeistert. Und dann: nichts.
Ich nenne dieses Phänomen den PoC-Friedhof: eine wachsende Sammlung technisch erfolgreicher Proof-of-Concepts, die nie den Sprung in skalierte Wertschöpfung schaffen. In zwanzig Jahren an der Schnittstelle von Daten und Strategie, von Big Data bei der BAWAG P.S.K. über BI-Führung in der Lufthansa Group bis zur AI-Koordination in einem internationalen Konzern, habe ich diesen Friedhof in fast jeder Organisation gesehen, die ich von innen kenne.
Das Scheitern beginnt nicht beim Modell
Die intuitive Erklärung, „die Technologie war noch nicht reif“, ist fast immer falsch. Die Modelle funktionieren. Was fehlt, ist etwas anderes: die strukturelle Kompatibilität zwischen dem Piloten und der Organisation, die ihn betreiben soll.
Ein Proof-of-Concept lebt in einer geschützten Umgebung: kuratierte Daten, keine Legacy-Integration, keine regulatorische Prüfung, kein 24/7-Betrieb, keine Haftungsfrage. Der Enterprise-Betrieb kennt keine dieser Freiheiten. Der Übergang vom einen zum anderen ist kein Deployment-Schritt, er ist ein organisatorischer Strukturwandel. Vier Muster tauchen in meinen Architektur-Reviews immer wieder auf:
1. Datenreife wurde als gelöst angenommen
Der Pilot lief auf einem handverlesenen Datensatz. Die Produktion braucht Datenpipelines, die über Systemgrenzen, Datenqualitätsschwankungen und historisch gewachsene Silos hinweg stabil liefern. In den meisten Organisationen existiert diese Infrastruktur nicht, und niemand hat sie ins Projektbudget eingepreist.
2. Governance kam nach der Technik
Modellrisiko-Management, Nachvollziehbarkeit von Entscheidungen, Eskalationspfade bei Fehlverhalten, Zuständigkeit für laufende Validierung: All das lässt sich nachträglich nur teuer und unvollständig einbauen. Organisationen, die Governance als nachgelagertes Compliance-Thema behandeln, bauen strukturell nicht skalierbare Systeme, unabhängig davon, wie gut das Modell ist.
3. Der Pilot hatte einen Champion, der Betrieb hat keinen Eigentümer
PoCs werden von motivierten Einzelpersonen getragen. Produktion braucht institutionalisierte Verantwortung: ein Operating Model, das definiert, wer das System betreibt, wer es weiterentwickelt, wer bei Drift eingreift und wer die Kosten trägt. Fehlt dieses Modell, stirbt das Projekt in dem Moment, in dem der Champion die Abteilung wechselt.
4. Die Architektur-Entscheidung fiel unter Informationsasymmetrie
Plattform- und Vendor-Entscheidungen wurden auf Basis von Hersteller-Narrativen getroffen, nicht auf Basis unabhängiger technischer Bewertung. Was im Piloten wie eine Abkürzung aussah, erweist sich in der Skalierung als Lock-in mit strukturellen Folgekosten.
Governance-Reife ist der eigentliche Prädiktor
Der gemeinsame Nenner dieser Muster: Keines davon ist ein Technologieproblem. Es sind Reifegradlücken, in Datenarchitektur, in Governance-Strukturen, in Operating Models und in der Urteilskompetenz der Entscheidungsebene.
„Die Frage „Welches Modell setzen wir ein?“ ist nachrangig gegenüber der Frage „Kann unsere Organisation ein solches System tragen?““
Organisationen, die die zweite Frage ehrlich beantworten, bevor sie die erste stellen, skalieren. Die anderen bauen Friedhöfe. Für regulierte Branchen (Banken, kritische Infrastruktur, öffentlicher Sektor) verschärft sich diese Logik zusätzlich: Der EU AI Act macht Governance-Reife von der Empfehlung zur Pflicht. Wer heute Systeme ohne dokumentierte Risikoklassifizierung, Datenqualitätsnachweise und menschliche Aufsichtsstrukturen baut, produziert Altlasten mit Ansage.
Was funktionierende Organisationen anders machen
In Engagements mit Enterprise-Kunden sehe ich bei den Organisationen, die die Lücke tatsächlich schließen, ein wiederkehrendes Muster:
- Sie beginnen mit einem Architektur- und Reifegrad-Review, nicht mit einem Use Case. Erst wenn klar ist, was die Organisation tragen kann, wird priorisiert, was sie bauen soll.
- Sie bauen Governance parallel zur Technik, nicht danach. Modellrisiko-Prozesse, Dokumentationsstandards und Zuständigkeiten entstehen im selben Projekt wie das System selbst.
- Sie internalisieren Kompetenz, statt sie dauerhaft einzukaufen. Externe Expertise wird so eingesetzt, dass sie Wissen überträgt, mit dem Ziel, dass die Organisation danach eigenständig priorisieren, bauen und betreiben kann.
- Sie behandeln die Use-Case-Pipeline als Portfolio. Nicht jeder Pilot muss skalieren, aber jeder Pilot braucht vor dem Start ein dokumentiertes Kriterium, unter welchen Bedingungen er skaliert wird oder stirbt.
Fazit
Die PoC-to-Production-Lücke ist kein Naturgesetz. Sie ist das vorhersehbare Ergebnis einer Reihenfolge-Entscheidung: Technik vor Struktur, Ambition vor Reife, Pilot vor Operating Model. Organisationen, die die Reihenfolge umdrehen, verwandeln dieselben Budgets in produktive Systeme statt in Friedhöfe. Strategiepapiere gibt es genug. Der Enterprise-Betrieb wartet.
