Orientierung
Teamarbeit mit KI: Rollen, Workflows und Entwicklung
KI verändert nicht nur, wie Einzelpersonen arbeiten. Sie verändert, wie Teams Kontext aufbauen, Aufgaben verteilen, sich abstimmen und lernen. Wer KI nur als persönliches Produktivitätstool betrachtet, übersieht die wichtigere Frage: Wie muss sich Teamarbeit verändern, damit KI ihr volles Potenzial entfaltet?
Ausgangspunkt
Teams, nicht Einzelpersonen, sind die Einheit der Veränderung
Viele Organisationen führen KI als persönliches Produktivitätstool ein — ein Copilot für jede. Der Effekt ist messbar, aber begrenzt.
Die größere Chance liegt dort, wo Teams ihre Arbeit gemeinsam neu strukturieren: Wie werden Aufgaben zwischen Menschen und KI verteilt? Welche neuen Rollen entstehen? Wie verändern sich Abstimmung, Review und Entscheidungsfindung?
Diese Seite zeigt anhand von Forschung und konkreten Praxisbeispielen, welche Veränderungen in der Teamarbeit durch KI entstehen — und wie Führungskräfte diese Veränderungen gestalten können.
Das Fundament
Task Chaining: KI-Wert entsteht auf Workflow-Ebene
MIT Sloan Forschung — Chaining Tasks, Redefining Work
Die Forschung von Shahidi, Demirer, Horton, Immorlica und Lucier (MIT Sloan, Yale, Microsoft Research) zeigt: Der größte Hebel von KI liegt nicht darin, einzelne Aufgaben besser zu machen, sondern darin, wie Aufgaben sequenziert, gebündelt und zwischen Mensch und Maschine übergeben werden.
Workflow-Level > Task-Level
KI muss nicht jeden Schritt besser können als Menschen. Ganze Task-Chains zu automatisieren reduziert Koordinationskosten — und Koordination ist oft teurer als suboptimale Einzelschritte.
Task Bundling entscheidet
Sind KI-kompatible Tasks benachbart, lassen sie sich bündeln. Ein einziger Break in der Chain (ein Task, den KI nicht kann) gefährdet die ganze Kette — weil ständige Mensch-KI-Übergaben Review und Validierung kosten.
Workflow-Redesign, nicht Plug-in
Die Frage ist nicht: "Wie baue ich KI in meinen bestehenden Workflow ein?" Sondern: "Wie redesign ich meinen Workflow so, dass er KI-freundlich wird?" Das erfordert Zeit — bis zu einem Threshold dominieren Adoptionskosten die Gewinne.
Quelle: Shahidi et al. — "Chaining Tasks, Redefining Work: A Theory of AI Automation", MIT Sloan
Praxisfall
Ein Team, fünf Tage — wie AI-native Zusammenarbeit wirklich aussieht
Doctolib Engineering — dokumentierter Wochenbericht, Juni 2026
Das Doctolib-Team hat ein Experiment durchgeführt: Drei Personen, fünf Tage, komplett AI-native Arbeitsweise. Der detaillierte Wochenbericht zeigt, wie Teamarbeit unter KI-Bedingungen konkret funktioniert — und welche Regeln sich bewährt haben.
Vom seriellen Research zum synchronen Sense-Making
Vorher
Eine Person recherchiert unabhängig, schreibt Draft, wartet auf Review
Nachher
Diskussion im Team, AI fasst zusammen, Knowledge Graph beantwortet Rückfragen, alle haben denselben Wissensstand
Doctolib: 4 Technical Scopings an einem Tag statt eines in zwei Wochen
Knowledge Graphs als Team-Gehirn
Vorher
Wissen liegt verteilt in Docs, Tickets, Chat-Verläufen und Köpfen
Nachher
Strukturiertes Wissen pro Thema als lokaler Graph, verbunden zu einem graph-of-graphs — jeder Agent und jedes Teammitglied greift auf denselben Stand zu
Doctolib: Investition in Knowledge Graph vor der Woche — compounded jeden Tag
Skills als wiederverwendbare Bausteine
Vorher
Jede Aufgabe startet von Null, Wissen muss neu aufgebaut werden
Nachher
Knowledge-Skills (Fakten, Konzepte) und Workflow-Skills (Prozesse, Orchestrierung) werden live gebaut und wiederverwendet
Doctolib: Aus Macro-Tasks übergreifende Skill-Sets abgeleitet, live implementiert
Trennung von Implementierung und Review
Vorher
Gemischter Flow: während der Implementierung wird zwischendurch reviewed
Nachher
Klare Phasen: Tage 3-4 nur implementieren, Tag 5 nur reviewen — mixing verlangsamt beide
Doctolib: 'No reviewing or merging PRs' während der Implementation Phase
Review als kollektives Verstehen, nicht Risikofilter
Vorher
Review findet Fehler, verzögert, ist notwendiges Übel
Nachher
Owner erklärt Changes file-by-file, Demo, Team-Approval, AI verifies gegen Spec — Review ist finale Synchronisation
Doctolib: 'Review was not a filter on risk. It was the final act of collective understanding.'
Ergebnis der Woche
13 Tasks definiert, 12 implementiert, 10 am folgenden Montag in Production. Drei Parallelisierungs-Modi (fully delegated, fully manual, hybrid) — alle produzierten nutzbare Ergebnisse. Der Hybrid-Modus generierte die interessantesten Insights, weil zwei Versionen komplementäre Stärken hatten.
Quelle: Alexandre Guitton — "Inside the Room: how 5 days of AI-native collaboration actually work", Doctolib Engineering Blog
Rollen
Welche Rollen braucht ein AI-fähiges Team?
FutureProofing.dev — AI Team Structure Guide, 2026
Ein AI-fähiges Team braucht vier Kernrollen, die zusammen den gesamten Modell-Lebenszyklus abdecken — von Daten über Modellierung bis zu Betrieb und Produktverantwortung. Keine Rolle owned den ganzen Lifecycle allein; Wert entsteht erst in der Kombination.
AI/ML Engineer
Wandelt Modelle in Production-Software. Fine-Tuning, Evaluation-Harnesses, Modell-Integration. Die größte Rolle im Team.
2026 verschoben: Orchestrierung und Grounding großer Modelle, nicht nur klassisches ML.
— FutureProofing.dev
Data Engineer
Baut die Pipelines, die zuverlässige Daten liefern. Ohne diese Rolle verbringen AI Engineers ihre Zeit mit Data Plumbing.
Häufig unterschätzt: Der Data Engineer ist oft der erste Hire nach dem ersten AI Engineer.
— FutureProofing.dev
MLOps Engineer
Betreibt das Modell in Production: Deployment, Monitoring, Drift-Erkennung, Retraining. Der Boundary Marker für AI-native Teams.
Ab 3 Modellen in Production lohnt sich ein dedizierter MLOps Engineer.
— FutureProofing.dev
AI Product Manager
Übersetzt Geschäftsprobleme in KI-Probleme. Denkt in Wahrscheinlichkeiten, nicht binären Specs. Owns das AI-Risiko.
Anders als klassische PMs: Sie müssen um Data Availability und Modell-Feasibility priorisieren.
— FutureProofing.dev
Zwei Overlay-Rollen kommen bei Skalierung dazu: Der AI Architect owned die technische Richtung über mehrere Pods hinweg, der Data Scientist owned Research und Experimentation. Die operating rule: Keine Rolle owned den ganzen Lifecycle — das Team ist so designed, dass Data, Modeling, Operations und Product jeweils einen klaren Owner haben.
Strukturen
Teamgröße und Struktur nach Reifegrad
Die richtige Teamgröße hängt vom AI-Reifegrad ab, nicht vom Umsatz.
Der häufigste Fehler: Zu früh zu viele Modell-Bauer einstellen, bevor Data und Operations bereit sind. Data Engineers und MLOps müssen früher kommen, als Gründer erwarten.
| Stage | Größe | Typische Besetzung | Leistungsfähigkeit |
|---|---|---|---|
| Pilot / Seed | 1–3 Personen | 1 AI/ML Engineer (doublet als Data Scientist), Data Engineering part-time, Founder als PM | Ein Modell, ein Use Case, Wert beweisen |
| Growth | 5–8 Personen | 2–3 AI/ML Engineers, 1–2 Data Engineers, 1 MLOps, 1 AI PM | Mehrere Modelle in Production, eine Produktoberfläche |
| Scale | 15–20 Personen | Mehrere Pods mit AI/ML, dediziertem MLOps, embedded Data Engineering + AI Architect + 2+ AI PMs | Mehrere Produkte, Shared Platform, Governance |
| Enterprise | 20+ Personen (Multi-Pod) | Platform-Team + Product Pods, AI Architect(s), CAIO-Overlay, dedizierte Governance und ML-Platform | Org-weite AI-Fähigkeit, zentrale Plattform, auditiertes Compliance |
Strukturentscheidung: Bis 8 Personen ist Flat (alle in einem Team, ein Backlog) am schnellsten. Danach wird Matrix (Product Pods + Shared Platform) zur dominanten Struktur. Functional (Center of Excellence) ist nur in regulierten oder Research-geführten Organisationen sinnvoll, weil es klassische Hand-off-Probleme erzeugt.
Quelle: FutureProofing.dev — AI Team Structure Guide
Entwicklung
Upskilling als Teamaufgabe
Aus der AI-Org Knowledge Base
Die KB zeigt: Upskilling ist die mit Abstand am häufigsten genannte KI-Strategie — noch vor Hiring oder Tool-Einführung. Aber entscheidend ist, wie Upskilling organisiert wird. Nicht als HR-Programm, sondern als integrierte Teamarbeit.
Vom Support zum Builder
Teams entwickeln sich vom Konsumieren fertiger KI-Lösungen ("Support") zum aktiven Gestalten mit KI ("Builder"). Dieser Shift braucht Freiräume zum Experimentieren und eine Kultur, die Ausprobieren erlaubt.
Verlernen als Kernkompetenz
"Unlearning" in der AI-Ära bedeutet: Alte Routinen (Dokumentation von Hand schreiben, serielle Reviews, isolierte Recherche) aktiv aufgeben, um neue Arbeitsweisen zu ermöglichen. Das ist oft schwerer als Neues zu lernen.
Skills als Team-Artefakt
Im Doctolib-Experiment wurden Skills (Knowledge + Workflow) live im Team gebaut und wiederverwendet. Upskilling passiert nicht im Kurs, sondern indem Teams ihre eigenen Arbeitsbausteine entwickeln und teilen.
Einordnung
Was bedeutet das für deine Organisation?
Teamarbeit mit KI ist kein Tool-Thema. Sie erfordert bewusste Entscheidungen über Workflow-Design, Rollenverteilung, Teamstruktur und Lernprozesse.
Der Fehler ist nicht, mit einfachen Mitteln zu starten. Der Fehler ist, zu glauben, dass KI-Teamarbeit von alleine entsteht — nur weil alle einen Copilot haben.
Fünf Fragen für den Einstieg:
- Welche Tasks in unserem Team sind KI-kompatibel und lassen sich zu Chains bündeln — und wo zerstört ein Break die Kette?
- Haben wir die vier Kernrollen (AI/ML, Data, MLOps, AI PM) besetzt — oder fehlt eine, die den Lifecycle unterbricht?
- Wo könnten wir in einer Woche AI-native Zusammenarbeit ausprobieren, mit klaren Regeln und gemessenen Ergebnissen?
- Wer owned in unserem Team die kontinuierliche Schleife aus Monitoring, Lernen und Anpassen — nicht technisch, sondern fachlich?
- Welche alten Routinen müssten wir aktiv verlernen, damit neue Arbeitsweisen entstehen können?
Weiterlesen
Quellen und Vertiefung
- →
Doctolib Engineering — "Inside the Room"
medium.com/doctolib/inside-the-room — Konkreter 5-Tage-Bericht über AI-native Teamarbeit mit detaillierten Arbeitsweisen, Regeln und Ergebnissen.
- →
MIT Sloan — "Chaining Tasks, Redefining Work"
mitsloan.mit.edu/ideas-made-to-matter — Forschung zu Task Chaining: Warum KI-Wert auf Workflow-Ebene entsteht, nicht auf Task-Ebene.
- →
FutureProofing.dev — AI Team Structure Guide
futureproofing.dev/resources/ai-native-team — Rollen, Teamgrößen und Strukturen für AI-fähige Teams.
- →
iteratec — KI-Transformation: Human-Agent-Teams
explore.iteratec.com/news/ki-transformation — DACH-Praxis: Bis Mitte 2026 arbeiten fast alle Teams mit KI-Agenten.
- →
Verbalio — KI-Agenten und soziale Dynamik in Teams
verbalio.at/wie-ki-agenten-die-zusammenarbeit — DACH: Wie KI-Agenten Team-Dynamik verändern (ambivalentes Bild).
- →
Microsoft Work Trend Index 2026
microsoft.com/en-us/worklab/work-trend-index — Frontier Firms, Learning Systems, Agency als neues Betriebsmodell.
Verwandte Seiten
Vertiefung im AI-Hub
Diese Seite ist Teil der KI-Orientierung unter /themen/ai. Vertiefende Perspektiven:
- AI-native Organisationen— Rollen-Kollaps, Spec als Artefakt, Qualität als Constraint
- Agentic Engineering— Wie Harness, Workflows und Qualität die Entwicklungsarbeit verändern
- Beyond LLMs— Gesamte KI-Landkarte mit Retrieval, Semantic Layer und Klassischem ML
- AI-enabled Facilitation— KI als Moderator und Begleiter von Meetings und Workshops
- AI-enabled Teamentwicklung— KI als Katalysator für Diagnose, Retros, Feedback und Coaching
- KI in Organisationen— Grundlagen: was Organisationen über KI wissen müssen