Es gibt einen Tag, an dem sich entscheidet, ob ein KI-Vorhaben dauerhaft Bestand hat. Es ist nicht der Tag der gefeierten Demo und auch nicht der offizielle Go-Live. Es ist der Tag, an dem das Projektteam abzieht.

Bis zu diesem Moment kümmert sich immer jemand: die externe Beratung, das interne Innovationsteam oder die zwei Entwickler, die den Prototyp gebaut haben. Sie kennen die Eigenheiten des Modells, sie stutzen, wenn eine Ausgabe merkwürdig wirkt, und sie greifen ein, bevor die Fachabteilung einen Fehler überhaupt bemerkt. Diese informelle Fürsorge steht in keinem Projektplan. Genau deshalb fällt ihr Wegfall zunächst niemandem auf.

Spürbar wird er drei bis sechs Wochen später. Dann steht plötzlich eine Frage im Raum, die vorher niemand verbindlich beantwortet hat: Wer ist hier eigentlich zuständig?

Zuständigkeit ist nicht dasselbe wie Verantwortung

In fast jeder Abschlusspräsentation findet sich eine Folie mit einer beruhigenden Zeile: „Betrieb: Fachbereich Einkauf“ oder „Ownership: IT-Services“. Diese Zeile fühlt sich wie eine Klärung an. In der Praxis ist sie wertlos.

Eine Abteilung kann keine fachlichen Entscheidungen treffen. Eine Abteilung kann ein System nicht freitagnachmittags anhalten. Und eine Abteilung bemerkt nicht, dass die Ausgabequalität seit dem letzten Modell-Update schleichend nachgelassen hat. All das können nur einzelne, namentlich benannte Menschen mit Kalender und Verantwortung.

Wenn im Ernstfall drei Personen glauben, dass jemand anderes zuständig ist, ist niemand zuständig. Geteilte Verantwortung ist der verlässlichste Weg, gar keine zu haben.

Das häufigste Missverständnis folgt den alten Silogrenzen: Die IT verantwortet die Technik, der Fachbereich die Inhalte. Das klingt auf dem Papier aufgeräumt, lässt aber das eigentliche Betriebsrisiko ungedeckt. Wenn ein Sprachmodell eine Lieferantenrechnung falsch verbucht, liegt weder ein technischer Systemausfall vor – die Server liefen einwandfrei – noch ein klassischer Erfassungsfehler, denn niemand hat falsche Daten eingetippt. Es ist ein Ergebnisfehler. Und für die inhaltliche Richtigkeit maschineller Ergebnisse ist in dieser alten Aufteilung niemand vorgesehen — eine Lücke, die Governance schließen muss, bevor der erste Fehler auftritt.

Drei Dinge, die ein Owner zwingend braucht

Ownership ist kein wohlklingender Titel im Organigramm, sondern eine konkrete funktionale Ausstattung. Fehlt diese Ausstattung, scheitert die Rolle unweigerlich:

Erstens: Fachliche Entscheidungsbefugnis. Der Owner bestimmt verbindlich, was ein korrektes Ergebnis ist. Nicht das Modell, nicht die IT und nicht die Beratung. Taucht ein fachlicher Zweifelsfall auf – und Grenzfälle tauchen spätestens ab der zweiten Betriebswoche auf –, muss eine Person entscheiden können: „So wird dieser Fall ab sofort behandelt.“ Fehlt diese Befugnis, landet jede Unklarheit in zeitraubenden Abstimmungsrunden, bis die Anwender den Workflow entnervt umgehen.

Zweitens: Reservierte Arbeitszeit. Ein KI-Workflow ist kein statisches Werkzeug, das man einmal installiert und vergisst. Prompts verlieren an Schärfe, Kontextdokumente veralten, Geschäftsprozesse ändern sich, und Anbieter aktualisieren Modelle ohne Vorwarnung. Als Richtwert hat sich ein halber Tag pro Monat je aktivem Workflow bewährt – in den ersten Betriebswochen auch deutlich mehr.

