Wenn ein Unternehmen beschließt, KI einzusetzen, ist der erste Instinkt meist derselbe: Wir stellen einen Data Scientist ein. Dieser Instinkt ist nachvollziehbar — der Data Scientist ist die ikonische Rolle der KI-Ära. In der Praxis sehen wir jedoch, dass genau diese Einstellung oft der erste Fehler ist, der das Projekt verlangsamt oder zum Stillstand bringt.
Die richtige Teamzusammensetzung hängt davon ab, was Sie konkret bauen: Ein RAG-System über Unternehmensdokumenten unterscheidet sich von einem prädiktiven Anomaliemodell an einer Fertigungslinie, das sich wiederum von einem autonomen Agenten im Kundenservice unterscheidet. Jedes dieser Projekte braucht einen anderen Mix an Menschen — und für manche brauchen Sie gar kein internes Team.
Warum der Data Scientist nicht die erste Antwort ist
Ein Data Scientist fokussiert sich traditionell auf explorative Datenanalyse, statistisches Modellieren und Experimentieren. Diese Rolle ist wertvoll dort, wo Sie nicht wissen, was Sie in den Daten suchen — in der prädiktiven Analytik, beim Aufdecken von Mustern in historischen Daten, beim A/B-Testing.
Die meisten KI-Projekte, die Unternehmen tatsächlich brauchen, drehen sich jedoch nicht ums Musterfinden. Es sind Systemintegrationen: ein LLM, das an die Unternehmensdokumentation angebunden ist, ein Agent, der Bestellungen im ERP prüft, eine Automatisierung der E-Mail-Triage. Hier brauchen Sie jemanden, der produktionsreife Software bauen kann — nicht explorative Analyse.
In der Praxis sieht das so aus: Das Unternehmen stellt einen Data Scientist ein, der ansprechende Experimente in einem Jupyter-Notebook durchführt, die Ergebnisse sehen vielversprechend aus. Dann kommt die Frage: „Wann geht das in Produktion?" — und es herrscht Stille. Der Data Scientist ist kein Software-Ingenieur, kennt kein Docker, kein CI/CD, kein API-Design und kein Monitoring von Produktionssystemen. Das Projekt bleibt in der Prototyp-Phase stecken.
Rollen, die Sie wirklich brauchen
ML/AI-Ingenieur — das Herzstück des Teams
Das ist die Rolle, die die meisten Unternehmen unterschätzen, die aber entscheidend für produktionsfähige KI ist. Der ML/AI-Ingenieur vereint zwei Kompetenzen: Er versteht Modelle (Fine-tuning, Embeddings, Inference, Prompt Engineering) und kann diese Fähigkeiten in robuste Software verpacken (APIs, Queue-Systeme, Monitoring, Testing).
In der Praxis: Der ML-Ingenieur richtet eine RAG-Pipeline mit hybridem Retrieval ein, wählt das richtige Embedding-Modell, stimmt das Retrieval ab und stellt das Ergebnis als Produktions-API mit Observability bereit. Ein Data Scientist würde den ersten Schritt bewältigen; ein Software-Ingenieur ohne ML-Hintergrund würde den letzten übernehmen. Der ML/AI-Ingenieur beherrscht beides.
Für Unternehmen, die mit Frontier-Modellen über API bauen (Claude, GPT, Gemini), ist die Rolle des ML/AI-Ingenieurs noch wichtiger — hier geht es weniger ums Training und mehr um Orchestrierung, Prompt Engineering, Tool Calling und Integrationen. Mehr darüber, was Kosten und Zuverlässigkeit beeinflusst, finden Sie im Artikel Was ein KI-Agent in der Produktion wirklich kostet.
Domänenexperte — ohne ihn führt das Projekt nirgendwohin
Das ist die Rolle, die Unternehmen am häufigsten weglassen, wobei ihr Fehlen der zweithäufigste Grund für das Scheitern ist — nach minderwertigen Daten.
Der Domänenexperte ist jemand, der den Prozess, den Sie automatisieren, tiefgründig versteht. In der Praxis handelt es sich um einen erfahrenen Operator, einen Abteilungsleiter, einen Techniker oder einen Fachspezialisten. Diese Person weiß nichts über LLM, aber weiß genau: - Welche Antworten korrekt sind und welche nur korrekt aussehen - Wo die Grenzfälle, Ausnahmen und Situationen liegen, in denen das System versagt - Wie ein „gutes Ergebnis" aus geschäftlicher Sicht aussieht — nicht aus Sicht einer Accuracy-Metrik
Ohne Domänenexperten optimiert der ML-Ingenieur eine Metrik, nicht den realen Wert. Das Ergebnis ist ein System, das auf Demos brilliert und in der Produktion immer wieder dieselben Fehler wiederholt.
Der Domänenexperte muss kein Vollzeitmitglied des Teams sein. 4–8 Stunden pro Woche für die Überprüfung von Ausgaben, die Kalibrierung der Bewertung und Feedbackzyklen genügen.
Dateningenieur — nur wenn Sie ein Datenproblem haben
Wenn Ihr KI-Projekt von Datenpipelines abhängt — Bereinigung, Transformation, Streaming von Maschinenereignissen, Integration mehrerer Quellen — brauchen Sie einen Dateningenieur. Dieses Profil baut die Infrastruktur, die KI zuverlässig mit Daten versorgt.
Wenn Sie jedoch RAG über vorhandenen Dokumenten aufbauen oder einen Agenten entwickeln, der bestehende APIs aufruft, ist ein Dateningenieur in der ersten Phase nicht kritisch. Überschätzen Sie den Bedarf an dieser Rolle nicht — binden Sie sie ein, wenn Sie wirklich ein Datenproblem lösen, nicht präventiv.
MLOps-Ingenieur — ab einer gewissen Skalierung
MLOps umfasst das Deployment von Modellen, Drift-Monitoring, Versionsverwaltung und Retraining-Pipelines. Das ist eine kritische Rolle — aber erst dann, wenn Sie Modelle in der Produktion haben, die gewartet und aktualisiert werden müssen.
Für erste Projekte übernimmt der ML-Ingenieur diese Funktion in der Regel selbst — es ist unnötig, einen dedizierten MLOps-Spezialisten zu haben, solange es noch nichts zu verwalten gibt. Binden Sie ihn ein, wenn Sie mehr als 3–5 Produktionsmodelle verwalten oder Retraining-Zyklen angehen.
Product Owner — unterschätzte, aber unverzichtbare Rolle
Jedes KI-Projekt braucht jemanden, der dafür verantwortlich ist, welches Problem Sie lösen und wie Sie Erfolg messen. Ohne diese Rolle optimiert der ML/AI-Ingenieur technisch interessante Dinge, nicht den Geschäftswert.
Der Product Owner (oder KI-Produktmanager) definiert Erfolgsmetriken vor Projektbeginn, priorisiert Use-Cases nach ROI und vermittelt die Kommunikation zwischen dem technischen Team und den Stakeholdern. Diese Rolle kann von einem internen Projektmanager mit ausreichendem technischen Verständnis übernommen werden — es muss kein KI-Spezialist sein.
Das minimale funktionsfähige Team für das erste Projekt
Aus der Praxis für ein typisches erstes Produktions-KI-Projekt (RAG-System, Agent, LLM-Integration):
- 1× ML/AI-Ingenieur (Vollzeit während der Implementierung)
- 1× Domänenexperte (Teilzeit, 4–8 Std./Woche)
- 1× Product Owner / geschäftlich Verantwortlicher (Teilzeit, 2–4 Std./Woche)
Das ist das minimale funktionsfähige Team. Weniger als drei Personen in dieser Zusammensetzung ist eine risikobehaftete Konfiguration — entweder fehlt die technische Kompetenz oder die Anbindung an den realen Geschäftskontext.
Für komplexere Projekte (Multi-Agent-Systeme, Fine-tuning eines eigenen Modells, Integration mit mehreren Systemen) ergänzen Sie um einen Dateningenieur und einen MLOps-Spezialisten. Wann ein Fine-tuning des Modells sinnvoll ist, beschreiben wir im Artikel RAG vs. Fine-tuning — Entscheidungshilfe.
Internes Team vs. externer Partner — wann was
Das ist eine Frage, die sich Unternehmen zu spät stellen — meist erst dann, wenn der Recruiting-Prozess ins Stocken gerät oder das Projekt feststeckt.
Bauen Sie ein internes Team auf, wenn: - KI der Kern Ihres Produkts oder ein wesentlicher Wettbewerbsvorteil ist (nicht nur Unterstützung für einen bestehenden Prozess) - Sie einen langfristigen Investitionshorizont haben (12+ Monate) und ein stabiles Produkt als KI-Grundlage - Sie vollständige Kontrolle über Daten, Modelle und Pipeline benötigen (reguliertes Umfeld, DSGVO-kritische Systeme) - Sie schnell und in kurzen Zyklen iterieren wollen — ein extern geführtes Team ist dabei langsamer
Binden Sie einen externen Partner ein, wenn: - Sie das erste oder zweite KI-Projekt angehen und noch keine interne Kompetenz haben - Sie ein schnelles Ergebnis brauchen (3–6 Monate) — Einstellung und Onboarding eines internen Teams dauern typischerweise 4–9 Monate - Der Use-Case klar definiert ist und nach dem Deployment nur Wartung, keine aktive Weiterentwicklung erfordert - Sie Wissenstransfer möchten — ein guter Partner liefert nicht nur die Lösung, sondern befähigt das interne Team auch, damit zu arbeiten
Über die Entscheidung zwischen eigener Implementierung und einer fertigen Lösung haben wir ausführlicher im Artikel Build vs. Buy — KI-Lösung selbst bauen oder kaufen geschrieben.
Das Hybridmodell funktioniert gut: Der externe Partner liefert das erste Projekt, das interne Team lernt mit und übernimmt Verantwortung für Wartung und Weiterentwicklung. Entscheidend ist, dass der Partner diesen Transfer aktiv unterstützt — und nicht einfach liefert und geht.
Häufige Fehler beim Teamaufbau
Sie suchen einen „KI-Experten" — und finden keinen
Einen universellen KI-Experten gibt es nicht. Jeder wirklich erfahrene Fachmann hat eine Spezialisierung: Inference und Serving, Fine-tuning, Agent-Orchestrierung, RAG-Architektur. Suchen Sie jemanden mit konkreter Relevanz für Ihren Use-Case — keinen Universalgenies.
Sie unterschätzen die Zeit des Domänenexperten
Unternehmen planen typischerweise „ein paar Stunden pro Monat für Beratungen". In der Praxis braucht ein hochwertiges KI-Projekt eine regelmäßige, konsistente Einbindung des Domänenexperten — kein einmaliges Kickoff zu Beginn und ein Sign-off am Ende.
Sie verwechseln Experimentieren mit Produktionskompetenz
Ein Kandidat, der Ihnen beeindruckende Prototypen in einem Colab-Notebook zeigt, muss noch keine Erfahrung im Produktions-Deployment haben. Fragen Sie nach konkreten Beispielen: Was genau haben Sie deployed? Wie haben Sie das Monitoring gelöst? Wie haben Sie auf eine Regression in der Qualität reagiert? Die Antworten auf diese Fragen unterscheiden den Experimentator vom Ingenieur.
Sie skalieren, bevor Sie den Use-Case validiert haben
Wir sehen das regelmäßig: Das Unternehmen stellt ein ganzes Team ein (3–5 Personen), kauft GPU-Infrastruktur — und stellt sechs Monate später fest, dass der Use-Case für ein Produktions-Deployment nicht wertvoll genug war. Validieren Sie zuerst mit einem minimalen Team und einer externen Lösung; der Scale-up kommt, wenn Sie wissen, was funktioniert.
Warnsignale für eine falsche Teamzusammensetzung
Aus der Praxis — Warnsignale, die wir bei Kunden beobachten:
- Das Projekt steckt länger als 3 Monate in der Prototyp-Phase — es fehlt typischerweise ein ML/AI-Ingenieur mit Produktionserfahrung oder ein Product Owner, der Exit-Kriterien definiert
- Das System „funktioniert in der Praxis nicht" trotz guter Benchmarks — der Domänenexperte fehlt im Bewertungszyklus
- Das Team kann die Frage „wie messen Sie Erfolg" nicht beantworten — entweder fehlt der Product Owner oder die Metriken sind rein technisch definiert (Accuracy, F1) ohne Geschäftsbezug
- Das Recruiting dauert 6+ Monate ohne Ergebnis — das Profil ist zu allgemein oder die Gehaltserwartungen entsprechen nicht dem Markt; erwägen Sie einen externen Partner für die erste Phase
Wie Sie vorgehen, wenn Sie anfangen
Wenn Sie das erste KI-Projekt starten und noch kein internes Team haben, empfehlen wir:
- 1.Definieren Sie den Use-Case und Erfolgsmetriken vor jeglichem Recruiting — ohne diesen Schritt wissen Sie nicht, wen Sie suchen
- 2.Identifizieren Sie den Domänenexperten intern — das ist eine Rolle, die Sie nicht von außen kaufen können
- 3.Erwägen Sie einen externen Partner für die erste Phase — schnellerer Start, geringeres Risiko, Möglichkeit des Wissenstransfers
- 4.Das Recruiting des ML/AI-Ingenieurs starten Sie parallel zum Pilot — das Team wird bereit sein, das Projekt zum richtigen Zeitpunkt zu übernehmen
Mehr darüber, wie Sie die ersten 90 Tage eines KI-Projekts strukturieren, finden Sie im Artikel Wie man mit KI im Unternehmen startet.
Häufige Fragen
Brauche ich einen Data Scientist für ein KI-Projekt mit LLM?
In den meisten Fällen nicht — zumindest nicht als primäre Rolle. Ein Data Scientist ist wertvoll bei explorativer Analyse und statistischem Modellieren. Projekte, die auf LLM aufgebaut sind (RAG, Agenten, Integrationen), brauchen in erster Linie einen ML/AI-Ingenieur, der sowohl Modelle als auch produktionsreife Software versteht. Ein Data Scientist kann das Team später ergänzen — etwa bei der Evaluation oder der Analyse von Ausgaben.
Wie viele Personen sind mindestens für ein produktionsfähiges KI-Projekt nötig?
Aus der Praxis: Drei Rollen sind das Minimum — ML/AI-Ingenieur (Vollzeit), Domänenexperte (Teilzeit) und Product Owner / geschäftlich Verantwortlicher (Teilzeit). Ein Team mit nur einer Person oder ohne Domänenexperten hat ein deutlich höheres Risiko zu scheitern oder in der Prototyp-Phase stecken zu bleiben.
Ist es besser, ein eigenes Team aufzubauen oder einen externen Partner zu beauftragen?
Das hängt von Ihrem Horizont und Ihrem aktuellen Stand ab. Für das erste Projekt empfehlen wir einen externen Partner oder ein Hybridmodell — das ist schneller und reduziert das Risiko einer kostspieligen Einstellung vor der Validierung des Use-Cases. Ein internes Team ist sinnvoll, wenn KI der Kern Ihres Produkts ist und Sie einen langfristigen Investitionshorizont haben.
Wie erkenne ich, dass ein Kandidat Produktionserfahrung hat und nicht nur Prototypen-Erfahrung?
Fragen Sie nach konkreten Deployments: Was genau lief in der Produktion? Welches Daten- oder Benutzervolumen war vorhanden? Wie haben Sie Monitoring und Fehlerzustände gelöst? Wie haben Sie reagiert, als die Qualität schlechter wurde? Prototypisten antworten allgemein; Produktionsingenieure beschreiben konkrete Entscheidungen und Kompromisse.
Muss der Domänenexperte KI verstehen?
Nein — und das ist auch nicht wünschenswert. Der Domänenexperte muss den Prozess verstehen, den Sie automatisieren: beurteilen können, ob eine Ausgabe korrekt ist, Grenzfälle identifizieren und definieren, was aus geschäftlicher Sicht ein „gutes Ergebnis" ist. Technische KI-Kenntnisse sind hier keine Voraussetzung.
*Wenn Sie an der Teamzusammensetzung für ein KI-Projekt arbeiten oder abwägen, was Sie intern bauen und was Sie einem Partner überlassen sollten, sprechen wir gerne in einem kostenlosen Erstgespräch mit Ihnen. Wir helfen Ihnen einzuschätzen, welche Rollen Sie wirklich brauchen — und wann sich externe Zusammenarbeit mehr lohnt als eine Neueinstellung.*