Warum die meisten KI-Programme nach dem ersten KI-Use-Case stocken

Der zweite Use Case ist der eigentliche Test

89 Prozent der Unternehmen führen KI-Pilotprogramme. Wie viele davon skalieren über den Piloten hinaus? Etwa jedes vierte Unternehmen, so eine Untersuchung der MIT Sloan. Diese Lücke sollte jeden, der ein KI-Programm verantwortet, alarmieren.

Der erste Use Case funktioniert immer. Er hat die Aufmerksamkeit des Vorstands, die besten Data Engineers, einen handverlesenen Datensatz und großzügig ausgelegte Erfolgskriterien. Er geht live. Der Lenkungsausschuss applaudiert. Jemand schreibt einen LinkedIn-Post. Dann beginnt der zweite Use Case, und alles kommt zum Stillstand.

Nicht weil das Modell versagt. Sondern weil jede Entscheidung im ersten Use Case eine Einzelfallentscheidung war. Die Datenpipeline war individuell gebaut. Der Feature Store war ein Ordner. Die Evaluierung lief manuell. Governance fand informell im Gespräch statt. Nichts davon lässt sich übertragen. Die AI at Work Insights des World Economic Forums benennen dieses Muster ausdrücklich: Unternehmen investieren stark in erste KI-Deployments, versäumen aber, das organisatorische Gerüst zu bauen, das weitere Deployments tragfähig macht.

Diagnose: Wo es wirklich hakt

Der Engpass ist nicht das technische Talent. Er ist nicht die Modellqualität. Er ist das Fehlen gemeinsamer Infrastruktur zwischen den Use Cases.

Datenzugriff wird jedes Mal neu gebaut. Das Team des ersten Use Cases verbrachte sechs Wochen damit, Zugriff auf Kundendaten zu verhandeln, sie zu bereinigen und eine Pipeline zu bauen. Das Team des zweiten Use Cases braucht dieselben Kundendaten plus Produktdaten. Es fängt bei null an. Andere Pipeline, andere Bereinigungslogik, andere Annahmen darüber, was ein „aktiver Kunde“ ist. Das Muster ist ernüchternd häufig: zwei Teams im selben Unternehmen, jedes drei Monate damit beschäftigt, Pipelines zum gleichen Quellsystem zu bauen — mit widersprüchlicher Geschäftslogik.

Semantische Definitionen existieren nicht. Was ist „Umsatz“? Gebuchter Umsatz? Realisierter Umsatz? ARR? Das erste Team hat es in seinem Notebook auf eine Weise definiert. Das zweite Team hat es anders definiert. Beide haben in ihrem Kontext recht. Keines davon ist wiederverwendbar. Genau dieses Problem soll der Semantic Layer von dbt lösen — ein einziger, zentral verwalteter Ort, an dem Geschäftskennzahlen einmal definiert und überall genutzt werden. Die meisten Unternehmen haben keinen.

Evaluierung ist Stückwerk. Das erste Modell wurde von dem Data Scientist evaluiert, der es gebaut hat. „Sieht gut aus“ war der Maßstab. Der zweite Use Case hat größere Tragweite — Kreditscoring, Schadenrouting, Bedarfsprognosen. Plötzlich reicht „sieht gut aus“ nicht mehr, aber es gibt keine Eval-Suite, keinen Benchmark-Datensatz, keinen systematischen Weg, das Modellverhalten vor dem Deployment zu testen.

Governance ist unsichtbar. Wer hat das erste Modell für die Produktion freigegeben? Meist dieselbe Person, die es gebaut hat. Das funktioniert einmal. Es funktioniert nicht bei fünf, zehn oder fünfzig Use Cases.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph LR
    UC1["Use Case 1"]
    UC2["Use Case 2"]
    UC3["Use Case 3"]
    UC1 --> D1["Individuelle Pipeline"]
    UC1 --> E1["Ad-hoc-Evaluierung"]
    UC1 --> G1["Informelle Freigabe"]
    UC2 --> D2["Individuelle Pipeline"]
    UC2 --> E2["Ad-hoc-Evaluierung"]
    UC2 --> G2["Informelle Freigabe"]
    UC3 --> D3["Individuelle Pipeline"]
    UC3 --> E3["Ad-hoc-Evaluierung"]
    UC3 --> G3["Informelle Freigabe"]
    style UC1 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style UC2 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style UC3 fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style D1 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style D2 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style D3 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style E1 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style E2 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style E3 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style G1 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style G2 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b
    style G3 fill:#2a1a1a,stroke:#ff6b6b,color:#ff6b6b

Jeder Use Case baut dieselben Komponenten von Grund auf neu. Der Preis ist nicht nur Doppelarbeit — er ist Widerspruch. Drei Teams, drei Definitionen von „Kunde“, drei Governance-Standards.

Perspektivwechsel: Städte haben das vor einem Jahrhundert gelöst

