Das AI Operating Model und die Plattform

# Das AI Operating Model und die Plattform

2019 zählte eine große europäische Bank 160 Machine-Learning-Modelle über ihre Geschäftsbereiche hinweg. Als eine neue Regulierung sie zwang, jedes Modell mit Bezug zu Kreditentscheidungen zu prüfen, brauchte das Team des CDO sechs Wochen, nur um sie zu *finden*. Elf liefen produktiv auf dem privaten Cloud-Account eines Data Scientists. Drei waren von Leuten 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 in großem MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßstab aus, und es ist das Standardergebnis. Jeder erfolgreiche POC erzeugt ein neues Waisenkind: ein Modell ohne Owner, ohne Monitoring, ohne Retraining-Plan und ohne Verbindung zurück zu einer Plattform. Die Frage, die CDOs, die KI skalieren, von denen trennt, die technische Schulden anhäufen, lautet nicht „Wie bauen wir mehr Modelle?“ Sie lautet: „Welches Operating Model macht das 50. Modell billiger zu bauen und sicherer zu betreiben als das fünfte?“

Das ist eine Frage des organisatorischen und architektonischen Designs, und Sie müssen sie lösen.

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

Jedes AI Operating Model liegt irgendwo auf einem Spektrum, das davon bestimmt wird, 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 am Geschäftskontext. Das zentrale Team wird zum Bottleneck, priorisiert Arbeit nach eigenen MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßstäben und liefert Modelle, die das Business stillschweigend ignoriert, weil niemand aus der P&L an ihrer Gestaltung beteiligt war. Sie bekommen technisch exzellente Lösungen für Probleme, die niemand dringend hat.

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

Die dauerhafte Antwort ist Hub-and-Spoke, aber der Begriff wird so lose verwendet, dass ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → die eigentlichen Designentscheidungen verdeckt. Der entscheidende Unterschied ist, *was dem Hub gehört und was den Spokes*, und diese Grenze richtig zu ziehen, sind 80 % der Arbeit.

Eine nützliche Regel: Dem Hub gehört das Wie; den Spokes gehört das Was.

Dem Hub (Ihrer zentralen AI-Plattform-Organisation) gehören der Paved Road, die Plattform, die wiederverwendbaren Komponenten, das MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.Vollständige Definition ansehen →-Tooling, das Model-Governance-Framework, 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 Geschäftsdomä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 typische Fehler vieler CDOs ist, diese Linie nach *Rolle* zu ziehen („alle Data Scientists berichten an mich“) statt nach *Verantwortung*. Ziehen Sie sie nach Verantwortung, und die Berichtslinien folgen von selbst: Platform- und ML-Engineers berichten an den Hub; Applied Data Scientists sitzen in den Spokes, mit einer gestrichelten Linie zum Hub für Standards und Karriereentwicklung.

Der Föderationstest

Bevor Sie sich auf eine Struktur festlegen, machen Sie den Föderationstest für Ihren Ist-Zustand. 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 zentralisiertes Modell, und volle Einbettung ist verfrüht: Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen keine Squads besetzen, die untätig herumsitzen.
• Varianz der Datenreife. Wenn sich die Domänen 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-Lebenszyklus, 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 Föderation aufbauen; zwei embedded Squads plus ein schlankes Plattform-Team sind richtig. Eine globale Bank mit KI-Nachfrage in jeder Funktion und starker Regulierung braucht einen starken Hub mit formalen Standards. Passen Sie das Modell zur Diagnose an, nicht zur gerade angesagten Org-Chart-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 Set gemeinsamer Services, die Einzelanfertigungen von Modellen in Fließbandproduktion verwandeln. Der Test einer echten Plattform ist einfach: Die marginalen Kosten und die Zeit, um Modell N+1 zu deployen, sinken, während N wächst. Wenn jedes neue Modell so viel kostet wie das letzte, haben Sie ein Toolset, keine Plattform.

Vier Plattformschichten liefern diese sinkenden Grenzkosten.

1. Die Feature-Schicht. Die wirkungsvollste wiederverwendbare Komponente ist der Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen →. Wenn Ihr Fraud-Team und Ihr Credit-Team beide „Transaktionsgeschwindigkeit des Kunden über 30 Tage“ brauchen, sollten sie dasselbe governte, überwachte, versionierte Feature konsumieren und es nicht zweimal mit subtilen Unterschieden bauen. Im Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → wird das Duplikat-Churn-Modell-Problem der europäischen Bank an der Wurzel gelöst: eine Definition, ein Owner, viele Konsumenten.

2. Die Pipeline- und Trainingsschicht. Standardisierte, als Template hinterlegte Trainingspipelines, damit ein neues Projekt von einem funktionierenden Gerüst statt von einem leeren Notebook startet. Hier kodieren Sie den „Paved Road“: Ein aus dem Template generiertes Projekt erhält automatisch Experiment Tracking, Lineage-Erfassung und einen Eintrag in der Model Registry.

3. Die Deployment- und Serving-Schicht. Gemeinsame Patterns für Batch- und Real-Time-Serving, damit ein Data Scientist nicht bei jedem Launch über Infrastruktur verhandeln muss. Ziel ist Self-Service-Deployment hinter Guardrails.

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

Die Registry ist das Bindegewebe. Ein minimaler Registry-Eintrag macht das Operating Model durchsetzbar, weil *nichts ohne einen solchen 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 zugleich 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: Die Rohre kaufen, den Paved Road bauen, an der Frontier partnern.

