Das AI Operating Model und die Plattform

2019 zählte eine große europäische Bank 160 Machine-Learning-Modelle über ihre Geschäftseinheiten hinweg. Als eine neue Regulierung sie zwang, jedes Modell zu prüfen, das Kreditentscheidungen berührt, brauchte das Team des CDO sechs Wochen, nur um sie zu *finden*. Elf liefen in Produktion auf dem privaten Cloud-Account eines Data Scientists. Drei waren von Personen abgeschaltet worden, die das Unternehmen inzwischen verlassen hatten. Zwei verschiedene Teams hatten unabhängig voneinander dasselbe Churn-Modell auf denselben Daten gebaut und kamen zu unterschiedlichen Schlüssen, die zwei verschiedene Führungskräfte im selben Meeting zitierten.

So sieht AI Sprawl im großen MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßstab aus, und es ist das Standardergebnis. Jeder erfolgreiche POC schafft ein neues Waisenkind: ein Modell ohne Owner, ohne Monitoring, ohne Retraining-Zyklus und ohne Verbindung zu einer Plattform. Die Frage, die CDOs, die KI skalieren, von jenen unterscheidet, die technische Schulden anhäufen, lautet nicht „Wie bauen wir mehr Modelle?“. Sie lautet: „Welches Operating Model macht das 50. Modell günstiger zu bauen und sicherer zu betreiben als das fünfte?“

Das ist ein organisatorisches und architektonisches Designproblem, und es liegt bei Ihnen.

Das Spektrum der Operating Models: zentralisiert, embedded und die Hub-and-Spoke-Antwort

Jedes AI Operating Model liegt irgendwo auf einem Spektrum, das sich durch die Frage definiert, wo Talente berichten und wo Entscheidungen fallen. Beide Pole scheitern vorhersehbar.

Vollständig zentralisiert (ein Center of Excellence, dem alle Data Scientists gehören) liefert Konsistenz, Wiederverwendbarkeit und Governance, hungert aber beim Business-Kontext. Das zentrale Team wird zum Bottleneck, priorisiert Arbeit nach eigenen Maßstäben und liefert Modelle, die das Business stillschweigend ignoriert, weil niemand aus der P&L sie mitgeformt hat. Sie erhalten technisch exzellente Lösungen für Probleme, die niemand dringend hat.

Vollständig embedded (Data Scientists berichten in die Geschäftseinheiten) liefert Relevanz und Geschwindigkeit, reproduziert aber das Chaos der europäischen Bank. Jede Einheit erfindet Feature-Pipelines neu, wählt eigene Tools, setzt eigene Risikotoleranzen und baut keine gemeinsamen Assets. Sie erhalten 160 Modelle und keinen Hebel.

Die belastbare Antwort ist Hub-and-Spoke, aber der Begriff wird so lose verwendet, dass ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → die eigentlichen Designentscheidungen verdeckt. Entscheidend ist die Unterscheidung, *was dem Hub gehört und was den Spokes*, und diese Grenze richtig zu ziehen ist 80 % der Arbeit.

Eine brauchbare Regel: dem Hub gehört das Wie, den Spokes gehört das Was.

Dem Hub (Ihrer zentralen AI-Plattform-Organisation) gehört die paved road, die Plattform, die wiederverwendbaren Komponenten, das MLOpsMLOpsMachine Learning Operations: die Verbindung von ML- und DevOps-Praktiken, um Modelle zu industrialisieren, auszurollen, zu überwachen und in der Produktion zuverlässig neu zu trainieren.Vollständige Definition ansehen →-Tooling, das Framework für Model Governance, die Standards für Monitoring und Dokumentation sowie eine kleine Bank an Spezialisten (ML Engineering, Responsible AI, Platform SREs). Den Spokes (embedded Squads innerhalb der Business-Domänen) gehören die Auswahl der Use Cases, das domänenspezifische Feature Engineering, die Modellentwicklung gegen Business-Metriken und die P&L-Verantwortung für die Ergebnisse.

Der Fehlermodus der meisten CDOs besteht darin, diese Linie nach *Rolle* zu ziehen („alle Data Scientists berichten an mich“) statt nach *Verantwortung*. Ziehen Sie sie nach Verantwortung, dann folgen die Berichtslinien von selbst: Platform- und ML-Engineers berichten an den Hub; angewandte Data Scientists sitzen in den Spokes mit einer dotted line zum Hub für Standards und Karriereentwicklung.

Der Federation-Test

Bevor Sie sich auf eine Struktur festlegen, führen Sie den Federation-Test für Ihren Ist-Zustand durch. Bewerten Sie Ihre Organisation auf drei Achsen:

