Was sich an KI-Rollen 2026 wirklich verändert hat

Vor einigen Jahren hieß die Standardantwort auf „wir wollen KI machen" reflexartig „wir brauchen Data Scientists". Diese Antwort war damals nicht ganz falsch und ist heute nicht mehr richtig. Klassische ML-Arbeit — eigene Modelle trainieren, Features engineering, Hyperparameter — ist in vielen produktiven Anwendungen heute ein kleiner Teil des Bildes geworden, weil große Sprachmodelle einen Großteil dessen, was früher selbst gebaut wurde, von der Stange übernehmen.

Stattdessen ist eine andere Disziplin in den Vordergrund gerückt: AI Engineering. Es ist eine Mischung aus Software-Engineering, dem Verständnis von Sprachmodellen, Daten- und Pipeline-Arbeit, Sicherheit und Betrieb. Die Fähigkeiten, die im laufenden produktiven KI-Betrieb wirklich gebraucht werden, sind heute näher an einem guten Software-Engineering-Team mit zusätzlichem LLM-Verständnis als an einem klassischen Data-Science-Team.

Diese Verschiebung ist wichtig für die Personalplanung. Wer für die nächste KI-Anwendung nach den Rollenprofilen von 2020 sucht, sucht oft an der falschen Stelle — und mit der falschen Vergütungsstruktur.

Drei Phasen des Team-Aufbaus

KI-Teams entstehen in den meisten Unternehmen nicht in einem Schritt, sondern in drei erkennbaren Phasen. Sie verlangen unterschiedliche Rollenmischungen, unterschiedliche Verantwortungen und unterschiedliche Mengen an externer Unterstützung.

Die erste Phase ist der erste produktive Use Case. Hier braucht es wenige, dafür sehr fähige Personen mit breitem Profil — typischerweise zwei bis drei AI-Engineers, idealerweise gestützt durch eine erfahrene fachliche Eigentümerschaft aus dem Bereich, in dem die Anwendung wirken soll. Eine eigene Datenwissenschafts- oder ML-Abteilung ist in dieser Phase fast immer überdimensioniert.

Die zweite Phase ist der Aufbau einer Plattform. Mehrere Anwendungen laufen produktiv, gemeinsame Infrastruktur entsteht, Wiederverwendung wird wichtiger als Einzelfall-Lösungen. Hier kommen Plattform- und Operations-Profile dazu, oft auch ein klar zugeordneter Verantwortlicher für die KI-Infrastruktur. Was heute in vielen Unternehmen als „MLOps" verstanden wird, hat sich im LLM-Kontext zu „LLM Ops" oder schlicht zu einer Erweiterung der Plattform-Verantwortung entwickelt.

Die dritte Phase ist die Skalierung. Mehrere Teams nutzen die Plattform, KI-Fähigkeiten verteilen sich in die Fachbereiche, das KI-Kernteam wird selbst zur Service- und Beratungseinheit nach innen. Hier entstehen häufig Rollen, die in der ersten Phase niemand brauchen würde — interne KI-Beratung, Trainings- und Onboarding-Verantwortung, Governance.

Der häufigste Fehler in dieser Phasenlogik ist, in Phase eins schon nach Phase-drei- Strukturen zu hiren. Das produziert teures Personal, das in einem noch sehr kleinen Programm wenig zu tun hat — und das nach einigen Monaten wieder geht.

Welche Rollen wirklich gebraucht werden

Sechs Rollen tauchen in produktiven KI-Programmen verlässlich auf. Sie müssen nicht sechs Personen sein — in kleineren Teams werden mehrere davon kombiniert. Wichtig ist, dass jede Verantwortung benannt und besetzt ist.

AI Engineer. Die zentrale Rolle in produktiven LLM-Anwendungen. Beherrscht Software-Engineering, kennt Sprachmodelle aus der Anwendungsperspektive, arbeitet sauber mit Prompts, Tool-Use, RAG und Tests. Das ist die Rolle, an der ohne Übertreibung jedes KI-Programm hängt.

Fachliche Owner aus dem Bereich. Personen, die für den Use Case inhaltlich geradestehen — nicht beratend, sondern verantwortlich. Diese Rolle wird in den seltensten Fällen extern besetzt; sie sitzt im Service, im Einkauf, im Backoffice oder dort, wo die Anwendung wirken soll. Ihre Bedeutung beschreiben wir ausführlicher im Beitrag zur KI-Adoption im Unternehmen.

AI Product Manager oder Use-Case-Owner. Verantwortlich für Schnitt, Priorisierung, Erfolgskriterien und Übergabe zwischen Fachbereich und Engineering. In kleineren Teams kann das ein klassischer Product Manager mit ergänzter KI-Kompetenz übernehmen — in größeren Programmen lohnt sich eine eigene Spezialisierung.

