AI Org Building
Context
Abschnitt betitelt „Context“Dein Unternehmen hat ein erstes AI-Feature erfolgreich gelauncht. Der CEO will jetzt “AI ueberall”. Drei Business Units bitten gleichzeitig um AI-Ressourcen. Dein kleines ML-Team von vier Leuten ist ueberfordert, und jedes Projekt hat andere Anforderungen.
Du stehst vor der Frage, die jede Organisation frueher oder später beantworten muss: Wie strukturieren wir unsere AI-Teams? Zentralisiert, verteilt, oder irgendwas dazwischen? Die Antwort bestimmt, wie schnell ihr liefert, wie konsistent die Qualität ist, und ob AI ein strategischer Vorteil wird oder ein Flickenteppich.
Concept
Abschnitt betitelt „Concept“Drei Modelle für AI-Teams
Abschnitt betitelt „Drei Modelle für AI-Teams“1. Centralized (Center of Excellence) Ein dediziertes AI-Team bedient die gesamte Organisation. Alle AI-Expertise sitzt an einer Stelle.
- Vorteile: Konsistente Standards, geteiltes Tooling, effiziente Nutzung knapper AI-Talente
- Nachteile: Kann zum Bottleneck werden, mangelnder Domain-Kontext, Priorisierungskonflikte zwischen Business Units
- Passt für: Fruehe AI-Adoption (Maturity Level 1-2), Unternehmen mit wenig AI-Talent
2. Distributed / Embedded AI Engineers sitzen direkt in den Produktteams. Jedes Squad hat eigene AI-Kapazitaet.
- Vorteile: Tiefes Domain-Wissen, schnellere Iteration, direkte Accountability
- Nachteile: Duplizierter Aufwand, inkonsistente Practices, schwieriger für Platform-Infrastruktur
- Passt für: AI-reife Organisationen (Maturity Level 3+) mit ausreichend AI-Talent
3. Hub-and-Spoke (Hybrid) Ein zentrales AI Platform Team pflegt geteilte Infrastruktur (Model Serving, Eval Pipelines, Feature Stores), waehrend Embedded Engineers in den Produktteams sitzen.
- Vorteile: Balance zwischen Konsistenz und Domain-Fokus, skaliert besser als pure Zentralisierung
- Nachteile: Matrix-Reporting-Komplexität, erfordert starke Koordination
- Passt für: Mittlere bis grosse Organisationen, die von initialem AI-Erfolg zu breiter Nutzung skalieren
Die AI PM Rolle
Abschnitt betitelt „Die AI PM Rolle“Die Rolle des AI Product Managers hat sich verändert — von “PM, der mit ML Engineers arbeitet” zu einer eigenen Spezialisierung. McKinsey fand, dass die Nachfrage nach AI Fluency in Stellenanzeigen sich zwischen 2023 und 2025 fast versiebenfacht hat, mit dem staerksten Wachstum in Management- und Business-Rollen.
Ein AI PM muss nicht Modelle trainieren können. Aber er muss:
- Model Capabilities und Limitations verstehen
- Evaluation Criteria und Quality Thresholds definieren
- Mit probabilistischen Outputs umgehen können
- User-Erwartungen für non-deterministische Produkte managen
Upskilling statt Komplettersatz
Abschnitt betitelt „Upskilling statt Komplettersatz“Der effektivste Ansatz ist nicht Teams ersetzen, sondern bestehendes Wissen erweitern:
- PMs: Evals schreiben lernen, Model-Tradeoffs verstehen (Cost vs. Quality vs. Latency)
- Engineers: Prompt Engineering, RAG Patterns, Evaluation Frameworks
- Designer: Interaction Patterns für non-deterministische Outputs, Progressive Disclosure
Framework
Abschnitt betitelt „Framework“Entscheidungsmatrix: Welches Org-Modell passt?
| Faktor | Centralized | Hub-and-Spoke | Distributed |
|---|---|---|---|
| AI-Talent | Weniger als 5 Personen | 5–20 Personen | Mehr als 20 Personen |
| AI Maturity | Level 1-2 | Level 2-3 | Level 3+ |
| Produkte mit AI | 1-2 | 3-5 | 5+ |
| AI Literacy | Niedrig | Wachsend | Weit verbreitet |
Immer beibehalten, unabhängig vom Modell: Shared Eval Infrastructure, Model Governance, Cost Monitoring.
Evolutionspfad: Start centralized, dann Hub-and-Spoke bei wachsender Reife, Distributed nur wenn AI Literacy organisationsweit ist.
Scenario
Abschnitt betitelt „Scenario“Du bist VP Product bei einem B2B-SaaS mit 400 Mitarbeitern. Ihr habt 6 AI Engineers, 3 Produktteams die AI-Features brauchen, und ein erfolgreiches AI-Feature in Produktion. Der CEO will AI in allen Produktlinien innerhalb von 12 Monaten.
Aktuelle Situation:
- 6 AI Engineers sitzen in einem zentralen Team
- Team braucht durchschnittlich 6 Wochen pro AI-Feature
- 3 Produktteams warten jeweils auf AI-Ressourcen
- Produktteams haben wenig AI-Verständnis
- Kein geteiltes Eval-Framework, jedes Projekt baut eigenes
Wie wuerdest Du entscheiden?
Die beste Entscheidung: Wechsle zum Hub-and-Spoke-Modell. Behalte 2-3 Engineers als zentrales Platform-Team (Eval Infrastructure, Model Serving, Cost Monitoring). Bette die anderen 3-4 als Embedded Engineers in die Produktteams ein.
Warum:
- 6 AI Engineers und 3 Produkte liegen genau im Hub-and-Spoke-Sweetspot
- Das zentrale Team baut die geteilte Infrastruktur, die aktuell fehlt (vor allem Eval-Framework)
- Embedded Engineers bringen Domain-Kontext und eliminieren die 6-Wochen-Wartezeit
- Parallel: Upskilling-Programm für bestehende Product Engineers
Was viele falsch machen:
- Alle 6 Engineers verteilen, ohne zentrales Platform-Team — fuehrt zu inkonsistenter Qualität und dupliziertem Aufwand
- Rein zentralisiert bleiben — das Bottleneck wird mit 3 wartenden Teams nur schlimmer
- Sofort einstellen statt umstrukturieren — loest das Organisationsproblem nicht
Reflect
Abschnitt betitelt „Reflect“Die wichtigste Erkenntnis: AI Org Building ist keine einmalige Entscheidung, sondern ein Evolutionspfad. Starte einfach, skaliere die Struktur mit der Reife.
- Dein Org-Modell muss zu Deinem AI Maturity Level passen — nicht zu Deinen Ambitionen
- Upskilling bestehender Teams ist schneller und guenstiger als Neueinstellung
- Geteilte Infrastruktur (Eval, Monitoring, Governance) ist das Rueckgrat jedes Modells
Quellen: HBR “To Drive AI Adoption, Build Your Team’s Product Management Skills” (2026), Shopify CEO AI-First Memo (2025), Duolingo AI-First Restructuring (2025), Product School “AI Product Manager: Real Role or Buzzword?”