B7. Rollen und Verantwortlichkeiten für KI im Unternehmen
Rollen und Verantwortlichkeiten für KI im Unternehmen: RACI-Matrix, Rollenprofile und Entscheidungsrechte.
KI wirkt nur nachhaltig, wenn klar ist, wer wofür zuständig ist, über den gesamten Lebenszyklus von Strategie und Ideensammlung über Entwicklung und Betrieb bis zu Optimierung und Stilllegung.
Was dieses Kapitel liefert: Rollen, Entscheidungsrechte und die zugehörigen Vorlagen (RACI-Matrix, Rollenprofile) gebündelt an einer Stelle. Kapitel B6 legt die Organisationsform fest; hier werden die Rollen darin konkret.
Grundsätze für die Rollenverteilung
Eine Rolle hat ein klares Ziel, messbare Ergebnisse und definierte Entscheidungen.
Aufgaben sind entlang des Lebenszyklus verteilt: Intake, Entwurf, Entwicklung, Prüfung, Freigabe, Betrieb, Überwachung, Verbesserung, Stilllegung.
Verantwortlichkeiten sind getrennt: Wer entwickelt, prüft nicht sich selbst; wer freigibt, ist unabhängig.
Zentrale Leitplanken, dezentrale Umsetzung: Zentrale Teams sichern Standards und Bausteine, Fachbereiche liefern Produkte und Wirkung.
Jede Rolle hat Vertretung, Übergaben und dokumentierte Arbeitsweise.
Rollen entlang des Lebenszyklus
Die folgende Rollenlandkarte zeigt alle Rollen des Kapitels im Überblick, gruppiert in die vier Abschnitte, die danach im Detail folgen. Wichtig: Die Landkarte beschreibt Funktionen, nicht Stellen; wie Rollen je nach Unternehmensgröße gebündelt werden, steht im Abschnitt Skalierung am Kapitelende.
Jede Rolle wird mit fünf Feldern beschrieben: was die Rolle ist, warum es sie braucht, ihre Kernaufgaben, die Abgrenzung zu benachbarten Rollen und die typische Besetzung. Wer eine Rolle konkret einführt, überführt diese Angaben in den Rollensteckbrief weiter unten. Fachbegriffe werden bei ihrer ersten Nennung in Klammern erklärt.
Strategische und frühe Phase
Vorstandspat:in für KI
Feld
Beschreibung
Was die Rolle ist
Ein Mitglied von Vorstand oder Geschäftsführung, das die Schirmherrschaft für das gesamte KI-Programm übernimmt. Es ist ein Zusatzmandat obendrauf zur bestehenden Vorstandsrolle, keine eigene Stelle und keine operative Mitarbeit: Die Person sichert Rückhalt auf oberster Ebene und entscheidet im Konfliktfall, arbeitet aber nicht selbst an einzelnen Vorhaben mit.
Warum es sie braucht
KI-Vorhaben konkurrieren bereichsübergreifend um Budget und Personal. Ohne Fürsprecher auf oberster Ebene verlieren sie diesen Wettbewerb gegen das Tagesgeschäft, das kurzfristig immer dringlicher wirkt.
Kernaufgaben
Vertritt das KI-Portfolio (die Gesamtheit aller KI-Vorhaben) im Vorstand, gibt Priorität und Budget frei, entscheidet Zielkonflikte zwischen Bereichen und legt die Portfoliogrenzen fest, also auch, welche Anwendungsfelder das Unternehmen bewusst nicht verfolgt.
Abgrenzung
Entwickelt nicht die KI-Strategie (das ist Sache des Chief AI Officer) und steuert nicht das laufende Programm (AI-Programmleitung). Sie entscheidet dort, wo diese Ebenen nicht mehr weiterkommen, etwa bei Budget- oder Prioritätskonflikten.
Typische Besetzung
CIO, CDO oder CFO im Vorstand; in kleineren Unternehmen die Geschäftsführung selbst.
Chief AI Officer / CIO mit KI-Mandat
Feld
Beschreibung
Was die Rolle ist
Die Führungsrolle, die die KI-Strategie fachlich verantwortet, vergleichbar mit einer Bereichsleitung, die für ihr Thema den Kurs vorgibt. In vielen Unternehmen kein eigener Titel, sondern ein Mandat (ein ausdrücklicher Auftrag), das der CIO oder CDO zusätzlich übernimmt.
Warum es sie braucht
Jemand muss die Unternehmensziele in eine konsistente KI-Strategie übersetzen und über Bereichsgrenzen hinweg durchsetzen. Fehlt diese Klammer, entstehen Insellösungen, die je Bereich in unterschiedliche Richtungen laufen.
Kernaufgaben
Übersetzt Unternehmensziele in die KI-Strategie, verantwortet die Prinzipien, die Zielarchitektur (das technische Zielbild), die Roadmap und das Steuerungsmodell und berichtet an die Vorstandspat:in.
Abgrenzung
Setzt die inhaltliche Richtung, steuert aber nicht das Tagesgeschäft des Programms (AI-Programmleitung) und trifft keine Budgetentscheidungen auf Vorstandsebene (Vorstandspat:in).
Typische Besetzung
CIO oder CDO mit KI-Mandat; in großen Unternehmen eine eigene Position als Chief AI Officer.
AI-Programmleitung
Feld
Beschreibung
Was die Rolle ist
Die operative Steuerungsrolle für das KI-Programm: Sie hält im Alltag alle laufenden KI-Vorhaben zusammen, vergleichbar mit der Programmleitung in klassischen Transformationsprogrammen. Während der Chief AI Officer das Was und Wohin festlegt, sorgt diese Rolle für das geordnete Wie und Wann.
Warum es sie braucht
Einzelne KI-Vorhaben laufen sonst unkoordiniert nebeneinander, und niemand hat den Überblick über Status, gegenseitige Abhängigkeiten und Risiken.
Kernaufgaben
Nimmt neue Ideen über einen geordneten Eingangsprozess auf (Intake), organisiert deren Bewertung und Priorisierung, verfolgt Status und Risiken bereichsübergreifend und bereitet die Entscheidungen des Portfolio Boards vor.
Abgrenzung
Bereitet Portfolioentscheidungen vor, trifft sie aber nicht (das tut das Portfolio Board). Verantwortet keine einzelnen Produkte (Product Owner KI).
Typische Besetzung
Erfahrene Programm- oder Projektleitung, oft im KI-Kompetenzzentrum angesiedelt.
Portfolio Board für KI
Feld
Beschreibung
Was die Rolle ist
Ein Entscheidungsgremium, also eine feste Runde benannter Personen aus Fachbereichen, IT, Daten, Risiko und Finanzen, die gemeinsam über die KI-Vorhaben entscheidet. Keine Einzelrolle, sondern ein Besetzungskreis, der regelmäßig zusammenkommt.
Warum es sie braucht
Entscheidungen über Aufnahme und Reihenfolge von Vorhaben betreffen mehrere Bereiche zugleich. Ein gemeinsames Gremium verhindert, dass sich der lauteste oder mächtigste Bereich durchsetzt statt des sinnvollsten Vorhabens.
Kernaufgaben
Entscheidet über Aufnahme, Priorisierung und Beendigung von Vorhaben, gleicht das Portfolio mit Strategie und Budget ab und tagt in festem Rhythmus (siehe Portfolio-Review in Kapitel D4).
Abgrenzung
Entscheidet über das Portfolio als Ganzes, nicht über die Inhalte einzelner Produkte (Product Owner KI) und nicht über die Strategie selbst (Chief AI Officer).
Typische Besetzung
Benannte Vertreter der beteiligten Bereiche; den Vorsitz hat oft der Chief AI Officer oder die AI-Programmleitung.
Enterprise-Architekturleitung
Feld
Beschreibung
Was die Rolle ist
Die bestehende Architekturfunktion der IT, erweitert um KI-Fragen. Enterprise-Architektur ist der Gesamtbauplan der IT-Landschaft: Sie legt fest, wie Systeme, Daten und Schnittstellen zusammenpassen sollen, damit nicht jedes Projekt eine eigene, unverträgliche Lösung baut.
Warum es sie braucht
KI-Lösungen, die an diesem Zielbild vorbei gebaut werden, erzeugen Integrations- und Sicherheitsprobleme und lassen sich später kaum skalieren.
Kernaufgaben
Prüft neue Vorhaben auf Passung zu Zielarchitektur, Datenplattform, Integration und Sicherheit, gibt technische Schnittstellen frei und pflegt Referenzarchitekturen (bewährte Bauvorlagen, siehe Kapitel B5).
Abgrenzung
Setzt die technischen Leitplanken, baut aber nicht selbst (das tun Entwicklungsteams und Plattform-Engineering). Sicherheitsfreigaben liegen bei der Sicherheitsverantwortung für KI.
Typische Besetzung
Leitung Enterprise-Architektur bzw. Lead Architect mit KI-Erfahrung.
FinOps-Leitung für KI
Feld
Beschreibung
Was die Rolle ist
Die Rolle für die finanzielle Steuerung der KI-Landschaft. FinOps (kurz für Financial Operations) bezeichnet die Praxis, laufende Cloud- und KI-Kosten fortlaufend sichtbar zu machen und gemeinsam mit den Fachbereichen zu steuern, statt sie erst nachträglich in der Abrechnung zu entdecken. Hier übertragen auf KI-typische Kosten wie Token-Kosten (die Abrechnung je verarbeiteter Texteinheit) und Trainingskosten.
Warum es sie braucht
KI-Kosten sind nutzungsgetrieben und schwer vorhersagbar: Jede Anfrage kostet, und die Summe wächst mit der Nutzung. Ohne laufende Kostentransparenz entgleisen Budgets unbemerkt (siehe Kapitel D2).
Kernaufgaben
Schafft Kostentransparenz je Anwendungsfall, definiert Einheitenkennzahlen (etwa Kosten pro Anfrage), plant Budgets und Prognosen und etabliert Showback oder Chargeback: Showback zeigt jedem Bereich seine verursachten Kosten, Chargeback belastet sie ihm tatsächlich weiter.
Abgrenzung
Steuert die Kosten, entscheidet aber nicht über die Priorisierung des Portfolios (Portfolio Board) und nicht über die Service-Level einzelner Anwendungen (Service Owner KI).
Typische Besetzung
Controller:in oder Cloud-FinOps-Verantwortliche mit KI-Bezug; in kleineren Unternehmen eine Teilaufgabe des IT-Controllings.
Prozess- und Change-Management
Feld
Beschreibung
Was die Rolle ist
Eine Rolle oder ein Team für die organisatorische Seite der KI-Einführung: veränderte Abläufe, veränderte Rollen und die begleitende Kommunikation. Change-Management meint das strukturierte Begleiten von Veränderungen, damit die Betroffenen mitgehen statt zu blockieren.
Warum es sie braucht
KI-Vorhaben tragen nur, wenn neben der Technik auch Akzeptanz und Prozessänderungen geklärt sind (siehe Kapitel B11).
Kernaufgaben
Analysiert die Auswirkungen auf Abläufe und Rollen, plant Kommunikations- und Schulungsmaßnahmen, begleitet die Einführung in den Fachbereichen und misst die Akzeptanz.
Abgrenzung
Verantwortet die Veränderung der Organisation. Die fachliche Vermittlung von KI-Kompetenzen liegt beim Trainings- und Enablement-Team, das einzelne Produkt beim Product Owner KI.
Typische Besetzung
Change-Management aus HR oder Organisationsentwicklung, eng verzahnt mit dem KI-Kompetenzzentrum.
Daten und Governance
Data Owner je Domäne
Feld
Beschreibung
Was die Rolle ist
Eine fachliche Führungskraft, die die Eigentümerverantwortung für die Datenbestände einer Domäne trägt (einer Domäne, also eines fachlichen Bereichs wie Kundendaten oder Produktionsdaten). Eine Fachrolle, keine IT-Rolle: Es geht um die inhaltliche Hoheit über die Daten, nicht um deren technischen Betrieb.
Warum es sie braucht
Ohne benannten Eigentümer bleibt bei Datenfragen unklar, wer Zugriffe erlauben und Qualität einfordern darf. Datenanfragen stauen sich und Projekte verzögern sich, weil niemand entscheiden darf.
Kernaufgaben
Entscheidet über Zugriffe und Freigaben, legt Qualitätsziele fest, definiert die Zweckbindung (wofür die Daten genutzt werden dürfen und wofür nicht) und vertritt die Domäne gegenüber Compliance und Datenschutz.
Abgrenzung
Entscheidet, setzt aber nicht selbst um (das tut der Data Steward). Prüft keine Rechtsgrundlagen (Datenschutzbeauftragte:r).
Typische Besetzung
Eine Führungskraft des Fachbereichs, dem die Daten fachlich gehören. Nicht an die IT delegierbar, weil die fachliche Bewertung dort nicht liegt.
Data Steward je Domäne
Feld
Beschreibung
Was die Rolle ist
Die operative Datenrolle, die die Vorgaben des Data Owners im Alltag umsetzt. Steward heißt Verwalter: Wo der Data Owner entscheidet, führt der Steward aus und hält die Daten in Ordnung.
Warum es sie braucht
Qualitätsregeln und Datenkataloge pflegen sich nicht von selbst. Ohne Steward veralten die Metadaten (die beschreibenden Angaben zu den Daten, etwa Herkunft und Bedeutung) und die Datenqualität sinkt schleichend.
Kernaufgaben
Setzt die Qualitätsregeln um, pflegt Datenkatalog, Metadaten und Klassifizierung (die Einstufung nach Sensitivität), bearbeitet Zugriffs- und Qualitätsanfragen und meldet Probleme an den Data Owner.
Abgrenzung
Setzt um, entscheidet aber nicht über Freigaben und Zweckbindung (das bleibt beim Data Owner).
Typische Besetzung
Eine erfahrene Fachkraft der Domäne mit Datenaffinität, oft in Teilzeit neben der eigentlichen Linienaufgabe.
Datenschutzbeauftragte:r
Feld
Beschreibung
Was die Rolle ist
Eine gesetzlich vorgeschriebene Rolle nach DSGVO, hier um KI-spezifische Prüfungen erweitert. Sie wacht darüber, dass personenbezogene Daten rechtmäßig verarbeitet werden.
Warum es sie braucht
KI-Systeme verarbeiten personenbezogene Daten oft in neuen Zusammenhängen. Ohne frühe Einbindung drohen Bußgelder und teure Nacharbeiten kurz vor der Produktivsetzung.
Kernaufgaben
Prüft Rechtsgrundlagen, Einwilligungen, Speicherfristen und Betroffenenrechte, begleitet Datenschutz-Folgenabschätzungen (die vorgeschriebene Risikoprüfung bei heiklen Verarbeitungen, kurz DSFA) und berät Product Owner und Data Owner früh im Vorhaben.
Abgrenzung
Prüft den Datenschutz, nicht die gesamte Regulatorik (Compliance und Recht) und nicht ethische Fragen jenseits des Rechts (Responsible AI).
Typische Besetzung
Der oder die bestellte Datenschutzbeauftragte des Unternehmens, intern oder extern.
Responsible AI Officer / Ethikgremium
Feld
Beschreibung
Was die Rolle ist
Eine Rolle oder ein Gremium für die verantwortungsvolle Gestaltung von KI jenseits der gesetzlichen Mindestanforderungen. Responsible AI (verantwortungsvolle KI) fragt nicht nur, was erlaubt ist, sondern was vertretbar ist.
Warum es sie braucht
Das Recht definiert nur die Untergrenze. Fragen der Fairness, Transparenz und menschlichen Aufsicht entscheiden über das Vertrauen von Kunden und Belegschaft (siehe Kapitel B10).
Kernaufgaben
Erstellt Leitlinien zu Fairness, Erklärbarkeit und Transparenz, verlangt vor Freigaben eine Verzerrungsbewertung (die Prüfung, ob ein Modell bestimmte Gruppen systematisch benachteiligt), definiert Einsatzgrenzen und eskaliert kritische Fälle.
Abgrenzung
Bewertet die ethische Vertretbarkeit, nicht die rechtliche Zulässigkeit (Compliance, Datenschutz) und nicht die statistischen Modellrisiken (Model Risk Management).
Typische Besetzung
Eine einzelne benannte Rolle in kleineren Organisationen, ein interdisziplinäres Gremium in größeren.
Compliance und Recht
Feld
Beschreibung
Was die Rolle ist
Die bestehende Compliance- und Rechtsfunktion, erweitert um KI-Regulatorik. Compliance meint die Einhaltung von Gesetzen und Vorgaben und den prüffesten Nachweis darüber.
Warum es sie braucht
EU AI Act, DSGVO und Branchenvorgaben verlangen Nachweise und Freigaben. Verstöße gefährden Zulassung, Budget und Reputation (siehe Kapitel B8).
Kernaufgaben
Bewertet Vorhaben regulatorisch (unter anderem die Risikoklasse nach EU AI Act), verantwortet die Verträge mit Anbietern, führt die Audit-Nachweise (die prüffesten Belege für Kontrollen) und klärt Haftungsfragen.
Abgrenzung
Prüft die Rechtskonformität insgesamt. Der Datenschutz im engeren Sinn liegt bei den Datenschutzbeauftragten, technische Schutzmaßnahmen bei der Sicherheitsverantwortung für KI.
Typische Besetzung
Die Compliance- und Rechtsabteilung, bei Bedarf ergänzt um externe Kanzleien mit KI-Schwerpunkt.
Entwicklung und Plattform
Product Owner KI je Anwendungsfall
Feld
Beschreibung
Was die Rolle ist
Die fachliche Produktverantwortung für einen einzelnen KI-Anwendungsfall. Der Begriff stammt aus der agilen Entwicklung: Der Product Owner ist die eine Person, die entscheidet, was gebaut wird und in welcher Reihenfolge, und die den Nutzen gegenüber dem Geschäft verantwortet.
Warum es sie braucht
Ohne fachlichen Eigentümer optimiert das Entwicklungsteam am tatsächlichen Bedarf vorbei, und niemand misst, ob die Lösung ihr Geschäftsziel erreicht.
Kernaufgaben
Formuliert Vision und Ziele, übersetzt Geschäftsziele in Anforderungen, priorisiert das Backlog (die geordnete Liste der offenen Aufgaben), nimmt Ergebnisse ab und misst die Wirkung gegen die Baseline (den vorher gemessenen Ausgangswert ohne KI).
Abgrenzung
Verantwortet das Produkt bis zur Produktivsetzung, danach übernimmt der Service Owner KI den Betrieb. Entscheidet nicht über Datenfreigaben (Data Owner).
Typische Besetzung
Eine Person aus dem Fachbereich, der den Nutzen erhält. Keine IT-Rolle.
Business Analyst:in
Feld
Beschreibung
Was die Rolle ist
Eine Analyserolle an der Schnittstelle zwischen Fachbereich und Entwicklungsteam. Sie übersetzt zwischen beiden Welten: fachliche Abläufe in präzise Anforderungen und technische Möglichkeiten zurück in den Fachkontext.
Warum es sie braucht
KI-Lösungen brauchen genau beschriebene Prozesse und messbare Ausgangswerte. Ohne eine Baseline (den gemessenen Zustand vor der Einführung) lässt sich der Nutzen später nicht belegen (siehe Kapitel D1).
Kernaufgaben
Analysiert und dokumentiert die Ist-Prozesse, definiert Kennzahlen und erhebt Baselines, unterstützt den Product Owner bei Anforderungen und der Wirtschaftlichkeitsrechnung.
Abgrenzung
Analysiert Prozesse und Kennzahlen, entwickelt aber keine Modelle (Data Scientist) und priorisiert nicht das Backlog (Product Owner KI).
Typische Besetzung
Business Analyst:in aus dem Fachbereich oder einem IT-nahen Analyseteam.
Data Engineer
Feld
Beschreibung
Was die Rolle ist
Eine Ingenieurrolle für die Datenbereitstellung. Sie baut die Strecke von den Quellsystemen bis zu den aufbereiteten Daten, mit denen Modelle trainiert und betrieben werden, vergleichbar mit dem Bau und Betrieb der Leitungen, bevor jemand den Hahn aufdreht.
Warum es sie braucht
Erfahrungsgemäß steckt ein großer Teil des Aufwands in KI-Projekten in Datenbeschaffung und -aufbereitung. Schlechte Datenstrecken (Pipelines) sind die häufigste technische Ursache für Verzögerungen.
Kernaufgaben
Beschafft und modelliert Daten, baut und betreibt Pipelines (die automatisierten Verarbeitungsstrecken), sichert Datenqualität und die Nachvollziehbarkeit der Herkunft (Lineage, die lückenlose Datenspur) und stellt Daten für Training und Inferenz (den produktiven Modellbetrieb) bereit.
Abgrenzung
Liefert die Daten, entwickelt aber keine Modelle (Data Scientist) und baut keine Modell-Pipelines (Machine Learning Engineer).
Typische Besetzung
Software-Engineering mit Schwerpunkt Daten, meist im Plattform- oder Datenteam.
Machine Learning Engineer
Feld
Beschreibung
Was die Rolle ist
Eine Ingenieurrolle, die Modelle produktionsreif macht. Sie verbindet Data Science mit Software-Engineering und Betrieb, kurz MLOps bzw. LLMOps: die Praxis, Modelle zuverlässig, wiederholbar und überwacht in Betrieb zu bringen, so wie es DevOps für klassische Software tut.
Warum es sie braucht
Ein Modell im Notebook (der Experimentierumgebung eines Data Scientist) ist noch kein Produkt. Ohne reproduzierbare Pipelines, Tests und Versionierung bleibt jede Lösung im Pilotstadium stecken (siehe Kapitel C3).
Kernaufgaben
Baut die Trainings- und Inferenz-Pipelines, sorgt für Reproduzierbarkeit, Versionierung und automatisierte Tests und stellt Modelle bereit und aktualisiert sie.
Abgrenzung
Industrialisiert die Modelle, entwirft sie aber nicht (Data Scientist) und betreibt nicht die darunterliegende Plattform (Plattform-Engineering).
Typische Besetzung
Software-Engineering mit ML-Erfahrung; wird oft mit dem Data Engineering in einem Team gebündelt.
Data Scientist
Feld
Beschreibung
Was die Rolle ist
Die Methodenrolle für die Modellentwicklung, von der Auswahl des Verfahrens bis zur Bewertung der Ergebnisse. Sie beantwortet, mit welchem Ansatz sich ein Problem am besten lösen lässt und wie gut die Lösung wirklich ist.
Warum es sie braucht
Die Wahl von Verfahren, Merkmalen und Bewertungsmaßstäben entscheidet über Qualität und Belastbarkeit der Lösung. Das erfordert statistische und methodische Expertise.
Kernaufgaben
Entwickelt und vergleicht Modelle, wählt das Verfahren, bewertet die Ergebnisse gegen Baselines, dokumentiert in Modellkarten (den standardisierten Steckbriefen eines Modells) und unterstützt die Interpretation im Fachkontext.
Abgrenzung
Entwickelt die Modelle, verantwortet aber weder deren produktiven Betrieb (Machine Learning Engineer, Service Owner KI) noch die Datenbereitstellung (Data Engineer).
Typische Besetzung
Data Scientist mit Statistik- oder ML-Hintergrund; bei GenAI-Lösungen zunehmend mit Prompt- und Evaluationsexpertise.
Plattform-Engineering
Feld
Beschreibung
Was die Rolle ist
Das Team, das die gemeinsame Daten- und KI-Plattform bereitstellt und betreibt, auf der alle Anwendungsfälle aufsetzen. Es liefert die geteilte Grundausstattung, damit nicht jedes Projekt sie neu beschafft.
Warum es sie braucht
Ohne gemeinsame Plattform baut jedes Projekt seine eigene Infrastruktur. Kosten, Sicherheit und Betrieb werden dann unbeherrschbar.
Kernaufgaben
Stellt Umgebungen und Rechenkapazität bereit, betreibt Observability (die laufende Beobachtung des Systemzustands über Kennzahlen, Protokolle und Ablaufverfolgung) und Automatisierung und liefert Wiederverwendungsbausteine wie Modellzugänge und Vektordatenbanken (spezielle Speicher, die Texte nach Bedeutung durchsuchbar machen und die RAG-Suche tragen); unterstützt Teams beim Onboarding.
Abgrenzung
Betreibt die Plattform, nicht die einzelnen Anwendungen darauf (Service Owner KI). Entwickelt keine Modelle.
Typische Besetzung
Das Plattform- oder Infrastrukturteam der IT, erweitert um KI-Komponenten.
Sicherheitsverantwortung für KI
Feld
Beschreibung
Was die Rolle ist
Eine Sicherheitsrolle mit Fokus auf KI-spezifische Bedrohungen, meist als Erweiterung der bestehenden Informationssicherheit.
Warum es sie braucht
KI bringt Angriffsflächen mit, die die klassische IT-Sicherheit nicht abdeckt: Prompt Injection (untergeschobene Anweisungen in der Eingabe, die das Modell kapern), Datenabfluss über Modelle und Data Poisoning (das gezielte Vergiften der Trainingsdaten), siehe Kapitel B9.
Kernaufgaben
Erstellt Bedrohungsmodelle für KI-Systeme, definiert Schutzmaßnahmen und Zugriffskontrollen, erteilt Sicherheitsfreigaben und pflegt Prüfpfade und Reaktionspläne.
Abgrenzung
Verantwortet die technische Sicherheit. Regulatorische Freigaben liegen bei Compliance und Recht, ethische Einsatzgrenzen bei Responsible AI.
Typische Besetzung
Das Security-Team bzw. die CISO-Organisation (Leitung Informationssicherheit) mit KI-Weiterbildung.
Betrieb und Weiterentwicklung
Service Owner KI
Feld
Beschreibung
Was die Rolle ist
Die verantwortliche Rolle für eine produktive KI-Anwendung über ihren gesamten Betriebszeitraum. Sie ist der dauerhafte Eigentümer im Betrieb, dort wo die Projektrolle des Product Owners endet.
Warum es sie braucht
Nach der Produktivsetzung endet die Projektlogik. Ohne Service Owner verwaist die Anwendung: Kosten und Qualität geraten außer Kontrolle, weil sich niemand dauerhaft zuständig fühlt.
Kernaufgaben
Verantwortet Verfügbarkeit, Service-Level (die zugesagten Leistungswerte wie Antwortzeit und Erreichbarkeit), Kosten, Sicherheit und Qualität im Betrieb, beauftragt Weiterentwicklungen und entscheidet über die Stilllegung gemeinsam mit dem Product Owner KI.
Abgrenzung
Übernimmt nach der Produktivsetzung vom Product Owner KI. Die technische Überwachung führt das Site Reliability Engineering aus.
Typische Besetzung
IT-Service-Management oder Betriebsorganisation; in kleineren Unternehmen in Personalunion mit dem Product Owner KI.
Site Reliability Engineering
Feld
Beschreibung
Was die Rolle ist
Die Betriebsrolle für Stabilität und Leistung der produktiven KI-Systeme. Site Reliability Engineering (SRE) ist eine ursprünglich bei Google entstandene Arbeitsweise, den IT-Betrieb wie eine Ingenieurdisziplin zu führen: Zuverlässigkeit (Verfügbarkeit und Antwortzeiten) wird als messbares Ziel festgelegt, und wiederkehrende Betriebsarbeit wird durch Automatisierung ersetzt, statt Störungen dauerhaft von Hand nachzulaufen.
Warum es sie braucht
KI-Systeme fallen anders aus als klassische Software, etwa durch schleichende Qualitätsverschlechterung (Drift, das Abdriften der Modellgüte, wenn sich die Realität verschiebt) oder plötzliche Lastspitzen bei der Inferenz. Das erfordert eine spezialisierte, kontinuierliche Überwachung.
Kernaufgaben
Baut Überwachung und Alarmierung auf, definiert Wiederanlaufverfahren für den Störungsfall, analysiert Vorfälle systematisch und optimiert Stabilität und Antwortzeiten.
Abgrenzung
Sichert den technischen Betrieb, verantwortet aber nicht die Service-Level und Kosten gegenüber dem Fachbereich (das tut der Service Owner KI).
Typische Besetzung
Das Betriebs- bzw. SRE-Team der IT.
Support-Stufen
Feld
Beschreibung
Was die Rolle ist
Eine gestaffelte Unterstützungsorganisation für Anwenderfragen und technische Vorfälle, aufgebaut in mehreren Stufen (englisch Level) mit steigender Fachtiefe.
Warum es sie braucht
Ohne klaren Support-Weg landen alle Fragen direkt beim Entwicklungsteam und blockieren dessen Weiterentwicklung.
Kernaufgaben
Die 1. Stufe beantwortet einfache Anwenderfragen, die 2. Stufe bearbeitet technische Vorfälle, die 3. Stufe führt die Ursachenanalyse gemeinsam mit der Entwicklung durch.
Abgrenzung
Bearbeitet Vorfälle und Fragen. Systematische Qualitätsprobleme eskaliert der Support an den Service Owner KI und das Model Risk Management.
Typische Besetzung
Die bestehende Support-Organisation, die 1. Stufe mit KI-Grundschulung.
Model Risk Management
Feld
Beschreibung
Was die Rolle ist
Eine unabhängige Prüfinstanz für Modellrisiken. In regulierten Branchen (Banken, Versicherer) ist sie etabliert und wird von der Aufsicht erwartet. Unabhängig heißt hier: nicht dem Team unterstellt, das das Modell gebaut hat.
Warum es sie braucht
Wer entwickelt, prüft nicht sich selbst. Eine unabhängige Instanz erkennt Schwächen, die dem eigenen Team unter Erfolgsdruck entgehen.
Kernaufgaben
Prüft Modelle vor der Freigabe und im laufenden Betrieb (Genauigkeit, Drift, Fairness, Einsatzgrenzen), fordert Gegenmaßnahmen und kann die Rücknahme eines Modells aus der Produktion verlangen.
Abgrenzung
Prüft die statistisch-fachlichen Modellrisiken. Die rechtliche Prüfung liegt bei Compliance und Recht, die ethische Bewertung bei Responsible AI, die technische Sicherheit bei der Sicherheitsverantwortung für KI.
Typische Besetzung
Eine unabhängige Risikofunktion; in kleineren Unternehmen mindestens eine fachkundige, nicht am Vorhaben beteiligte Person.
Trainings- und Enablement-Team
Feld
Beschreibung
Was die Rolle ist
Das Team für den KI-Kompetenzaufbau in der gesamten Organisation. Enablement (Befähigung) bedeutet, Mitarbeitende in die Lage zu versetzen, KI-Werkzeuge sicher und sinnvoll zu nutzen.
Warum es sie braucht
AI Literacy (grundlegende KI-Kompetenz) ist Pflicht (Art. 4 EU AI Act) und Voraussetzung für Akzeptanz. Ohne systematische Befähigung bleiben Werkzeuge ungenutzt oder werden falsch genutzt (siehe Kapitel B11).
Kernaufgaben
Entwickelt und hält Schulungen, pflegt Leitfäden und Selbstlernangebote, baut Communities of Practice (fachliche Austauschgruppen über Bereichsgrenzen hinweg) auf und misst den Lernfortschritt.
Abgrenzung
Vermittelt die Kompetenzen. Die organisatorische Veränderung selbst steuert das Prozess- und Change-Management.
Typische Besetzung
Die Personalentwicklung gemeinsam mit dem KI-Kompetenzzentrum.
Entscheidungsrechte im KI-Lebenszyklus
Entscheidungen fallen dort, wo Verantwortung und Fachwissen liegen: strategische Richtung in Gremien (Portfolio Board, Unternehmensleitung), operative Entscheidungen bei Product, Data und Service Owner. Sicherheits- und Compliance-Freigaben erfolgen stets unabhängig von Entwicklung und Betrieb. Die Tabelle ist exemplarisch und je nach Organisation anzupassen.
Rolle
Typische Entscheidungsrechte
Zusammenarbeit
Vorstandspat:in KI
Priorität und Budget freigeben, Zielkonflikte klären
Chief AI Officer, Portfolio Board
Chief AI Officer / CIO
Strategie, Prinzipien, Zielarchitektur, Roadmap
Enterprise-Architektur, FinOps, Fachbereiche
Portfolio Board KI
Aufnahme, Priorisierung, Beendigung von Projekten
Product Owner, AI-Programmleitung
Product Owner KI
Anforderungen, Backlog, Ergebnisfreigabe
Data Scientist, Data Engineer, Business Analyst:in
Data Owner
Datenzugriffe, Qualitätsziele, Zweckbindung
Data Steward, Compliance, Datenschutz
Data Scientist
Wahl der Verfahren, Modellentwurf und -bewertung
ML Engineer, Product Owner
ML Engineer
Trainings- und Inferenzpipelines, Deployment
Plattform-Engineering
Enterprise-Architektur
Technische Passung und Schnittstellen freigeben
Chief AI Officer, Security
Sicherheitsverantwortung KI
Sicherheitsfreigaben, Schutzmaßnahmen
Compliance, Plattform-Engineering
Responsible AI / Ethik
Fairness, Transparenz, Einsatzgrenzen
Product Owner, Portfolio Board
Compliance / Recht
Regulatorische Freigaben (DSGVO, AI Act)
Security, Responsible AI
Service Owner KI
Betrieb, Service-Level, Kosten, Verfügbarkeit
SRE, FinOps, Product Owner
FinOps-Leitung KI
Budgetfreigaben, Kostencontrolling, Prognosen
Portfolio Board, Service Owner
Vorlage: RACI je Anwendungsfall
Pro Aufgabe genau ein A (Accountable); R, C und I nach Bedarf. R = Responsible (führt aus), A = Accountable (entscheidet und verantwortet), C = Consulted (wird gefragt), I = Informed (wird informiert).
Die Tabelle ist bewusst ein Ausschnitt: Sie enthält die sechs Rollen, die an praktisch jedem Anwendungsfall beteiligt sind, und die Aufgaben mit dem größten Konfliktpotenzial. Je nach Vorhaben werden weitere Rollen aus der Rollenlandkarte als Spalten ergänzt (etwa Machine Learning Engineer, Responsible AI oder Datenschutzbeauftragte:r) und weitere Aufgaben als Zeilen.
Aufgabe
Product Owner
Data Owner
Data Scientist
Security
Compliance
Service Owner
Datenfreigabe
C
A
C
C
C
I
Modellentwicklung
A
I
R
C
I
I
Sicherheitsfreigabe
C
I
I
A
C
I
Regulatorische Freigabe
C
C
I
C
A
I
Produktivsetzung
A
I
C
C
C
R
Betrieb / Monitoring
I
I
C
C
I
A
Vorlage: Rollensteckbrief
Der Rollensteckbrief wird einmal je Rolle ausgefüllt und zentral abgelegt. Er verhindert, dass Verantwortung nur mündlich existiert, und macht Vertretungen und Übergaben überhaupt erst möglich: Eine neue Person kann die Rolle anhand des Steckbriefs übernehmen, ohne auf mündliche Überlieferung angewiesen zu sein.
Feld
Inhalt
Rolle
Bezeichnung
Ziel
Wofür steht die Rolle?
Kernaufgaben
3 bis 5 Hauptaufgaben
Entscheidungsrechte
Was darf die Rolle allein entscheiden?
Schnittstellen
Wichtigste Zusammenarbeit
Lieferartefakte
Welche Artefakte liefert die Rolle verbindlich? Beispiele: Modellkarte vom Data Scientist, Kostenbericht von der FinOps-Leitung, Freigabenachweis von Compliance. Die Artefakte je Rolle greift der folgende Abschnitt auf.
Kennzahlen
2 bis 3 Erfolgsindikatoren (Vorschläge im Abschnitt Kennzahlen je Rolle)
Vertretung
Wer vertritt im Abwesenheitsfall?
Arbeitsartefakte, Rhythmen und Gremien
Rollen bleiben Papier, wenn sie nichts Greifbares liefern und sich nie treffen. Dieser Abschnitt legt deshalb fest, welche Ergebnisse die Rollen produzieren (Artefakte, siehe Feld Lieferartefakte im Rollensteckbrief) und in welchem Takt sie zusammenkommen (Rhythmen und Gremien). Jede Rolle liefert verbindliche Artefakte: Rollensteckbrief, RACI je Anwendungsfall, Modell- und Datenkarten, Evaluations- und Freigabenachweise, Sicherheits- und Datenschutzdokumente, Serviceziele und Kostenberichte. Verankert wird das in festen Rhythmen: wöchentliche Statusrunden pro Produkt, zweiwöchentliche Architektur- und Sicherheitsprüfung, monatliches Portfolio-Review, vierteljährliche Überprüfung von Zielarchitektur und Leitlinien, jährliche Wirksamkeitsprüfung der Governance.
Segregation of Duties
Die Grundsätze am Kapitelanfang fordern getrennte Verantwortlichkeiten; dieser Abschnitt macht die Trennung konkret. Segregation of Duties (Aufgabentrennung) bedeutet: Bestimmte Rollen dürfen nie in einer Person oder einem Team zusammenfallen, weil sonst Interessenkonflikte entstehen, etwa wenn ein Team das eigene Modell freigibt, an dem sein Erfolg gemessen wird. Saubere Aufgabentrennung vermeidet diese Konflikte und erfüllt zugleich Compliance-Anforderungen.
Entwicklung und Freigabe sind getrennt; eine unabhängige Instanz prüft Qualität und Risiko.
Betrieb und Audit sind getrennt; Prüfungen erfolgen neutral.
Datenfreigaben steuern Data Owner, nicht die Entwickelnden selbst.
Produktivzugriffe sind streng begrenzt, rollenbasiert und vollständig protokolliert.
Kennzahlen je Rolle
Rollen wirken nur, wenn ihr Erfolg messbar ist. Dieser Abschnitt schlägt je Rolle wenige Kennzahlen vor; sie gehören in das Feld Kennzahlen des Rollensteckbriefs und in das Reporting (Kapitel D4). Mehr als zwei bis drei Kennzahlen je Rolle verwässern die Steuerungswirkung.
Product Owner: Zielbeitrag, Nutzungsrate, Zufriedenheit, Zeit- und Budgettreue.
Data Owner: Datenqualität und -aktualität, Freigabegeschwindigkeit, Regelverstöße.
Data Scientist: Modellgüte, Stabilität über Szenarien, Nutzen gegen Baseline.
Responsible AI: Fairness-Indikatoren, Erklärbarkeit, Erfüllung von Auflagen.
FinOps: Kosten pro Anfrage, Training und Produkt, Prognosegenauigkeit.
Skalierung je Unternehmensgröße
Die Rollenlandkarte beschreibt Funktionen, nicht Stellen: Nicht jede Rolle braucht eine eigene Person. Dieser Abschnitt zeigt, wie dieselben Verantwortlichkeiten je nach Unternehmensgröße besetzt werden, ohne dass die Aufgabentrennung verloren geht.
Verantwortungsbereich
Bis ~50 Mitarbeitende
~50 bis 250
Ab ~250
Strategie, Priorisierung, Budget
Geschäftsführung in Personalunion, ein monatlicher Steuerungstermin
Ein KI-Verantwortlicher plus kleines Portfolio Board
Vorstandspat:in, Chief AI Officer, Portfolio Board
Produktverantwortung je Anwendungsfall
Eine Person aus dem Fachbereich, oft in Teilzeit
Dedizierte Product Owner
Product Owner plus Business-Analyse
Daten (Owner, Engineering, Data Science)
Eine datenkundige Person, extern ergänzt
Kleines Datenteam
Getrennte Rollen
Technik und Betrieb
Bestehende IT plus Partner
ML- und Plattformaufgaben als ein Team
Dedizierte Plattform- und Betriebsteams
Sicherheit, Compliance, Datenschutz
Bestehende Rollen, Freigabe bleibt getrennt vom Bauen
Teilzeit-Rollen mit unabhängiger Freigabe
Unabhängige Funktionen inkl. Model Risk Management und Revision
Befähigung und FinOps
In Personalentwicklung und Controlling integriert
Benannte Teilzeit-Rollen
Eigene Rollen
Eine Grenze gilt unabhängig von der Größe: Wer ein Modell baut, gibt es nicht selbst frei. Sicherheits- und Compliance-Freigaben bleiben auch bei starker Bündelung von Entwicklung und Betrieb getrennt (siehe Abschnitt Segregation of Duties).
Kleinere Organisationen: Rollen werden gebündelt (Product Owner übernimmt Business-Analyse; Data Engineer und ML Engineer als ein Team). Governance bleibt schlank: klare Leitplanken, kurze Templates, wenige Pflichtprüfungen mit schneller Rückmeldung. Ein kleiner Satz verbindlicher Standards (Benennung, Versionierung, Modellkarten, Freigabenachweise, einfache Kostenübersicht) genügt. Entscheidend ist konsequente Einhaltung.
Große Organisationen: dedizierte Teams für Plattform, Sicherheit, Responsible AI, FinOps, Datenmanagement, Betrieb. Abgestufte Gremien (Portfolio, Architektur/Sicherheit, Betrieb), Communities of Practice, gemeinsame Plattformen und unabhängige Rollen für Model Risk Management, Compliance, Datenschutz, interne Revision.
Checkliste: praktische Einführung
Die Checkliste führt durch die Einführung der Rollen, von der Landkarte bis zum laufenden Nachsteuern:
Rollensteckbrief je Rolle ausgefüllt und zentral abgelegt, inklusive Vertretung und Lieferartefakten
Entscheidungsrechte je Rolle zugeordnet; Sicherheits- und Compliance-Freigaben unabhängig von Entwicklung und Betrieb
RACI je Anwendungsfall gepflegt und in jedem Meilenstein geprüft, mit genau einem A je Aufgabe
Aufgabentrennung umgesetzt: Entwicklung getrennt von Freigabe, Betrieb getrennt von Audit, Datenfreigaben beim Data Owner, Produktivzugriffe begrenzt und protokolliert
Gremien mit klaren Mandaten und Sitzungstakten eingesetzt
