KI-Verantwortlichkeiten im Unternehmen festlegen

Ein KI-gestützter Assistent greift auf Vertriebsdaten zu, erstellt Angebotsentwürfe und wird nach einem erfolgreichen Pilotprojekt kurzfristig für weitere Teams geöffnet. Erst bei fehlerhaften Ergebnissen stellt sich die zentrale Frage: Wer entscheidet über Datenfreigaben, fachliche Grenzen, Änderungen und den Weiterbetrieb? KI-Verantwortlichkeiten im Unternehmen festlegen heißt, diese Fragen vor der Produktivsetzung verbindlich zu beantworten - nicht erst im Incident.

Warum KI-Projekte an unklaren Zuständigkeiten scheitern

In vielen Unternehmen beginnt KI als Fachbereichsinitiative, Technologieexperiment oder Erweiterung einer bestehenden Plattform. Das ist für die Erprobung sinnvoll, reicht aber für einen stabilen Betrieb nicht aus. Sobald ein System Entscheidungen vorbereitet, Inhalte erzeugt, Prozesse auslöst oder mit SAP-, CRM- und weiteren Unternehmensdaten verbunden wird, entstehen Verantwortlichkeiten über mehrere Bereiche hinweg.

Die IT kann einen sicheren technischen Betrieb gewährleisten, aber nicht allein beurteilen, ob ein Ergebnis fachlich angemessen ist. Der Fachbereich kennt den Prozess und die Entscheidungskriterien, verfügt jedoch häufig nicht über vollständige Transparenz zu Datenflüssen, Modellgrenzen oder Berechtigungen. Informationssicherheit, Datenschutz, Compliance, Einkauf und Betriebsrat können je nach Einsatzfall ebenfalls eingebunden sein. Ohne ein abgestimmtes Rollenmodell entstehen Freigaben im Einzelfall, Dokumentationen bleiben lückenhaft und Änderungen werden nicht nachvollziehbar gesteuert.

Entscheidend ist deshalb nicht, möglichst viele Gremien einzurichten. Benötigt wird ein Modell, das Entscheidungsrechte, Ausführungsverantwortung und Eskalationswege klar voneinander trennt. Eine benannte Person ist nur dann verantwortlich, wenn sie auch über die nötigen Informationen, Befugnisse und Ressourcen verfügt.

KI-Verantwortlichkeiten im Unternehmen festlegen: drei Ebenen trennen

Ein belastbares Rollenmodell unterscheidet mindestens die fachliche, die daten- und technologiebezogene sowie die betriebliche Verantwortung. Diese Ebenen können in kleineren Organisationen teilweise bei einer Person zusammenlaufen. Mit wachsender Kritikalität des Einsatzfalls sollten sie jedoch bewusst getrennt und gegenseitig kontrollierbar sein.

Fachliche Verantwortung für Zweck und Ergebnis

Der fachliche Use-Case-Owner verantwortet, warum ein KI-System eingesetzt wird und in welchem Prozess es arbeiten darf. Er definiert den zulässigen Anwendungsbereich, die fachlichen Qualitätskriterien und die Folgen fehlerhafter Ergebnisse. Bei einer Lösung zur Belegprüfung gehört dazu beispielsweise die Entscheidung, welche Fälle automatisiert vorqualifiziert werden dürfen und wann eine menschliche Prüfung zwingend bleibt.

Diese Rolle sollte auch messbare Zielgrößen festlegen. Dazu zählen Bearbeitungszeiten, Fehlerquoten, Nachbearbeitungsaufwand oder Akzeptanz im Fachbereich. Ohne solche Kriterien lässt sich nach einem Pilot nicht belastbar bewerten, ob der Nutzen den Betriebs- und Kontrollaufwand rechtfertigt.

Verantwortung für Daten, Architektur und Modellverhalten

Datenverantwortliche entscheiden nicht nur über die Freigabe eines Datenbestands. Sie müssen nachvollziehbar festlegen, welche Daten für den jeweiligen Zweck erforderlich sind, welche Qualitätsanforderungen gelten und wie Änderungen an Stammdaten, Schnittstellen oder Berechtigungen bewertet werden. Besonders in SAP-nahen Prozessen können unklare Datenherkunft und fehlende fachliche Definitionen zu Ergebnissen führen, die technisch korrekt wirken, aber operativ falsch eingeordnet werden.