Das eigentlich Interessante an diesem Problem: Das Bauingenieurwesen hat es im 19. Jahrhundert gelöst.

Vor der städtischen Infrastruktur hatte jedes Gebäude in London seine eigene Wasserversorgung — einen Brunnen, eine Zisterne, eine Vereinbarung mit einem Wasserträger. Abwasser war Sache des Eigentümers. Gasbeleuchtung erforderte einen eigenen Vertrag pro Gebäude. Ein einzelnes Bauwerk zu errichten war beherrschbar. Eine Stadt zu bauen war unmöglich.

Der Durchbruch waren nicht bessere Gebäude. Es war gemeinsame Infrastruktur. Standardisierte Wasserleitungen, Kanalisation, Stromnetze. Man baute nicht jedes Gebäude mit einem eigenen Sanitärstandard. Man baute die gemeinsame Schicht einmal, und jedes weitere Gebäude wurde daran angeschlossen.

Enterprise-KI steckt in der Phase vor der kommunalen Infrastruktur fest. Jeder Use Case ist ein freistehendes Gebäude mit eigenem Brunnen. Das erste Gebäude funktioniert tadellos. Das zweite funktioniert tadellos. Aber beim fünften stecken Sie in inkompatiblen Leitungs- und Anschlusslogiken fest, und die Kosten jedes weiteren Gebäudes steigen, statt zu sinken.

Die Stückkosten von KI-Programmen sollten sich mit der Skalierung verbessern. Gemeinsame Datenpipelines, gemeinsame semantische Definitionen, wiederverwendbare Eval-Suites — jeder neue Use Case sollte günstiger und schneller sein als der letzte. Wenn das Gegenteil eintritt, wenn Use Case drei länger dauert als Use Case eins, ist das ein klares Signal: Die gemeinsame Schicht fehlt.

Ich bin nicht sicher, ob die Analogie in jeder Dimension trägt — Städte haben auch Bebauungspläne und Bauordnungen, an die Unternehmen selten heranreichen — aber der Kern stimmt. Ein gemeinsames Gerüst macht Skalierung erst möglich.

Der Minimum Viable Common Layer

Die Lösung ist keine massive Plattforminvestition. Sie besteht darin, den kleinsten Satz gemeinsamer Komponenten zu identifizieren, der den zweiten Use Case spürbar schneller macht als den ersten. Ich nenne das den Minimum Viable Common Layer (MVCL).

Vier Komponenten. Nicht zwölf. Kein zweijähriges Plattformprogramm.

1. Gemeinsamer Datenzugriff. Ein kuratiertes Set zentraler Datenprodukte — Kunde, Produkt, Transaktion, Interaktion — verfügbar über eine einzige Schnittstelle. Kein Data Lake. Kein Warehouse-Dump. Governance-konform verwaltete, dokumentierte, zugangskontrollierte Datenprodukte, die jedes Use-Case-Team ohne sechswöchigen Data-Engineering-Sprint konsumieren kann. Unity Catalog auf Databricks oder die Governance-Schicht von Snowflake können diese Rolle übernehmen, aber die Technologie ist weniger entscheidend als die Entscheidung, sie zu bauen.

2. Semantische Definitionen. Ein Ort, an dem „Umsatz“, „aktiver Kunde“, „Churn“ und „Conversion“ definiert, versioniert und durchgesetzt werden. Der dbt Semantic Layer ist eine Implementierung. Der Punkt ist: Geschäftslogik lebt an einem zentral verwalteten Ort, nicht verstreut über fünfzig Notebooks.

3. Eval-Suite. Ein standardisierter Weg, Modell-Outputs vor dem Deployment zu testen. Benchmark-Datensätze, Evaluierungsmetriken, Regressionstests. Nicht zwingend komplex — selbst eine gemeinsam genutzte Test-Suite mit positiven und negativen Referenzbeispielen bringt Sie von „sieht gut aus“ zu „erfüllt die definierten Kriterien“.

4. Governance-Framework. Ein schlankes Entscheidungs-Framework: In welcher Risikoklasse liegt dieser Use Case? Wer gibt das Deployment frei? Welches Monitoring ist erforderlich? Das muss keine Bürokratie sein. Eine einseitige Entscheidungsmatrix pro Risikoklasse reicht für den Anfang.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph TD
    MVCL["Minimum Viable Common Layer"]
    MVCL --> DA["Gemeinsamer Datenzugriff\nKuratierte Datenprodukte"]
    MVCL --> SD["Semantische Definitionen\nEinzige Quelle der Geschäftslogik"]
    MVCL --> EH["Eval-Suite\nStandardisiertes Testen"]
    MVCL --> GF["Governance-Framework\nRisikoklassen-Freigaben"]
    DA --> UC["Use-Case-Teams"]
    SD --> UC
    EH --> UC
    GF --> UC
    UC --> V["Schnellere Umsetzung,\nkonsistente Qualität,\nniedrigere Grenzkosten"]
    style MVCL fill:#1a2540,stroke:#00d4ff,color:#00d4ff,stroke-width:2px
    style DA fill:#1a2540,stroke:#ffb347,color:#ffb347
    style SD fill:#1a2540,stroke:#ffb347,color:#ffb347
    style EH fill:#1a2540,stroke:#ffb347,color:#ffb347
    style GF fill:#1a2540,stroke:#ffb347,color:#ffb347
    style UC fill:#1a2540,stroke:#ffffff,color:#ffffff
    style V fill:#0a2a1e,stroke:#00ff88,color:#00ff88,stroke-width:2px