• Use-Case-Dichte pro Domäne. Wenn nur zwei oder drei Domänen echte, wiederkehrende KI-Nachfrage haben, funktioniert ein zentrales Modell und volles EmbeddingEmbeddingEin Embedding ist ein numerischer Vektor, der Daten (Text, Bilder oder Objekte) so darstellt, dass ihre Bedeutung erfasst wird: Ähnliche Elemente liegen im Raum dicht beieinander.Vollständige Definition ansehen → ist verfrüht, Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen keine Squads besetzen, die untätig herumsitzen.
• Varianz der Datenreife. Wenn Domänen sich in der Datenreife stark unterscheiden, ist eine starke zentrale Plattform nicht verhandelbar; sonst ziehen die reifen Domänen davon und die Nachzügler bauen Shadow Stacks.
• Regulatorische Exponierung. Hohe Exponierung zieht klar in Richtung zentraler Kontrolle über den Modell-Lifecycle, weil Sie ein auditierbares System of Record für jedes Modell brauchen.

Ein Händler mit konzentrierter Nachfrage in Merchandising und Supply Chain sollte keine ausufernde Federation aufbauen; zwei embedded Squads plus ein schlankes Plattformteam ist richtig. Eine globale Bank mit KI-Nachfrage in jeder Funktion und hoher Regulierung braucht einen starken Hub mit formalen Standards. Passen Sie das Modell der Diagnose an, nicht der gerade angesagten Organigramm-Mode.

Die Plattform: was „wiederverwendbar“ tatsächlich bedeutet

CDOs sagen „wir bauen eine AI-Plattform“ und meinen damit alles von einer Databricks-Lizenz bis zu einem Governance-Komitee. Seien Sie präzise. Eine produktive AI-Plattform ist ein Satz gemeinsamer Services, die einmalige Modellentwicklungen in Fließbandproduktion verwandeln. Der Test einer echten Plattform ist einfach: die marginalen Kosten und die Zeit für den Deployment von Modell N+1 sinken, während N wächst. Wenn jedes neue Modell dasselbe kostet wie das letzte, haben Sie ein Toolset, keine Plattform.

Vier Plattformschichten liefern diese sinkenden Grenzkosten.

1. Die Feature-Schicht. Die wiederverwendbare Komponente mit dem größten Hebel ist der Feature StoreFeature StoreEin zentrales Repository zur Verwaltung von ML-Features, das Konsistenz zwischen Training und Serving sicherstellt.Vollständige Definition ansehen →. Wenn Ihr Fraud-Team und Ihr Credit-Team beide „Transaktionsgeschwindigkeit des Kunden über 30 Tage“ brauchen, sollten sie dasselbe governierte, überwachte, versionierte Feature konsumieren und es nicht zweimal mit subtilen Unterschieden bauen. Im Feature Store wird das Problem der doppelten Churn-Modelle der europäischen Bank an der Wurzel gelöst: eine Definition, ein Owner, viele Konsumenten.

2. Die Pipeline- und Trainingsschicht. Standardisierte, templatisierte Trainingspipelines, damit ein neues Projekt von einem funktionierenden Scaffold startet und nicht von einem leeren Notebook. Hier kodieren Sie die „paved road“: Ein aus dem Template generiertes Projekt erhält automatisch Experiment Tracking, Lineage-Erfassung und einen Eintrag im Model Registry.

3. Die Deployment- und Serving-Schicht. Gemeinsame Patterns für Batch- und Echtzeit-Serving, damit ein Data Scientist nicht für jeden Launch über Infrastruktur verhandelt. Self-Service-Deployment hinter GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen → ist das Ziel.

4. Die Monitoring- und Governance-Schicht. Automatisierte Drift-Erkennung, Performance-Monitoring und das Model Registry, das die Audit-Frage in sechs Minuten beantwortet hätte, nicht in sechs Wochen.

Das Registry ist das Bindegewebe. Ein minimaler Registry-Eintrag macht das Operating Model durchsetzbar, weil *nichts ohne ihn in Produktion geht*:

model:
  name: credit_churn_v3
  owner_squad: retail-lending
  business_metric: 90d_retention_uplift
  training_data: feature_store/customer_txn_velocity@v4
  approval: risk_committee_2024_03
  monitoring:
    drift_check: daily
    performance_review: weekly
    retrain_trigger: auc < 0.72