Die technische Verantwortung umfasst Architektur, Schnittstellen, Zugriffssteuerung, Protokollierung und die Bewertung des eingesetzten Modells. Bei extern bezogenen Modellen oder Plattformdiensten gehört auch die Steuerung des Dienstleisters dazu. Einkauf und Vertragsverantwortliche benötigen hierfür klare technische Anforderungen, etwa zu Datenverarbeitung, Änderungsankündigungen, Support und Nachweisen.

Dabei sollte klar bleiben: Die technische Verantwortung ersetzt keine fachliche Freigabe. Umgekehrt darf ein Fachbereich kein System produktiv einsetzen, ohne dass Datenflüsse, Sicherheitsmaßnahmen und Betriebsprozesse geprüft sind.

Betriebsverantwortung für Änderungen und Störungen

Nach dem Go-Live beginnt der Teil, der in vielen Pilotprojekten unterbewertet bleibt. Wer überwacht Ergebnisqualität und Nutzung? Wer darf Prompts, Wissensquellen, Berechtigungen oder Schnittstellen ändern? Wer stoppt das System bei auffälligem Verhalten? Diese Aufgaben gehören in eine ausdrücklich benannte Betriebsverantwortung.

Sie organisiert Monitoring, Incident-Prozesse und regelmäßige Reviews. Für kritische Einsatzfälle sollte sie mit Testmanagement und Release-Steuerung verbunden sein. Werden KI-Komponenten in einen S/4HANA-Transformationsprozess integriert, müssen sie in Testzyklen, Cutover-Planung und Go-Live-Kriterien berücksichtigt werden. Eine produktive KI-Komponente darf nicht außerhalb etablierter Änderungsprozesse betrieben werden.

Entscheidungsrechte entlang des Lebenszyklus definieren

Ein Rollenmodell wird erst wirksam, wenn es an konkreten Entscheidungspunkten angewendet wird. Eine einfache RACI-Matrix kann dabei helfen, sie darf aber nicht bei abstrakten Tätigkeiten stehen bleiben. Relevant sind die Freigaben, die einen Use Case in die nächste Stufe bringen.

Für die meisten Unternehmensanwendungen sollten mindestens diese Entscheidungen dokumentiert sein:

• die fachliche Freigabe des Einsatzfalls inklusive Nutzen, Grenzen und menschlicher Kontrollpunkte,

• die Freigabe der verwendeten Datenquellen, Datenflüsse und Berechtigungen,

• die technische Freigabe von Architektur, Modellkonfiguration und Sicherheitsmaßnahmen,

• die Betriebsfreigabe vor der Produktivsetzung mit Testnachweisen, Monitoring und Eskalationsweg,

• die Entscheidung über wesentliche Änderungen, etwa neue Datenquellen, neue Nutzergruppen oder ein Modellwechsel.

Nicht jede Änderung braucht ein umfangreiches Gremium. Eine Anpassung an einer Hilfetextvorlage ist anders zu bewerten als die Anbindung zusätzlicher Personal-, Kunden- oder Produktionsdaten. Deshalb empfiehlt sich eine risikobasierte Änderungslogik. Sie legt fest, welche Anpassungen im regulären Betrieb zulässig sind, wann ein Fachbereich zustimmen muss und wann eine erneute technische oder regulatorische Prüfung erforderlich wird.

Governance in bestehende Projekt- und Betriebsstrukturen einbauen

Separate KI-Governance-Strukturen wirken auf den ersten Blick konsequent, führen in der Praxis aber häufig zu parallelen Freigabewegen. Sinnvoller ist es, vorhandene Strukturen gezielt zu erweitern: Architekturboard, Change Advisory Board, Informationssicherheitsprozess, Daten-Governance und Projektsteuerung erhalten definierte KI-Prüfpunkte.