Plattform- und Ops-Verantwortliche. Sobald mehrere Anwendungen laufen, braucht es eine klare Verantwortung für die gemeinsame Infrastruktur: Modellanbindung, Werkzeug-Schicht, Beobachtbarkeit, Kostensteuerung. Diese Rolle entsteht in Phase zwei, nicht in Phase eins.

Quality- und Test-Verantwortung. Tests von LLM-Anwendungen sind anders als klassische Software-Tests. Wer das nicht ausdrücklich verantwortet, bekommt es im Betrieb auf die schlechte Tour zurück. Diese Disziplin überschneidet sich direkt mit unserem Bereich LLM-Qualitätssicherung.

Datenverantwortliche pro Wissensdomäne. Wer pflegt Inhalte, wer aktualisiert Quellen, wer entscheidet über Berechtigungen? Diese Rolle ist in wenigen Unternehmen ausdrücklich besetzt — und in den meisten KI-Vorhaben am Ende der Engpass. Ihre Bedeutung haben wir im Beitrag zum Wissensmanagement mit KI beschrieben.

Welche Rollen oft überschätzt werden

Genauso wichtig wie die Frage nach den nötigen Rollen ist die Frage nach den modischen Rollen, deren Mehrwert oft schwer zu fassen ist.

Reine Data Scientists, die vor allem klassische ML-Modelle trainieren, sind in den meisten heutigen LLM-zentrierten Anwendungen nur in ausgewählten Spezialfällen wirklich nötig — etwa dort, wo eigenes Fine-Tuning oder klassische statistische Modelle Teil der Architektur sind. In den meisten Unternehmensanwendungen passt das Profil eines AI Engineers besser zur tatsächlichen Arbeit.

„Prompt Engineers" als eigene Vollzeitrolle. Prompt-Arbeit ist ein wichtiger Teil der Disziplin AI Engineering — eine eigene Vollzeitrolle nur dafür ist in den meisten Unternehmen nicht tragfähig. Wir haben das im Beitrag zum Prompt Engineering im Unternehmen ausgeführt: Prompt-Disziplin ist eine Pflicht im Engineering, nicht eine eigene Berufsfamilie.

KI-Strategie-Stäbe ohne Umsetzungsmandat. In manchen Unternehmen entsteht früh eine KI-Strategieabteilung, die Folien produziert und Frameworks verteilt, ohne dass jemand mit dem konkreten Aufbau einer Anwendung verbunden ist. Solche Strukturen sind selten der Engpass des Programms — und konsumieren oft Aufmerksamkeit, die in der Umsetzung fehlt.

Intern aufbauen, extern einkaufen oder hybrid arbeiten

Die Frage „intern oder extern" stellt sich bei KI-Teams ähnlich wie bei Build vs. Buy bei KI-Assistenten — mit dem Unterschied, dass es nicht um Software, sondern um Personen geht. Drei Antworten sind in der Praxis tragfähig.

Vollständig intern ist sinnvoll, wenn KI dauerhaft eine strategische Kernfähigkeit werden soll, das Unternehmen groß genug ist, um attraktive Rollen zu schaffen, und das eigene Onboarding für neue Methoden funktioniert. Voraussetzung ist eine ehrliche Einschätzung, ob diese Rollen am Markt und am Standort überhaupt zu besetzen sind — und ob die Vergütung dazu passt.

Vollständig extern ist sinnvoll, wenn ein einmaliges Vorhaben ansteht, intern keine Bandbreite für Aufbau besteht und die Kompetenz nach Abschluss nicht gehalten werden muss. In dieser Konstellation lohnt sich ein klarer Auftrag mit definiertem Übergabeschritt — sonst entsteht eine Abhängigkeit, die später unangenehm wird.

Hybride Modelle sind in den meisten Fällen die ehrlichste Antwort: ein kleiner interner Kern aus AI Engineers, Plattform-Verantwortung und fachlichen Ownern, ergänzt durch externe Partner für Spitzen, spezielle Architekturschritte oder zur Beschleunigung des ersten Use Cases. So entsteht intern Kompetenz, ohne dass jede Stunde extern bezahlt werden muss — und ohne dass das interne Team in einer Größe geplant wird, die später nicht ausgelastet ist.

Onboarding und Wissensaufbau

Ein neues Mitglied im KI-Team braucht selten klassisches Modell-Training. Es braucht Zugang zu den eigenen Anwendungen, klare Beispiele, einen ersten kleinen Beitrag und eine kompetente Person, an die es sich wenden kann. Das ist banal — und in vielen Unternehmen nicht so organisiert, dass es zuverlässig passiert.