Drittens: Das uneingeschränkte Recht abzuschalten. Wer persönlich dafür geradesteht, dass ein System zuverlässig arbeitet, muss es im Zweifel sofort stoppen können – ohne vorher drei Führungsebenen um Erlaubnis zu bitten. Ein Abschaltrecht, das an Gremienfreigaben hängt, ist im Krisenmoment nutzlos. Und ein Owner, der zwar abschalten darf, dafür aber Rechtfertigungsdruck fürchtet, wird zu lange zögern. Genau dieses Zögern verwandelt einen einfachen Fehler in einen geschäftskritischen Vorfall.

Der Freitagnachmittag-Test

Ob die Betriebsverantwortung wirklich geregelt ist, lässt sich vor dem Go-Live mit einem einfachen Gedankenspiel prüfen — die übrigen Punkte derselben Runde stehen in der Checkliste zur Abnahme:

Es ist Freitag, 16 Uhr. Eine Sachbearbeiterin stellt fest, dass der KI-Assistent heute zum dritten Mal eine falsche Kundenauskunft generiert hat – und zwei dieser Schreiben sind bereits verschickt. An wen wendet sie sich jetzt?

Fragt man diese Frage in die Projektrunde, müssen alle wie aus der Pistole geschossen denselben Namen nennen. Zögert die Runde oder fallen zwei unterschiedliche Namen, ist der Workflow nicht betriebsbereit.

Der zweite Teil des Tests ist noch aufschlussreicher: Man ruft die genannte Person an und fragt sie direkt, ob sie von ihrer Rolle weiß. Überraschend oft weiß sie es nicht. Ownership wurde dann in einem Meeting beschlossen, bei dem sie gar nicht am Tisch saß – formal delegiert, aber operativ nie vereinbart.

Auftraggeber, Betreiber und fachlicher Owner

Drei Rollen werden bei KI-Initiativen regelmäßig verwechselt, und diese Verwechslung wird im Betrieb teuer:

  • Der Auftraggeber hat das Projekt initiiert und das Budget freigegeben. Er trägt das wirtschaftliche Investitionsrisiko, arbeitet aber nicht im Alltag mit dem Werkzeug und kann fachliche Detailfehler nicht erkennen.
  • Der technische Betreiber sichert die Infrastruktur: API-Zugänge, Verfügbarkeit, Schnittstellen, Latenzen und Kostenüberwachung. Er bemerkt sofort, wenn das System keine Antwort liefert – aber er bemerkt nicht, wenn die gelieferte Antwort inhaltlicher Unsinn ist.
  • Der fachliche Owner verantwortet die Qualität der Ergebnisse. Er ist die einzige Person, die eine fehlerhafte Ausgabe auf einen Blick als solche entlarvt. Ohne ihn gibt es keine echte Qualitätssicherung.

In kleineren Organisationen können technischer Betreiber und fachlicher Owner in Personalunion auftreten. Was niemals funktioniert: den fachlichen Owner mit jemandem zu besetzen, der die operative Facharbeit nicht im Detail beherrscht. Wer noch nie Lieferantenverträge manuell geprüft hat, kann nicht beurteilen, ob die Zusammenfassung der KI vollständig ist. Er sieht nur, dass der Text flüssig formuliert ist. Und flüssig zu formulieren ist genau das, was Sprachmodelle auch bei völligen Falschaussagen perfekt beherrschen.

Die Frage nach dem Owner gehört an den Anfang

Der typische Ablauf scheitert an seiner Reihenfolge: Idee, Prototyp, erfolgreicher Pilot, Begeisterung im Management, Beschluss zum Rollout – und ganz am Ende die hektische Suche nach jemandem, der das fertige System übernimmt. Zu diesem Zeitpunkt ist die Verhandlungsposition fatal. Das Projekt gilt bereits als Erfolg, das Budget ist investiert, und die auserkorene Fachkraft erbt eine Dauerlast, auf deren Zuschnitt sie keinerlei Einfluss hatte.