Die Abwägung ist real. Den Common Layer zu bauen bremst Use Case eins. Das Team, das in acht Wochen eine Demo hätte zeigen können, braucht jetzt zwölf, weil es wiederverwendbare Komponenten baut statt Wegwerf-Skripte. Das ist ungeduldigen Sponsoren schwer zu verkaufen. Der Effekt zeigt sich bei Use Case zwei: Was wieder ein Zwölf-Wochen-Projekt gewesen wäre, wird zu einem Vier-Wochen-Projekt. Bei Use Case fünf gehen Teams innerhalb weniger Tage live.

Anwendung: Wie ING den Common Layer aufgebaut hat

Die ING Bank bietet ein öffentliches Beispiel dafür, wie der Aufbau gemeinsamer KI-Infrastruktur aussieht. Als ING gemeinsam mit McKinsey einen GenAI-Chatbot in nur 7 Wochen baute und damit 25 Prozent Produktivitätsgewinn erzielte, war diese Geschwindigkeit kein Zufall. ING hatte über das gesamte Bankgeschäft hinweg bereits in gemeinsam genutzte Dateninfrastruktur und Governance-Standards investiert. Das Chatbot-Team begann nicht bei null bei Datenzugriff, Metrik-Definitionen oder Compliance-Frameworks.

Vergleichen Sie das mit dem typischen Muster. Eine Bank baut ein automatisiertes Kreditscoring-Modell — gefeierter Erfolg. Dann braucht das Team für Betrugserkennung dieselben Kundendaten aus einem anderen Blickwinkel. Es verbringt acht Wochen damit, die Datenpipeline neu zu bauen, mit subtilen Unterschieden in der Definition von „Dauer der Kundenbeziehung“ und „Transaktionswert“. Die Evaluierung läuft über eine Excel-Tabelle. Governance ist eine E-Mail-Kette.

Der Unterschied ist der Common Layer. Durch den Ansatz von ING — unternehmensweit nutzbare Datenprodukte, zentral verwaltete Definitionen, standardisierte Evaluierung — konnte jeder weitere KI-Use-Case auf bestehender Infrastruktur aufbauen, statt sie neu zu erfinden. McKinseys Dokumentation des Projekts hebt hervor, dass die Umsetzung in 7 Wochen genau deshalb möglich war, weil die grundlegenden Daten- und Governance-Schichten bereits existierten.

Die unbequeme Wahrheit: Gemeinsame Infrastruktur vor dem ersten Use Case zu bauen, ist politisch schwierig. Der erste Use Case muss oft erst existieren, um die Investition zu rechtfertigen. Aber die Unternehmen, die nach Use Case eins innehalten, um den Common Layer aufzubauen — unternehmensweit nutzbare Datenprodukte, eine Metrik-Schicht, die zentrale Geschäftsbegriffe definiert, standardisierte Eval-Suites, eine schlanke Freigabematrix — beschleunigen drastisch. Was wieder ein Zwölf-Wochen-Projekt wäre, wird zu einem Vier-Wochen-Projekt. Bei Use Case fünf gehen Teams innerhalb weniger Tage live.

Die eigentliche Frage

Die Kennzahl, auf die es ankommt, ist nicht „Wie viele KI-Use-Cases haben wir gestartet?“. Sondern „Um wie viel schneller und günstiger ist Use Case N+1 im Vergleich zu Use Case N?“ Wenn diese Zahl sich nicht verbessert, skaliert Ihr KI-Programm nicht. Es wiederholt sich nur.

Die meisten Unternehmen bauen freistehende Häuser, wenn sie städtische Leitungen verlegen sollten. Der Bau des ersten Hauses dauert etwas länger. Jedes weitere Haus wird strukturell günstiger. Das ist der Unterschied zwischen einem KI-Programm, das nach dem Showcase ins Stocken gerät, und einem, das sich potenziert.

Quellen

• MIT Sloan Management Review — Scaling AI Results
• World Economic Forum — AI at Work Insights
• dbt Labs — Semantic Layer Documentation
• McKinsey — Banking on Innovation: How ING Uses Generative AI to Put People First

Daniel Piatkowski — Data & Analytics-Veteran, der AI-native Unternehmen prägt.