Der häufigste Besetzungsfehler bei KI-Projekten ist nicht die falsche Person, sondern die richtigen Personen in der falschen Reihenfolge und in der falschen Größenordnung. Unternehmen kündigen eine KI-Initiative an, schreiben fünf Stellen gleichzeitig aus, Data Scientist, ML Engineer, MLOps Engineer, Data Engineer, Product Manager, und haben sechs Monate später ein volles Team, eine hohe Payroll und kein ausgeliefertes System, weil die Arbeit im ersten Monat nur zwei dieser fünf gebraucht hätte. Ein KI-Team sollte so wachsen wie das Projekt: schmal starten, etwas ausliefern, und Rollen erst dann ergänzen, wenn die Arbeit sie tatsächlich verlangt.
Die Rollen, die ein KI-Projekt wirklich braucht
Ohne Titel-Inflation betrachtet greifen die meisten angewandten KI-Projekte auf sechs Funktionen zurück. Nicht sechs Personen, Funktionen: In kleinem Maßstab deckt eine starke Person mehrere davon ab.
- KI-/ML-Engineer: baut die Modelle oder LLM-Pipelines und die Software drumherum und bringt sie in Produktion. In modernen angewandten Projekten, besonders LLM-basierten, ist das die tragende Rolle.
- Data Engineer: macht die Daten des Unternehmens erreichbar, sauber und verlässlich, Pipelines, Qualitätsprüfungen, Zugriffe. Chronisch unterschätzt; auf den meisten Projekten wird hier der Zeitplan gewonnen oder verloren.
- MLOps-/Plattform-Engineer: Deployment, Monitoring, Retraining, Kostenkontrolle, der Unterschied zwischen einer Demo, die einmal lief, und einem System, das jeden Tag läuft.
- Product Owner mit KI-Verständnis: verantwortet das Geschäftsproblem, definiert, was „gut genug“ heißt, und schützt das Team vor Scope-Drift. Muss nicht programmieren, muss aber verstehen, was Modelle können und was nicht.
- Fachexpert:in: die Person, die den zu automatisierenden Prozess kennt, in Teilzeit, aber nicht verhandelbar, denn sie definiert die Ground Truth und erkennt Unsinns-Ausgaben, die keine Metrik erkennt.
- Data Scientist/Applied Researcher: nötig, wenn das Problem wirklich offen ist, eigene Modelle, neue Methoden, nicht, um erprobte Modelle in Produkte zu verdrahten, das deckt ein ML Engineer ab.
Die Reihenfolge zählt: erst Engineer, dann Daten, dann Betrieb
Die Reihenfolge, die über die meisten angewandten KI-Projekte hinweg funktioniert, ist eine Treppe, kein Urknall.
- 1Phase 1, validieren (Woche 1-8): ein:e Senior-KI-/ML-Engineer plus Fachexpert:in in Teilzeit und ein Product Owner, den es in Ihrer Organisation schon gibt. Das Ziel ist ein funktionierender Ende-zu-Ende-Durchstich auf echten Daten, keine Architektur.
- 2Phase 2, härten (Monat 2-5): Data Engineering ergänzen, denn spätestens jetzt hat der Pilot offengelegt, dass die Daten unordentlicher sind, als alle zugegeben haben, und eine:n zweite:n Engineer, wenn die Fläche wächst.
- 3Phase 3, produktionalisieren (Monat 4-8): MLOps-Fähigkeit ergänzen, Monitoring, Deployment-Automatisierung, Evaluations-Pipelines, anfangs oft fractional, in Vollzeit erst bei ausreichender Betriebslast.
- 4Phase 4, skalieren (ab Monat 6): Erst jetzt lohnt es sich, über Plattform-Teams, dedizierte Researcher oder mehrere Squads zu sprechen, und nur, wenn ein Portfolio an Use Cases sie rechtfertigt.
Teamformen nach Projektgröße
| Projektumfang | Typisches Team | Größe | Anmerkungen |
|---|---|---|---|
| Pilot / Proof of Value | 1 Senior-KI-/ML-Engineer, Fachexpert:in in Teilzeit, bestehender PO | 1-2 FTE | Ziel ist Evidenz, nicht Architektur; Spezialist:innen-Ausbau widerstehen |
| Produktionsfeature | 2 KI-/ML-Engineers, 1 Data Engineer, MLOps fractional, PO mit KI-Verständnis | 3-5 FTE | Die häufigste gesunde Form für einen einzelnen ausgelieferten Use Case |
| KI-Plattform / Portfolio | Use-Case-Squads (je 2-3), geteiltes Daten- & MLOps-Plattformteam, KI-Lead | 6-10+ FTE | Gerechtfertigt nur durch mehrere produktive Use Cases, nicht durch Ambition |
Die klassischen Über- und Unterbesetzungsfehler
- Eine:n Data Scientist für den Job eines ML Engineers einstellen: Das Projekt braucht ausgelieferte Software, und Analysefähigkeiten allein hinterlassen eine Prototyp-zu-Produktion-Lücke, die niemand verantwortet.
- Die Plattform vor dem Produkt bauen: ein MLOps-Engineer und eine Feature-Store-Initiative im ersten Monat, bevor irgendein Use Case Wert bewiesen hat, ist die teuerste Form der Prokrastination.
- Das einsame Genie: ein:e Engineer, die Modellierung, Daten-Klempnerei, Deployment und Stakeholder-Management allein trägt, das funktioniert acht Wochen, dann wird es zum Single Point of Failure des Projekts.
- Fürs Organigramm besetzen statt für die Phase: fünf gleichzeitige Ausschreibungen, weil das Zielbild fünf Kästchen zeigt, während die aktuelle Phase Arbeit für zwei hat.
- Die Fachexpert:in vergessen: Teams ohne strukturierten Zugang zu der Person, die den Prozess kennt, optimieren am Ende Metriken, die nicht zählen, und liefern Ausgaben, die das Business stillschweigend ignoriert.
Wann Fractional oder Embedded die Festanstellung schlägt, Rolle für Rolle
Nicht jede Funktion auf der Liste verdient einen dauerhaften Sitz, und das Gegenteil zu behaupten ist der Weg, auf dem KI-Initiativen zu Fixkostenproblemen werden. Eine praktikable Aufteilung: Die Rollen, die das System über seine gesamte Lebensdauer tragen, gehören in Vollzeit ins Haus; die Rollen mit spitzer, phasenbegrenzter oder anteiliger Last sind mit Embedded- oder Freelance-Expert:innen besser besetzt. Konkret: Der Kern-KI-/ML-Engineer eines Systems, das Sie behalten wollen, sollte Richtung Festanstellung tendieren. MLOps ist meist fractional, bis die Betriebslast einen vollen Sitz rechtfertigt. Senior-Datenarchitektur ist oft ein Aufbau-Problem, ein Quartal intensiv, danach beratend. Und ein:e eingebettete:r Senior-Engineer am Projektstart, Seite an Seite mit den Menschen, die das System später verantworten, kauft jetzt Geschwindigkeit und hinterlässt Wissen, ein völlig anderes Geschäft als gemietete Arbeitsleistung.