Das ist keine Bürokratie; es ist der maschinenlesbare Vertrag zwischen dem Spoke, dem das Modell gehört, und dem Hub, dem die Plattform gehört. Es ist außerdem Ihr Audit Trail, Ihr Kill Switch und Ihr Wiederverwendungskatalog in einem Artefakt.

Die Build-Buy-Partner-Entscheidung für Plattformkomponenten

Sie werden nicht alle vier Schichten selbst bauen, und Sie sollten es auch nicht. Wenden Sie einen scharfen Filter an: Kaufen Sie die Rohre, bauen Sie die paved road, gehen Sie an der Front Partnerschaften ein.

Kaufen Sie Commodity-Infrastruktur, Serving, Orchestrierung, Experiment Tracking, wo reife Anbieter existieren und Ihre Anforderungen nicht besonders sind. Bauen Sie die dünne Schicht an opinionated Templates, Standards und Integrationen, die die Governance und das Datenmodell *Ihrer* Organisation kodieren, denn das ist Ihr tatsächlicher Hebel und kein Anbieter wird das für Sie tun. Gehen Sie Partnerschaften ein (oder nutzen Sie managed Frontier Services) für Fähigkeiten, die sich zu schnell bewegen, um sie selbst zu besitzen, insbesondere große Foundation Models, wo Eigenbau ein Weg ist, permanent hinterherzuhängen.

Der Fehler ist die Umkehrung: Teams bauen liebevoll einen maßgeschneiderten Feature Store (Rohre) und kaufen dann ein generisches Governance-Produkt, das nicht zu ihrem Modell-Lifecycle passt (paved road). Am Ende pflegen Sie Infrastruktur, die keine Differenzierung bringt, während Ihre Standards undurchgesetzt bleiben.

Finanzierung, Talent und der Produkt-Betriebsrhythmus

Organigramm und Plattform sind notwendig, aber nicht ausreichend. Zwei Designentscheidungen bestimmen, ob das Operating Model am Montagmorgen tatsächlich funktioniert: wie Sie es finanzieren und wie Sie es betreiben.

Finanzieren Sie die Plattform als Produkt, nicht als Projekt. Der häufigste Weg, eine junge AI-Plattform zu töten, ist, sie als Investitionsprojekt an einen bestimmten Use Case zu binden. Der Use Case geht live, die Finanzierung endet, die Plattform verfällt, und das nächste Team baut sie neu. Finanzieren Sie den Hub stattdessen als dauerhaftes internes Produkt mit eigener Roadmap, eigenem Product Manager und eigenen Erfolgsmetriken, Adoption, Time-to-Production, Reuse-Rate. Die Spokes werden von den Geschäftseinheiten gegen P&L-Ergebnisse finanziert. Diese Trennung ist wichtig: Sie bedeutet, dass die Plattform den Abschluss jedes einzelnen Projekts überlebt, und sie bedeutet, dass das Business für Wert zahlt, während das Unternehmen für Hebel zahlt.

Ein konkreter Mechanismus: Berechnen Sie den Spokes eine leichte interne Verbrauchsgebühr für Plattformservices (Compute, Feature-Store-Abfragen, Serving). Das bewirkt drei Dinge gleichzeitig, es schafft Kostendisziplin in den Spokes, es gibt dem Plattformteam ein Nachfragesignal dafür, was als Nächstes zu bauen ist, und es tötet die Dynamik der „kostenlosen internen Ressource“, die zu Verschwendung führt. Halten Sie die Gebühr niedrig genug, dass sie niemals ein Team in Richtung Shadow IT treibt; das Ziel ist ein Preissignal, kein Profit Center.

Gestalten Sie das Talentmodell um eine Rotation, nicht um eine Mauer. Die Dotted-Line-Anbindung an den Hub scheitert, wenn sie nur eine Linie im Organigramm ist. Machen Sie sie real mit einer Rotation: Angewandte Data Scientists in den Spokes verbringen früh in ihrer Laufbahn eine definierte Zeit im Plattformteam. Sie lernen die paved road kennen, bauen eine wiederverwendbare Komponente und tragen diese Standards zurück ins Business. So verbreiten Sie das Operating Model kulturell statt per Anordnung, die Standards werden zu „so arbeiten wir“, weil die Leute, die in den Spokes arbeiten, sie mitgebaut haben.

Halten Sie Ihre knappsten Talente, Senior ML Engineers, Responsible-AI-Spezialisten, im Hub, wo ihr Hebel über alle Use Cases hinweg am größten ist. Verteilen Sie die angewandten Talente in die Spokes, wo Domänennähe sie wirksam macht.

Der Betriebsrhythmus: wie Arbeit tatsächlich fließt

