Das erste KI-Produktteam eines deutschen Unternehmens hat bald zwei Termine im Kalender. Der eine mit dem Betriebsrat, der andere mit der Datenschutzbeauftragten, und kein amerikanisches Handbuch sieht sie vor. Wer sie einplant, verliert ein paar Wochen. Wer sie übersieht, verliert Monate und am Ende oft das Tempo, für das das Team gegründet wurde.
Ein KI-Team liefert Verhalten, kein Feature
Ein KI-Produktteam entsteht nicht, indem man einer klassischen Softwareorganisation ein Data-Science-Team anhängt. Die Arbeitseinheit ist kein Feature mit bekanntem Ergebnis mehr. Sie ist ein Verhalten, das je nach Daten anders ausfällt.
Daraus folgt eine Kette. Dasselbe Modell antwortet nicht immer gleich, also lässt sich Qualität nur an vielen Beispielen prüfen. Modelle verändern sich, also braucht es laufende Überwachung. Sie hängen an Daten, also braucht jemand den Nachweis, woher diese Daten stammen. Und weil Recht und Mitbestimmung mitreden, wird die Abstimmung deutlich aufwendiger als bei einem normalen Release.
Wer hier Feature-Lieferung nach agilem Standardschema betreibt, stößt schnell an Grenzen. Datenstrecken, Modellverhalten, Sicherheitsprüfungen und Bereitstellung über mehrere Umgebungen lassen sich nicht in denselben Takt pressen wie ein gewöhnliches Release.
Deshalb verbinden KI-Unternehmen Produktstrategie, KI-Kompetenz, experimentelle Strenge und Governance in einem gemeinsamen Betriebsmodell. Wie es aussieht, hängt weniger von Moden ab als vom Reifegrad und von der Zahl der KI-Produkte.
Ab drei Teams lohnt sich die gemeinsame Plattform
In frühen Phasen bündelt oft ein zentrales Center of Excellence die knappe ML-Expertise. Es setzt Standards, baut schnell Prototypen und berät die Produktteams. Das funktioniert, solange die Nachfrage klein bleibt.
Wächst sie, wird die zentrale Stelle zum Engpass. Ein Beispiel mit runden, frei gewählten Zahlen: Das Zentrum liefert neun Modelle pro Quartal, die Fachbereiche melden vierzehn Anfragen an. Die Warteschlange wächst um fünf pro Quartal, nach einem Jahr warten zwanzig Anfragen, gut zwei Quartale Arbeit. Fachbereiche, die so lange nicht warten wollen, bauen eigene Schattenteams.
Das häufigste nächste Muster trennt Plattform- von Anwendungsteams. Plattformteams verantworten die Bausteine, die alle Teams nutzen: Datenspeicher für Modellmerkmale (Feature Stores), Embedding-Bibliotheken, die Steuerlogik für Prompts, Trainingsstrecken, ein Verzeichnis aller Modelle, Werkzeuge zur Qualitätsprüfung und automatische Regelprüfungen. Die Anwendungsteams bauen darauf Funktionen, treiben Experimente und Rollouts und verantworten das Geschäftsergebnis.
Kurz: Plattformteams optimieren Skalierung, Anwendungsteams optimieren Nutzerwert. Das frühere Center of Excellence bekommt in diesem Bild eine neue Aufgabe: Es befähigt die Anwendungsteams und gibt Wissen weiter, statt zur Dauerstation für jede Modellfrage zu werden.
Ob sich die Plattform rechnet, lässt sich an einer Tafel prüfen. Bauen drei Teams je zwei Personenmonate an einer eigenen Evaluationsumgebung, sind das sechs Personenmonate Doppelarbeit. Eine gemeinsame Lösung kostet vielleicht drei Personenmonate plus einen halben pro Team für die Anbindung, zusammen 4,5.
Die Plattform lohnt sich, wenn 2 × N > 3 + 0,5 × N, wobei N die Zahl der Teams ist. Bei zwei Teams steht es 4 zu 4, bei drei Teams 6 zu 4,5.
Große Häuser landen meist beim föderierten Modell. Eine zentrale Plattform setzt die gemeinsamen Regeln. Die Fachbereiche haben eigene Teams mit eigenen Data Scientists, die selbstständig arbeiten, aber nach denselben Abläufen. Die gemeinsame Struktur zählt, weil Systeme am Ende so geschnitten sind, wie die Teams miteinander reden: Wer getrennt plant, baut getrennte Plattformen. In Konzernen mit SAFe landen die Produktteams oft in bestehenden Agile Release Trains. Das funktioniert, wenn die Plattform als eigener Train oder als Shared Service geführt wird und nicht als Abhängigkeit, die jeder Train einzeln verhandeln muss.
Jede Rolle steht für einen Fehler, den sonst niemand bemerkt
KI-Produkte verlangen Rollen für Modelllebenszyklus, Datenqualität, Evaluierung und Governance. Am leichtesten versteht man sie vom Fehler her, den jede verhindert.
Im Zentrum steht der KI-Produktmanager. Er verhindert das falsch gestellte Problem: gute Offline-Werte, aber niemand nutzt die Funktion. Er definiert Hypothesen, prüft die Datenlage, legt Evaluationskriterien und Leitplanken fest und hält Engineering, Data Science und Rechtsabteilung auf einer Linie. In vielen deutschen Konzernen heißt die Rolle auf dem Papier Product Owner. Entscheidend ist, ob sie über das Was entscheiden darf oder nur ein Backlog pflegt.
Der Data Scientist verhindert, dass ein Team an Daten scheitert, die die Aufgabe gar nicht tragen. Er arbeitet an Feature Engineering, Offline-Evaluierung und explorativen Analysen. Der ML Engineer bringt Modelle in den Betrieb: Integration, Performance, Skalierung der Inferenz, Drift-Erkennung. Dahinter hält MLOps den Betrieb stabil: Das Team überwacht laufend, wie sich die Modelle verhalten, trainiert sie automatisch nach und verwaltet ihre Versionen.
Zwei Rollen gewinnen in KI-Häusern eigenes Gewicht. Evaluierung und Sicherheit baut Golden Datasets auf, also feste Testfragen mit bekannten richtigen Antworten. Diese Rolle prüft Modelle auf erfundene Antworten, Verzerrungen und Sicherheitslücken und gibt sie frei. Das Produktdesign verhindert falsches Vertrauen: Es zeigt Unsicherheit an und legt fest, wo ein Mensch prüft oder überstimmt.
Für die Data Governance steht eine Rolle gerade, die Datenherkunft nachweist, Einwilligungen einhält und Audit-Trails führt. Sie arbeitet eng mit der Datenschutzbeauftragten zusammen. Spätestens wenn ein Modell personenbezogene Daten in großem Umfang verarbeitet, steht eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO an. Die sollte nicht erst in der Woche vor dem Launch beginnen.
Kleine Häuser können nicht sieben Rollen besetzen. Bei vier ML-Leuten trägt eine Person zwei oder drei davon, und das ist in Ordnung, solange die Kombination aufgeschrieben ist. Gefährlich wird es, wenn die Evaluierung „allen“ gehört und die Freigabe niemandem.
Für alle Produktrollen steigt zugleich die Grundanforderung, und ein Lernpfad mit KI-Kompetenz, Datenkompetenz und Experimentierfähigkeit wird zur Pflicht. Jeder PM braucht ein KI-Grundverständnis: wie Modelle halluzinieren, wie Retrieval funktioniert, was eine Evaluationsmetrik verschweigt. Er muss die Kennzahlen selbst lesen können, statt sie an die Data Scientists abzugeben: Precision (wie viele Treffer stimmen), Recall (wie viele richtige Fälle das Modell findet), Antwortzeit, Halluzinationsrate sowie Inferenzkosten und Drift-Indikatoren. Und er muss strategisch wie ökonomisch denken, weil KI die Kostenstruktur verändert.
Ein typischer Abwägungsfall: Eine neue Modellvariante hebt die Präzision von 88 auf 91 Prozent, verlängert aber die Antwortzeit von 1,2 auf 2,6 Sekunden. Im Live-Chat gewinnt die Latenz, die Variante wartet. Für E-Mail-Entwürfe, die ein Mensch später verschickt, geht sie live.
Eine Rahmenvereinbarung spart Monate beim Betriebsrat
Sobald ein KI-System im eigenen Unternehmen eingesetzt wird, greift die Mitbestimmung. Typische Fälle sind Ticketverteilung, Schichtplanung, Leistungsauswertung und Bewerberauswahl.
Nach § 87 Abs. 1 Nr. 6 BetrVG bestimmt der Betriebsrat mit bei technischen Einrichtungen, die geeignet sind, Verhalten oder Leistung der Beschäftigten zu überwachen. Nach der Rechtsprechung genügt die objektive Eignung, eine Absicht ist nicht nötig.
Das Betriebsrätemodernisierungsgesetz von 2021 hat die KI ausdrücklich ins Gesetz geschrieben. Nach § 80 Abs. 3 BetrVG gilt die Hinzuziehung eines Sachverständigen als erforderlich, wenn der Betriebsrat die Einführung oder Anwendung von KI beurteilen muss. § 90 BetrVG erfasst den geplanten Einsatz von KI bei der Unterrichtung über Arbeitsverfahren. § 95 Abs. 2a BetrVG erstreckt die Mitbestimmung bei Auswahlrichtlinien auf Richtlinien, die mit Unterstützung von KI erstellt werden.
Für das Betriebsmodell folgt daraus etwas Praktisches. Interne KI-Produkte brauchen eine Rahmen-Betriebsvereinbarung. Sie legt fest, welche Daten ein System auswerten darf, wer Ergebnisse sieht und wie neue Anwendungsfälle in einem vereinfachten Verfahren aufgenommen werden. Das setzt Vertrauen und saubere Dokumentation voraus.
Der Unterschied ist messbar. Teams mit früher Rahmenvereinbarung führen einzelne Anwendungsfälle in Wochen statt Monaten ein. Ein Rechenbeispiel mit frei gewählten Zahlen: Ein Team plant sechs interne Anwendungsfälle im Jahr. Dauert jede Einzelvorlage drei Monate und das vereinfachte Verfahren drei Wochen, spart die Rahmenvereinbarung rund 14 Monate Wartezeit, verteilt auf die Anwendungsfälle. Teams, die jedes Werkzeug einzeln vorlegen, verlieren genau die Geschwindigkeit, die das Plattformmodell bringen sollte.
Eine Einschränkung gehört dazu. Dieser Abschnitt beschreibt die Rechtslage nur in Grundzügen und ersetzt keine arbeitsrechtliche Prüfung. Ob ein konkretes System mitbestimmungspflichtig oder hochriskant ist, entscheidet der Einzelfall.
Governance läuft von Anfang an mit
Der Weg von der Idee zum ausgerollten Modell verläuft in Schleifen. Ein schwaches Offline-Ergebnis in Schritt vier schickt das Team oft zurück zu Schritt zwei:
- PM definiert Problem, Hypothesen und Evaluationskriterien
- DS prüft Datenqualität und -verfügbarkeit
- ML Engineers entwickeln Prototypen
- PM + DS analysieren Offline-Ergebnisse
- Engineering integriert das Modell
- PM führt Online-Experimente durch
- Sicherheitsteams validieren Risiken
- MLOps bringt das Modell in Betrieb, überwacht es und trainiert nach
Governance greift an jeder Station: bei der Prüfung der Datenquellen, beim Training und der Dokumentation, in Tests gegen Prompt-Angriffe, in den KI-Hinweisen der Oberfläche und in den Abläufen mit menschlicher Prüfung. Sie entscheidet über den Erfolg, vorausgesetzt, sie bremst nicht aus, was sie absichern soll.
Den Rahmen setzen Prinzipien verantwortungsvoller KI: Fairness-Kriterien, Schwellen für Erklärbarkeit, Risikobewertung, Dokumentation der Datensätze und Audit-Logs. Hilfreich ist, jede dieser Aufgaben ausdrücklich einer der Rollen oben zuzuordnen: Wer legt die Regeln fest, wer beschreibt die Risiken eines Anwendungsfalls, wer misst sie, und wer entscheidet, was mit einem gefundenen Risiko passiert?
Für Systeme, die bei Personalauswahl oder Beschäftigtenmanagement mitentscheiden, verlangt das europäische Recht ohnehin menschliche Aufsicht. Das Team plant die Rolle des prüfenden Menschen deshalb von Anfang an ein, mit Zeitbudget und klarer Befugnis zum Überstimmen.
In Deutschland legen nationale Durchführungsvorschriften zur KI-Verordnung fest, welche Behörde zuständig ist. Je nach Einsatzbereich kann das eine andere Aufsicht sein: Für KI im Finanzsektor gelten eigene Zuständigkeiten, und Datenschutzfragen bleiben bei den Datenschutzbehörden. Produktteams klären deshalb früh, welche Aufsicht für ihren Anwendungsfall gilt, und holen bei Unklarheit die Rechtsabteilung dazu.
Damit Prinzipien nicht bei jeder Freigabe neu verhandelt werden, laufen Evaluationsstrecken standardisiert mit: Red-Teaming, Golden Datasets, Offline- und Online-Tests, definierte Freigaben. Risikostufen machen die Prüftiefe vorhersehbar. Ein internes Zusammenfassungswerkzeug braucht weniger Prüfung als ein System, das über Bewerbungen mitentscheidet.
Wenn Governance zum Theater wird, zeigt sie Symptome. Freigaben dauern im Median länger als zehn Arbeitstage, Teams zerlegen eine Funktion in kleine Teile, um der Prüfung auszuweichen, und die Golden Datasets veralten, weil niemand sie pflegt.
Ein Modell endet nicht mit dem Release. Registrierung, Drift-Erkennung, Retraining-Zyklen und die geordnete Ausmusterung alter Modelle gehören zum Lebensweg. Das schlägt bis in die Roadmap durch. Sie plant danach, was das System können muss, welche Datenstrecken dafür nötig sind und von welchen Plattformbausteinen die Arbeit abhängt. Der PM muss Unsicherheiten, Risikoszenarien und Iterationspläne gegenüber Geschäftsführung, Fachbereich und Betriebsrat in jeweils passender Tiefe erklären.
Der erste Umbau, der sich wirklich lohnt
Das Organigramm kommt zuletzt. Welches der drei Strukturmodelle passt, ergibt sich daraus, wie viele KI-Produkte es gibt und wie oft dieselben Bausteine neu gebaut werden. Bei einem einzelnen Produkt ist ein Center of Excellence schneller. Sobald drei oder mehr Teams sich gegenseitig die Datenstrecken nachbauen, gewinnt das hybride Plattformmodell.
Aufschlussreicher als jedes Organigramm ist eine nüchterne Bestandsaufnahme der KI-Komponenten, die bereits doppelt existieren: Evaluationsdatensätze, Prompt-Orchestrierung, Drift-Überwachung. Als erster Plattform-Kandidat taugt die Komponente, die gerade an zwei Stellen parallel entsteht, auch wenn sie technisch die unscheinbarste ist.
Ausbremsen kann diesen Umbau in deutschen Unternehmen eher die Mitbestimmung als die Technik. Die Faustregel lautet deshalb: Ohne unterschriebene Rahmenvereinbarung mit Betriebsrat und Datenschutzbeauftragter keine gemeinsame Plattform für interne KI-Werkzeuge.