Unklare Zuständigkeiten sind in KI-Projekten ein stiller Kostentreiber: Anforderungen werden mehrfach diskutiert, Risiken bleiben liegen, Freigaben dauern und im Ernstfall fühlt sich niemand verantwortlich. Ein sauber definiertes Rollenmodell reduziert Reibung, beschleunigt Entscheidungen und macht Risiken bearbeitbar. Besonders bei GenAI (z. B. Textassistenten, Chatbots oder interne Wissenssysteme) sind Rollen deshalb kein „Organigramm-Thema“, sondern ein Qualitäts- und Sicherheitsfaktor.
Praktisch bewährt hat sich eine RACI-Logik: Aufgaben werden so beschrieben, dass für jede Aufgabe klar ist, wer verantwortlich ausführt, wer am Ende rechenschaftspflichtig ist, wer konsultiert wird und wer informiert werden muss. Damit lässt sich auch in kleineren Teams eine robuste Struktur aufbauen, ohne Prozesse zu überfrachten.
RACI bei GenAI: Warum Rollen hier besonders zählen
GenAI verändert Arbeitsteilung und Risikooberflächen
GenAI verschiebt Tätigkeiten: Fachbereiche erstellen Inhalte schneller, Entwickler integrieren Modelle und Schnittstellen, Security bewertet neue Angriffswege, und Compliance prüft Datenflüsse. Gleichzeitig entstehen neue Risikooberflächen: sensible Informationen im Prompt, unklare Urheberrechte an Trainings- oder Kontextdaten, und nicht deterministische Ausgaben, die überprüft werden müssen.
Ein Rollenmodell sorgt dafür, dass diese Verschiebung nicht in Grauzonen endet. Es klärt, wer welche Kontrollen einführt, wer die Nutzung regelt und wer im Betrieb eingreift, wenn etwas aus dem Ruder läuft.
Typische Symptome fehlender Zuständigkeiten
- „Das prüfen wir später“: Qualitäts- und Sicherheitsfragen werden vertagt, bis sie teuer werden.
- Uneinheitliche Freigaben: Jeder Bereich entscheidet anders, was „ok“ ist.
- Operative Überlast: Ein Team (meist IT) wird zum Nadelöhr für alles.
- Kein Incident-Owner: Bei Fehlverhalten des Systems gibt es kein klares Playbook.
Rollen statt Titel: So werden Verantwortungen praktikabel
Rollenschnitt nach Aufgaben, nicht nach Hierarchie
In der Praxis funktionieren Rollen am besten, wenn sie an Aufgabenpakete gekoppelt sind. Ein und dieselbe Person kann mehrere Rollen innehaben (z. B. in KMU), aber die Verantwortungslogik bleibt stabil. Sinnvoll ist außerdem eine Trennung zwischen „Produktverantwortung“ (Nutzen, Anforderungen, Entscheidung) und „Betriebsverantwortung“ (Stabilität, Sicherheit, Monitoring).
Empfohlene Kernrollen in GenAI-Teams
- Product Owner GenAI: priorisiert Use-Cases, verantwortet Zielbild, Abnahme und Nutzen.
- Model/Platform Engineer: integriert Modelle, baut Schnittstellen, setzt technische Kontrollen um.
- Data Steward: klärt Datenherkunft, Qualität, Zugriffsregeln und Pflege von Wissensquellen.
- Security & Risk: bewertet Bedrohungen, setzt Security-Reviews und Incident-Prozesse auf.
- Legal/Compliance: prüft vertragliche, urheberrechtliche und datenschutzbezogene Anforderungen.
- Fachliche Reviewer: prüfen Domänenrichtigkeit (z. B. HR, Finance, Support).
- Operations/Support: betreibt, triagiert Tickets, koordiniert Störungen.
Wichtig: Rollen sollten nicht „mitdenken müssen“, was gemeint ist. Je klarer Aufgaben und Grenzen formuliert sind, desto weniger wird RACI zur Folie ohne Wirkung.
Aufgabenlandkarte: Wo RACI in GenAI wirklich hilft
Entwicklung: Von Idee bis Abnahme
Schon in der Pilotphase entstehen Entscheidungen, die später schwer zu ändern sind: Welche Datenquellen dürfen genutzt werden? Welche Ausgaben sind zulässig? Welche Qualitätsschwelle gilt für den Rollout? RACI zwingt dazu, diese Punkte als konkrete Aufgaben zu formulieren und einen Owner zu benennen.
Passend dazu kann der Prozess zur Anforderungspräzisierung schlank angedockt werden, etwa über KI-Use-Case Canvas – Anforderungen präzise dokumentieren, damit Rollen nicht an vagen „Wünschen“ arbeiten.
Betrieb: Qualität, Kosten, Sicherheit als laufende Verantwortung
GenAI ist kein „einmal live, immer fertig“. Prompts ändern sich, Datenquellen werden aktualisiert, Nutzer finden Abkürzungen, und Kosten schwanken je nach Nutzung. Deshalb sollten Aufgaben wie Monitoring, Ticket-Triage, Rollback-Entscheidungen und Zugriffspflege fest zugeordnet sein. Wer hier verantwortlich ist, ist keine Formalie, sondern reduziert Ausfallzeiten und Fehlentscheidungen.
Nutzung: Regeln, Schulung, Eskalation
Viele Risiken entstehen nicht im Code, sondern im Alltag: Mitarbeitende kopieren sensible Inhalte in Tools, interpretieren Antworten als Fakt oder umgehen Prozesse. Ein Rollenmodell sollte deshalb auch Verantwortungen für Enablement (Guidelines, Schulung) und Eskalation (Was tun bei falscher Antwort?) enthalten. Das ergänzt technische Schutzmaßnahmen sinnvoll.
Zuordnungstabelle für typische GenAI-Aufgaben
Die folgende Tabelle zeigt eine praxistaugliche Startzuordnung. Sie ist absichtlich „normalisiert“: wenige Rollen, klare Aufgaben, RACI ohne Nebenrollen-Explosion. Anpassungen sollten Use-Case-spezifisch erfolgen.
| Aufgabe | R (Responsible) | A (Accountable) | C (Consulted) | I (Informed) |
|---|---|---|---|---|
| Use-Case Ziel & Erfolgskriterien definieren | Product Owner GenAI | Product Owner GenAI | Fachbereich, Operations | Security, Compliance |
| Datenquellen auswählen und pflegen | Data Steward | Product Owner GenAI | Compliance, Security | Fachliche Reviewer |
| Prompt-/Template-Standards festlegen | Model/Platform Engineer | Product Owner GenAI | Fachliche Reviewer | Operations |
| Security-Review und Bedrohungsanalyse | Security & Risk | Security & Risk | Model/Platform Engineer | Product Owner GenAI |
| Datenschutz- und Compliance-Check | Legal/Compliance | Legal/Compliance | Data Steward | Product Owner GenAI |
| Abnahmetest fachliche Richtigkeit | Fachliche Reviewer | Product Owner GenAI | Model/Platform Engineer | Operations |
| Rollout-Entscheidung | Product Owner GenAI | Product Owner GenAI | Security, Compliance, Operations | Betroffene Teams |
| Monitoring von Qualität & Kosten im Betrieb | Operations | Operations | Model/Platform Engineer | Product Owner GenAI |
| Incident-Handling (Fehlausgaben, Datenabfluss) | Operations | Security & Risk | Legal/Compliance, Engineer | Product Owner GenAI |
Grenzfälle sauber lösen: typische Konflikte in der Praxis
Wer ist „Accountable“, wenn Fachbereich und IT getrennt sind?
Accountable sollte dort liegen, wo die Entscheidung über Nutzen und Risikoausgleich getroffen wird. Bei internen Assistenzsystemen ist das häufig der fachliche Owner (z. B. Leiter Kundenservice) in enger Abstimmung mit Security/Compliance. Die IT bleibt verantwortlich für Umsetzung und Betrieb, aber nicht für fachliche Freigaben von Inhalten.
Wie viele „Consulted“ sind sinnvoll?
Zu viele Konsultierte machen Entscheidungen langsam. Als Daumenregel: Nur Rollen konsultieren, die aktiv Anforderungen verändern oder ein Veto auf Basis klarer Kriterien besitzen (z. B. Datenschutz, Security). Alle anderen gehören in „Informed“ mit klar definiertem Informationsformat.
Was tun, wenn eine Person mehrere Rollen trägt?
In kleineren Organisationen ist das normal. Entscheidend ist, die Rollenhüte explizit zu machen: In einem Ticket oder Entscheidungsprotokoll steht dann z. B. „A: Product Owner, R: Engineer (gleiche Person)“. So bleibt nachvollziehbar, welche Verantwortung wahrgenommen wurde.
Praktische Einführung in wenigen Schritten
Eine RACI-Matrix wirkt erst, wenn sie in den Arbeitsfluss eingebaut wird: in Ticket-Templates, Freigabe-Checkpoints und Betriebsroutinen. Die folgenden Schritte sind bewusst schlank gehalten.
- Use-Case abgrenzen: Was ist im Scope, was nicht (z. B. interne Texte vs. externe Kundenkommunikation).
- Aufgabenliste erstellen: 15–30 konkrete Aufgaben über Entwicklung, Betrieb und Nutzung.
- Pro Aufgabe genau eine accountable Rolle festlegen; Verantwortliche für Umsetzung benennen.
- Eskalationswege definieren: Wer entscheidet bei Konflikten, wer stoppt im Notfall.
- In Workflows einbetten: RACI-Felder in Tickets, Review-Checkpoints in Definition-of-Done.
- Quartalsweise Review: Rollen/Zuordnung anpassen, wenn Use-Case oder Risiko sich verändert.
Mini-Fallbeispiel: GenAI im Kundenservice ohne Zuständigkeitslücken
Ausgangslage: Schnelle Antworten, aber hoher Qualitätsdruck
Ein Kundenservice-Team möchte Antwortvorschläge generieren lassen. Die Qualität muss hoch sein, weil falsche Zusagen Kosten verursachen. Gleichzeitig sind in Tickets personenbezogene Daten enthalten, die nicht unkontrolliert verarbeitet werden dürfen. Ohne Rollenmodell entstehen typische Reibungen: Wer darf Templates ändern? Wer prüft neue Antwortbausteine? Wer stoppt das System bei riskanten Mustern?
Umsetzung: Rollen mit klaren Abnahmepunkten
Der Product Owner GenAI verantwortet Erfolgskriterien (z. B. weniger Bearbeitungszeit, keine neuen Beschwerdearten). Fachliche Reviewer definieren zulässige Antwortmuster und Tabus. Security & Risk setzt Vorgaben für Datenhandling und Logging, Compliance prüft die zulässige Verarbeitung, Operations betreibt und überwacht. Der Engineer implementiert die Templates und Kontrollen. Ergebnis: Änderungen an Antwortvorlagen laufen über einen klaren Review, Incidents haben einen eindeutigen Owner, und das Team kann iterieren, ohne jedes Mal Grundsatzdebatten zu führen.
Entscheidungslogik für neue Aufgaben: wohin gehört was?
- Wenn eine Aufgabe Nutzen, Scope oder Risikoakzeptanz festlegt
- Dann liegt A typischerweise beim Product Owner GenAI.
- Wenn eine Aufgabe technische Umsetzung, Integrationen oder Laufzeitstabilität betrifft
- Dann liegt R beim Engineer, A häufig bei Operations oder Plattformverantwortung.
- Wenn eine Aufgabe Datenherkunft, Datenpflege oder Zugriffsregeln betrifft
- Dann liegt R beim Data Steward, C bei Compliance/Security.
- Wenn eine Aufgabe rechtliche Zulässigkeit oder Datenschutzanforderungen prüft
- Dann liegt A bei Legal/Compliance, nicht „irgendwo in der IT“.
Ein gutes RACI-Setup ist kein bürokratisches Artefakt, sondern eine Betriebsanleitung für Zusammenarbeit. Sobald klar ist, wer Verantwortlichkeiten trägt, können Teams schneller entscheiden, sauber dokumentieren und sicher skalieren.