Drei Punkte machen den Unterschied. Erstens eine aktuelle interne Dokumentation der bestehenden KI-Architektur, der genutzten Modelle, der Werkzeug-Schicht und der laufenden Use Cases. Zweitens ein realistischer erster Beitrag in den ersten zwei bis vier Wochen — kein Training-Projekt, sondern eine echte Aufgabe, deren Ergebnis nach dem Onboarding in Produktion landen kann. Drittens eine klare Mentor-Beziehung, durch die Wissen aus der bestehenden Mannschaft weitergegeben wird.

KI-Wissen veraltet schneller als in vielen anderen Bereichen. Das macht kontinuierliches Lernen nicht zur Kür, sondern zum Teil der Arbeit. Teams, die eine wöchentliche Lernzeit oder einen monatlichen Architektur-Review bewusst einplanen, haben spürbar weniger Probleme mit veralteten Mustern.

Wie sich KI-Kompetenz langfristig halten lässt

Die KI-Werkzeuglandschaft verändert sich schneller als die meisten anderen Engineering-Bereiche. Modelle wechseln, Frameworks kommen und gehen, neue Architekturmuster entstehen quartalsweise. Wer ein KI-Team aufbaut, muss damit rechnen, dass ein Teil des Wissens nach einem Jahr nicht mehr aktuell ist — und dass das normal ist.

Drei Dinge helfen, KI-Kompetenz dauerhaft im Haus zu halten. Bewusste Spezialisierung im Team: nicht jeder muss alles können, aber bestimmte Bereiche brauchen klare Heimaten. Zeit für Werkzeug-Wechsel: wer erwartet, dass ein neues Modell oder ein neues Framework „nebenbei" eingeführt wird, bekommt mittelfristig technische Schulden. Und klare Karrierewege im KI-Bereich: ohne Perspektive verlassen Engineers das Team — und der Markt zahlt fast immer mehr.

Mit zunehmender Reife des Programms hilft auch, ein Engineering-Modell zu wählen, das den Schritt vom Pilot zur Produktion nicht zur einmaligen Heldentat macht, sondern als Routine etabliert. Das Team lernt damit, was im Alltag wirklich trägt — und nicht nur, was in Demos beeindruckt.

Typische Fehler im KI-Team-Aufbau

Der häufigste Fehler ist, zu früh ein großes Team zu hiren. Drei AI Engineers ohne geklärte Use Cases sind teurer und weniger wirksam als eine Person mit klarer Aufgabe, die wir extern unterstützen. Die Reihenfolge sollte fast immer sein: Use Case schneiden, dann Team aufbauen — nicht umgekehrt.

Der zweite Fehler ist, alte Rollenprofile zu kopieren. Eine Stellenanzeige für „Senior Data Scientist" produziert Bewerbungen für eine Disziplin, die in den meisten produktiven LLM-Anwendungen nicht den Engpass darstellt. AI-Engineering- Profile sehen anders aus und werden anders gefunden.

Der dritte Fehler ist, externe Partner ohne Übergabeplan einzusetzen. Ein externer Sprint, der eine Anwendung in Produktion bringt, ohne dass intern jemand sie anschließend verantworten kann, ist eine Schuld, die im nächsten Quartal sichtbar wird. Der Vertrag mit dem externen Partner sollte den Übergabeschritt ausdrücklich enthalten.

Der vierte Fehler ist, fachliche Owner aus den Bereichen nicht ausdrücklich zu besetzen. Ein KI-Team ohne fachliche Heimat im Unternehmen baut Anwendungen, die vielleicht technisch funktionieren, aber im Tagesgeschäft an Akzeptanz oder inhaltlicher Tiefe verlieren.

Der fünfte Fehler ist, KI-Kompetenz an einer einzigen Person aufzuhängen. Wenn diese Person geht — und das passiert, gerade in einem heißen Markt — verliert das Programm innerhalb weniger Wochen einen großen Teil seines Wissens. Ein bewusst geteilter Wissensstand ist Pflicht, nicht Komfort.

Wann externe Unterstützung sinnvoll ist

Für ein einzelnes erstes KI-Vorhaben mit klarem Use Case lässt sich der Personalbedarf intern abschätzen, sobald jemand mit Erfahrung im Aufbau dabei ist. Sobald aber mehrere Vorhaben, eine Plattform oder ein wachsendes KI-Portfolio zusammenkommen, lohnt sich ein gezielter Blick von außen — auf Rollenzuschnitt, Phasenlogik, Sourcing-Modell und Karrierewege.

Wir arbeiten mit Unternehmen, die KI-Kompetenz nicht als Einkaufsproblem, sondern als langfristige Engineering-Disziplin verstehen. Wenn das zu Ihrer Situation passt, sprechen Sie uns an — am besten bevor die nächste Stellenbeschreibung veröffentlicht wird, die einen Markt anspricht, der das Vorhaben nicht trägt. Den passenden Rahmen dafür bieten wir über AI Consulting und unsere Arbeit an AI Engineering.