Das reduziert Reibung, wenn die Verantwortlichkeiten nicht nur auf Folien stehen. Im Projektplan müssen Prüfungen, Nachweise und Freigaben mit Terminen, Verantwortlichen und Abhängigkeiten hinterlegt sein. Gerade bei engem Cutover-Fenster zeigt sich, ob das Modell belastbar ist: Ist dokumentiert, wer bei einer fehlerhaften Datenübernahme entscheidet? Gibt es eine Rückfalloption? Sind fachliche und technische Ansprechpartner erreichbar?

Bei Einsätzen mit möglichem Bezug zum EU AI Act sollte die Risikoeinordnung früh erfolgen, weil sie Anforderungen an Dokumentation, Aufsicht und Betrieb beeinflussen kann. Datenschutz, Informationssicherheit und weitere regulatorische Anforderungen sind ebenfalls in den konkreten Daten- und Prozesskontext einzuordnen. Für rechtliche Fragestellungen kann die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH ergänzend eingebunden werden. Die operative Rollen- und Prozessgestaltung bleibt davon klar getrennt.

Welche Nachweise den Betrieb steuerbar machen

Verantwortlichkeiten müssen für Projektteams, Revision und Betriebsorganisation nachvollziehbar sein. Eine reine Organigrammzuordnung genügt nicht. Praktisch bewährt sich eine kompakte Dokumentation je KI-Anwendung, die Zweck, Systemgrenzen, Datenquellen, Rollen, Freigaben, Testkriterien und Betriebsprozesse zusammenführt.

Besondere Aufmerksamkeit verdienen die Übergaben zwischen Teams. Wenn ein Data-Science-Team eine Lösung entwickelt, der Fachbereich sie abnimmt und der IT-Betrieb sie übernimmt, muss nachvollziehbar bleiben, welche Modellversion, Konfiguration und Datenbasis freigegeben wurden. Versionsstände, Testergebnisse, bekannte Einschränkungen und offene Risiken gehören daher in die Übergabedokumentation.

Revisionssicheres Reporting bedeutet in diesem Zusammenhang nicht, jede Systeminteraktion unbegrenzt zu speichern. Es bedeutet, angemessene Nachweise für Entscheidungen, Änderungen, Zugriffe und Kontrollen bereitzuhalten. Umfang und Aufbewahrung richten sich nach Einsatzfall, Datenart, Risikobewertung und geltenden Vorgaben.

Typische Lücken früh erkennen

Ein häufiger Fehler ist die Gleichsetzung von Projektleitung und Gesamtverantwortung. Projektleitungen koordinieren Termine, Abhängigkeiten und Liefergegenstände. Sie können aber weder fachliche Risikoentscheidungen noch dauerhafte Betriebsverantwortung pauschal übernehmen. Ebenso problematisch ist ein zentraler KI-Verantwortlicher ohne klare Anbindung an Fachprozesse und Datenverantwortliche.

Auch der Begriff „Human in the Loop“ ersetzt keine Zuständigkeit. Es muss feststehen, wer prüft, nach welchen Kriterien geprüft wird, wie Abweichungen behandelt werden und wann eine automatisierte Entscheidung gestoppt wird. Bei hohen Fallzahlen ist zudem zu klären, ob die vorgesehene Kontrolle operativ tatsächlich leistbar ist.

Der wirksamste Startpunkt ist meist kein unternehmensweites Regelwerk mit maximalem Detailgrad. Ein priorisierter Use Case mit relevanten Daten, realen Schnittstellen und einem geplanten Go-Live zeigt, welche Rollen, Nachweise und Eskalationen tatsächlich fehlen. Daraus lässt sich ein skalierbares Governance-Modell entwickeln, das den Betrieb unterstützt statt ihn zu verlangsamen.

Verantwortlichkeiten vor dem Go-Live prüfbar machen

Quteco unterstützt Unternehmen mit KI-Governance-Quick-Checks und Workshops dabei, Rollenmodelle, Datenflüsse, Freigabepunkte und Betriebsprozesse für konkrete KI-Anwendungen zu strukturieren. Bei SAP-nahen oder produktionskritischen Vorhaben kann die Ausgestaltung direkt mit Testmanagement, Integrationsplanung und Go-Live-Steuerung verbunden werden. Das schafft eine Grundlage, auf der Entscheidungen auch unter Projekt- und Betriebsdruck nachvollziehbar bleiben.