Die Frage nach dem fachlichen Owner gehört an den Anfang. Sie ist eine der fünf Kernfragen, die ein PoC vorab beantworten muss, und der schärfste Filter, um unrentable Use-Cases frühzeitig auszusortieren.

Findet sich im Fachbereich niemand, der bereit ist, die Verantwortung für einen Workflow dauerhaft zu übernehmen, ist das kein organisatorisches Missgeschick. Es ist ein glasklares Signal über den tatsächlichen Nutzen: Ein Workflow, für den niemand ein paar Stunden monatlicher Pflege investieren will, spart in der Praxis weniger ein, als er im Betrieb kostet.

Ein fehlender Owner ist kein Übergabeproblem am Projektende. Er ist ein Selektionsproblem, das schon vor der ersten Codezeile hätte auffallen müssen.

Was in der Übergabe schriftlich fixiert sein muss

Ein sauberes Übergabedokument braucht keine fünfzig Seiten. Vier verbindliche Punkte auf einer einzigen Seite genügen:

  1. Name des fachlichen Owners samt fester Vertretung – als konkrete Personen, nicht als Abteilungskürzel.
  2. Das freigegebene Zeitbudget, abgestimmt und bestätigt durch die jeweilige Führungskraft.
  3. Das uneingeschränkte Abschaltrecht, klar formuliert und ohne Zustimmungsvorbehalte.
  4. Ein fester Review-Termin nach vier bis sechs Wochen, an dem der Workflow auf den Prüfstand kommt – inklusive der Option, ihn ohne Gesichtsverlust wieder abzuschalten.

Besonders der vierte Punkt wird oft vergessen. Er nimmt den Druck von der Entscheidung, verwandelt eine gefühlte Dauerbelastung in ein kalkulierbares Experiment und stellt sicher, dass Systeme im Alltag nicht einfach stillschweigend versanden.

Ist die personelle Verantwortung geregelt, folgt unmittelbar die nächste operative Hürde: Ein Owner kann nur verantworten, was sich objektiv prüfen lässt. Woran genau sich ein betriebsreifes Ergebnis messen lassen muss, klärt der nächste Teil der Serie zur Betriebsübergabe.

Häufige Fragen

Was bedeutet Ownership bei einem KI-Workflow konkret?

Eine namentlich benannte Person entscheidet, was ein fachlich korrektes Ergebnis ist, pflegt Prompts und Kontextdaten, verantwortet die Qualität im laufenden Betrieb und darf das System jederzeit stoppen. Eine Abteilung kann das nicht leisten, weil im Ernstfall niemand persönlich greifbar ist.

Kann die IT-Abteilung den Owner eines KI-Workflows stellen?

Nur für den technischen Betrieb wie Verfügbarkeit und Schnittstellen. Die fachliche Verantwortung dafür, ob eine Ausgabe inhaltlich stimmt, gehört zwingend in den nutzenden Fachbereich. Fehlt diese Schnittstelle, verantwortet am Ende niemand das Gesamtergebnis.

Wie viel Zeit kostet die Betreuung eines KI-Workflows?

Als Richtwert gilt ein halber Tag pro Monat je aktivem Workflow, in den ersten Wochen nach dem Go-Live oft mehr. Entscheidend ist, dass diese Zeit vorab im Kalender reserviert wird, statt sie zusätzlich zur vollen Auslastung vorauszusetzen.

Was tun, wenn sich niemand als fachlicher Owner findet?

Dann geht der Workflow nicht in Betrieb. Ein fehlender Owner ist kein organisatorisches Detail für später, sondern der Beleg dafür, dass der erwartete Nutzen niemandem wichtig genug ist, um dauerhaft dafür persönlich einzustehen.