Kaufen Sie Commodity-Infrastruktur, Serving, Orchestrierung, Experiment Tracking, dort, wo reife Anbieter existieren und Ihre Anforderungen nicht besonders sind. Bauen Sie die dünne Schicht meinungsstarker Templates, Standards und Integrationen, die die Governance und das Datenmodell *Ihrer* Organisation kodieren, denn genau dort liegt Ihr eigentlicher Hebel, und kein Anbieter wird das für Sie tun. Partnern Sie (oder nutzen Sie managed Frontier-Services) für Fähigkeiten, die sich zu schnell bewegen, um sie selbst zu besitzen, vor allem große Foundation Models, wo Eigenbau ein Weg ist, dauerhaft hinterherzulaufen.

Der Fehler ist die Umkehrung: Teams bauen liebevoll einen mamaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßgeschneiderten Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → (Rohre) und kaufen dann ein generisches Governance-Produkt, das nicht zu ihrem Modell-Lebenszyklus passt (Paved Road). Am Ende pflegen Sie Infrastruktur, die keine Differenzierung bringt, während Ihre Standards unerzwungen bleiben.

Funding, Talent und der Product Operating Rhythm

Org Chart 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, das Funding 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äftsbereichen gegen P&L-Ergebnisse finanziert. Diese Trennung ist wichtig: Sie bedeutet, dass die Plattform den Abschluss jedes einzelnen Projekts überlebt, und dass das Business für Wert zahlt, während das Unternehmen für Hebel zahlt.

Ein konkreter Mechanismus: Belasten Sie die Spokes mit einer leichten internen Nutzungsgebühr für Plattform-Services (Compute, Feature-Store-Abfragen, Serving). Das bewirkt drei Dinge gleichzeitig: Es schafft Kostendisziplin in den Spokes, es gibt dem Plattform-Team ein Nachfragesignal für die nächsten Bauvorhaben, und es beendet die Dynamik der „kostenlosen internen Ressource“, die zu Verschwendung führt. Halten Sie die Gebühr so niedrig, dass sie kein Team in Richtung Shadow IT treibt; das Ziel ist ein Preissignal, kein Profit Center.

Legen Sie das Talentmodell um eine Rotation an, nicht um eine Mauer. Die gestrichelte Linie zum Hub scheitert, wenn sie nur eine Linie im Org Chart ist. Machen Sie sie mit einer Rotation real: Applied Data Scientists in den Spokes verbringen früh in ihrer Zeit einen definierten Abschnitt im Plattform-Team. Sie lernen den Paved Road kennen, bauen eine wiederverwendbare Komponente und tragen diese Standards zurück ins Business. So verbreiten Sie das Operating Model kulturell statt per Dekret: Die Standards werden zu „wie wir arbeiten“, weil die Leute, die in den Spokes arbeiten, sie mitgebaut haben.

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

Der Operating Rhythm: 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 läuft durch Gates, die früh absichtlich leichtgewichtig und spät rigoros sind:

1. Intake. Ein einseitiges Problem Statement mit einem benannten Business Owner und einer quantifizierten Wert-Hypothese. Kein Owner, keine Wertzahl, kein Eintritt. Dieses einzige Gate eliminiert den größten Teil des Sprawl.

2. Feasibility. Ein zeitlich begrenzter Spike (zwei bis vier Wochen) auf echten Daten auf der Plattform. Das Ergebnis ist ein Go/No-Go, und entscheidend: die meisten POCs sollten hier absichtlich sterben. Eine hohe POC-to-Production-Conversion-Rate ist ein Warnsignal, kein Orden: Sie bedeutet, dass Sie beim Intake nicht selektiv genug sind oder schwache Ideen nicht schnell genug beenden.

3. Produktivsetzung. Das Modell kommt in die Registry, erhält seinen Monitoring-Vertrag, besteht ein Governance-Review, das auf sein Risk Tier skaliert ist, und geht über den Paved Road ins Deployment.

4. Betrieb. Live-Monitoring, geplante Reviews und ein Plan für die Außerbetriebnahme. 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 Urteilsvermögen 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 rentabelsten Entscheidungen, die Sie treffen, denn jedes Modell, das Sie deployen, ist eine Verbindlichkeit, die Sie jahrelang tragen.

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

Key Takeaways

• **Ziehen Sie die Hub-Spoke-Grenze nach Verantwortung, nicht nach Rolle: dem Hub gehört das *Wie* (Plattform, Standards, wiederverwendbare Komponenten, MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.Vollständige Definition ansehen →), den Spokes gehört das *Was* (Use-Case-Auswahl, Domänen-Features, P&L-Verantwortung).** Machen Sie den Föderationstest, 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 ausgeliefert wird als Modell N, haben Sie ein Toolset, keine Plattform. Priorisieren Sie den Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → und die 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 Nutzungspreise, 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 Wert-Hypothese, kein Eintritt. Behandeln Sie eine hohe POC-to-Production-Rate als Red Flag, schwache Ideen früh zu beenden ist ein Feature des Operating Models, kein Scheitern.
• Jedes Produktivmodell braucht einen Owner, einen Monitoring-Vertrag und ein Ablaufdatum. Weniger, gut governte Modelle schlagen mehr verwaiste; Ihre beste Entscheidung am Stage Gate ist oft das Modell, das Sie nicht deployen.