Der Mechanismus, der Hub-and-Spoke zum Laufen bringt, ist ein Intake- und Stage-Gate-Prozess, der dem Hub gehört, aber gemeinsam gesteuert wird. Jeder vorgeschlagene Use Case durchläuft Gates, die früh bewusst leichtgewichtig und spät rigoros sind:

1. Intake. Ein einseitiges Problem Statement mit benanntem Business Owner und quantifizierter Werthypothese. Kein Owner, keine Wertzahl, kein Eintritt. Dieses eine Gate eliminiert den größten Teil des Sprawls.
2. Feasibility. Ein zeitlich begrenzter Spike (zwei bis vier Wochen) gegen echte Daten auf der Plattform. Das Ergebnis ist ein Go/No-Go, und entscheidend: die meisten POCs sollten hier absichtlich sterben. Eine hohe Konversionsrate von POC zu Produktion ist ein Warnsignal, kein Ehrenzeichen, sie bedeutet, dass Sie beim Intake nicht selektiv genug sind oder schwache Ideen nicht schnell genug beenden.
3. Produktivsetzung. Das Modell kommt ins Registry, erhält seinen Monitoring-Vertrag, durchläuft eine Governance-Prüfung passend zu seiner Risikostufe und wird über die paved road deployt.
4. Betrieb. Live-Monitoring, geplante Reviews und ein Retirement-Plan. Jedes Modell hat einen Owner und ein Ablaufdatum für die Neubewertung.

Am Stage Gate wird das Operating Model sichtbar und durchsetzbar. Dort ist auch das Urteil des CDO am wertvollsten: Ihre Aufgabe an den Gates ist nicht, alles zu genehmigen, was technisch solide ist, sondern die Plattform und das Portfolio vor Arbeit mit geringem Wert zu schützen, die sich als Wartungsschuld anhäuft. Nein zu einem plausiblen, aber marginalen Modell zu sagen ist eine der Entscheidungen mit der höchsten Rendite, denn jedes Modell, das Sie deployen, ist eine Verbindlichkeit, die Sie über Jahre tragen.

Die Bank aus unserem Einstieg hat sich genau darum herum neu aufgebaut. Innerhalb von achtzehn Monaten sank die Deployment-Zeit für Modelle von Monaten auf Wochen, jedes Produktionsmodell hatte einen Registry-Eintrag und einen benannten Owner, und, kontraintuitiv, die *Gesamtzahl* der Modelle in Produktion ging zurück, weil das Intake-Gate den Sprawl an der Quelle stoppte. Weniger Modelle, mehr Wert, dramatisch weniger Risiko. Das ist es, was ein funktionierendes Operating Model produziert.

Key Takeaways

• **Ziehen Sie die Grenze zwischen Hub und Spoke nach Verantwortung, nicht nach Rolle: dem Hub gehört das *Wie* (Plattform, Standards, wiederverwendbare Komponenten, MLOps), den Spokes gehört das *Was* (Use-Case-Auswahl, Domänen-Features, P&L-Verantwortung).** Führen Sie den Federation-Test durch, Use-Case-Dichte, Varianz der Datenreife, regulatorische Exponierung, um zu kalibrieren, wie stark der Hub sein sollte.
• Definieren Sie eine Plattform über sinkende Grenzkosten: wenn Modell N+1 nicht günstiger und schneller auszuliefern ist als Modell N, haben Sie ein Toolset, keine Plattform. Priorisieren Sie Feature Store und Model Registry, sie lösen Duplizierung und Auditierbarkeit an der Wurzel.
• Finanzieren Sie die Plattform als dauerhaftes internes Produkt mit Adoption- und Reuse-Metriken, nicht als Investitionsprojekt, das an einen Use Case gebunden ist. Nutzen Sie leichte interne Verbrauchspreise, um ein Nachfragesignal und Kostendisziplin zu erzeugen, ohne Teams in Richtung Shadow IT zu treiben.
• Machen Sie das Intake-Gate zu Ihrem wichtigsten Ventil gegen Sprawl: kein benannter Business Owner und keine quantifizierte Werthypothese, kein Eintritt. Behandeln Sie eine hohe POC-zu-Produktion-Rate als Warnsignal, schwache Ideen früh zu beenden ist ein Feature des Operating Models, kein Scheitern.
• Jedes Produktionsmodell braucht einen Owner, einen Monitoring-Vertrag und ein Ablaufdatum. Wenige, gut governierte Modelle schlagen viele verwaiste; Ihre beste Entscheidung am Stage Gate ist oft das Modell, das Sie nicht deployen.