KI Product Ownership nach dem Go-live

Viele KI-Initiativen in Schweizer KMU starten als PoC, Pilot oder MVP. Das ist sinnvoll, weil sich so Machbarkeit, Datenlage und erster Nutzen rasch prüfen lassen. Schwieriger wird es oft erst danach: Die Lösung ist live, erste Mitarbeitende nutzen sie, und trotzdem bleibt offen, wer nun eigentlich verantwortlich ist. Wer priorisiert Verbesserungen? Wer misst den Nutzen? Wer reagiert bei Fehlverhalten, Datenproblemen oder mangelnder Akzeptanz? Und wer entscheidet, ob die Lösung ausgebaut, angepasst oder gestoppt werden soll?

Genau hier beginnt KI Product Ownership. Eine KI-Lösung ist nach dem Go-live nicht abgeschlossen, sondern tritt in eine neue Phase ein: den laufenden Betrieb mit echter Nutzung, realen Daten, veränderten Prozessen und konkreten Erwartungen aus dem Fachbereich. Ohne klare Ownership versanden viele gute Ansätze nicht wegen der Technologie, sondern wegen unklarer Verantwortung.

Warum KI nach dem Go-live nicht einfach fertig ist

Ein PoC zeigt, dass etwas grundsätzlich funktioniert. Ein MVP zeigt, dass sich eine Lösung mit vertretbarem Aufwand einsetzen lässt. Ein Go-live zeigt nur, dass sie verfügbar ist. Ob daraus im Alltag ein tragfähiges Produkt wird, entscheidet sich erst im Betrieb.

Gerade bei KI-Produkten wird der eigentliche Reifegrad oft erst sichtbar, wenn die Lösung regelmässig genutzt wird. Mitarbeitende verwenden sie anders als ursprünglich gedacht. Prozesse ändern sich im Detail. Datenquellen liefern nicht immer dieselbe Qualität. Schnittstellen verhalten sich im Alltag anders als im Test. Und auch die Qualität der Ausgaben bleibt nicht automatisch stabil.

Ein typisches Beispiel aus dem KMU-Alltag ist eine interne Wissenssuche auf Basis von KI. Im Test findet das System die relevanten Dokumente schnell und überzeugend. Nach dem Go-live zeigt sich aber, dass viele Inhalte veraltet sind, gewisse Dokumente nicht sauber abgelegt wurden und Teams unterschiedliche Begriffe für denselben Sachverhalt verwenden. Technisch ist die Lösung live, operativ ist sie aber noch längst nicht sauber verankert.

Dasselbe gilt für KI im Forecasting, in der Dokumentenverarbeitung oder bei Assistenzsystemen im Kundendienst. Die Einführung ist nur ein Schritt. Danach müssen Nutzung, Qualität, Support, Verbesserung und Risiken aktiv gesteuert werden. Wenn niemand diese Steuerung übernimmt, entstehen schnell bekannte Muster:

• Rückmeldungen aus dem Fachbereich bleiben liegen
• kleine Verbesserungen werden nie priorisiert
• die Nutzung sinkt, weil der Alltag nicht gut unterstützt wird
• Risiken werden erst sichtbar, wenn bereits ein Problem entstanden ist
• der erwartete Business Value bleibt unklar

KI funktioniert zudem besonders gut dort, wo klare Prozesse vorhanden sind. Sie ersetzt diese Klarheit nicht. Wenn Rollen, Freigaben, Datenquellen oder Zielgrössen schon vor dem Einsatz unscharf sind, verstärkt KI diese Unschärfe oft eher, statt sie zu lösen.

Projektleitung ist nicht Product Ownership

Eine der häufigsten Ursachen für unklare Verantwortung liegt in der Rollenverwechslung. In vielen Unternehmen wird angenommen, dass die Person, die das Einführungsprojekt geleitet hat, auch danach automatisch zuständig bleibt. Das ist aber nicht dasselbe.

Projektleitung ist auf Umsetzung ausgerichtet. Sie organisiert Anforderungen, Zeitplan, Lieferobjekte, Abstimmungen und Übergabe. Ihr Fokus liegt auf einem definierten Anfang und einem definierten Ende. Das Projekt soll live gehen, innerhalb des Rahmens funktionieren und sauber abgeschlossen werden.

Product Ownership beginnt genau dort, wo das Projekt endet oder in den Hintergrund tritt. Sie verantwortet nicht die Einführung, sondern den laufenden Nutzen des Produkts im Betrieb. Dazu gehören Nutzung, Priorisierung von Verbesserungen, Abstimmung mit dem Business, Rückmeldungen aus dem Alltag und die Weiterentwicklung entlang der tatsächlichen Wirkung.

Ein einfaches Beispiel: Ein KMU führt eine KI-Assistenz für die Beantwortung interner Supportanfragen ein. Die Projektleitung sorgt dafür, dass Datenquellen angebunden, Benutzergruppen definiert, Tests durchgeführt und Schulungen geplant werden. Nach dem Go-live melden Mitarbeitende, dass gewisse Antworten zu allgemein sind, einzelne Inhalte veraltet erscheinen und wichtige Themen nicht gut auffindbar sind.

Die Projektleitung hat ihre Aufgabe erfüllt, wenn die Lösung eingeführt und übergeben wurde. Product Ownership ist dagegen dafür zuständig, diese Rückmeldungen zu strukturieren, Verbesserungen zu priorisieren, Anforderungen an die Fachlichkeit und Nutzung zu konkretisieren und sicherzustellen, dass das Produkt im Alltag wirksam bleibt.

Ohne diese Abgrenzung entsteht oft ein Vakuum. Das Projekt ist formal abgeschlossen, aber niemand fühlt sich verantwortlich, das Produkt aktiv weiterzuführen. Genau deshalb sollte KI Product Management nicht als Fortsetzung des Projekts verstanden werden, sondern als eigene laufende Führungsaufgabe.

Business Ownership: Wer den Wert und die Priorität verantwortet

Die wichtigste Verantwortung rund um eine KI-Lösung liegt nicht zuerst bei der Technik, sondern beim geschäftlichen Nutzen. Business Ownership bedeutet, dass eine Fach- oder Geschäftsverantwortung klar benennt, wofür die Lösung eingesetzt wird, welchen Wert sie stiften soll und welche Prioritäten im Zweifel gelten.

Diese Rolle ist zentral, weil viele KI-Lösungen technisch funktionieren, aber wirtschaftlich zu unscharf geführt werden. Dann gibt es zwar ein System, aber keinen verbindlichen Rahmen dafür, woran Erfolg gemessen wird.

Zur Business Ownership gehören typischerweise folgende Aufgaben:

• das Nutzenziel klar definieren
• den relevanten Prozess und den gewünschten Effekt beschreiben
• Prioritäten gegenüber anderen Anforderungen setzen
• über Ausbauten, Grenzen oder Stopps mitentscheiden
• Zielkonflikte zwischen Fachbereichen klären
• den Business Value laufend überprüfen

Ein Beispiel: Ein Handelsunternehmen nutzt KI für Bedarfsprognosen. Ohne Business Owner bleibt offen, ob die Lösung vor allem Lagerkosten senken, Fehlbestände vermeiden oder die Planungszeit reduzieren soll. Alle drei Ziele sind legitim, führen aber zu unterschiedlichen Prioritäten. Sobald die Lösung im Alltag nicht alle Erwartungen gleichzeitig erfüllt, braucht es jemanden, der diese Zielkonflikte fachlich entscheidet.

Business Ownership darf deshalb nicht einfach an die IT delegiert werden. Die IT kann den Betrieb unterstützen und technische Qualität sicherstellen, aber sie kann nicht definieren, welcher geschäftliche Nutzen Vorrang hat. Das gilt auch dann, wenn die Initiative ursprünglich aus der IT oder Digitalisierung angestossen wurde.

In der Praxis heisst das: Eine KI-Lösung sollte einen klar benannten Business Owner haben, etwa aus Operations, Vertrieb, Service, Finanzen oder Geschäftsleitung. Diese Person muss nicht jedes Detail selbst bearbeiten, aber sie trägt die Verantwortung dafür, dass die Lösung nicht nur technisch vorhanden ist, sondern einen nachvollziehbaren Beitrag zum Geschäft leistet.

Wer sich vertieft mit dem Zusammenspiel von Prozessen, Nutzen und KI befassen will, findet im Bereich Automatisierung und KI zusätzliche Einordnung für typische Anwendungsfelder in KMU.

Product Ownership: Nutzung, Weiterentwicklung und Akzeptanz sichern

Wenn Business Ownership den Nutzen und die Priorität vorgibt, dann übersetzt Product Ownership diese Ziele in konkrete Produktentscheide. Diese Rolle hält das KI-Produkt im Alltag zusammen. Sie schaut nicht nur auf Funktionen, sondern vor allem darauf, wie die Lösung genutzt wird, wo Reibung entsteht und welche Verbesserungen den grössten praktischen Effekt haben.

Product Ownership ist damit die operative Führungsrolle des Produkts auf fachlicher Ebene. Sie verbindet Business, Anwenderinnen und Anwender sowie technische Umsetzung.

Zu ihren Aufgaben gehören in der Regel:

• Nutzung beobachten und auswerten
• Feedback aus dem Alltag aufnehmen und strukturieren
• Anforderungen dokumentieren und konkretisieren
• Verbesserungen priorisieren
• Prozessanpassungen mit den Fachbereichen abstimmen
• Akzeptanz und Anwendbarkeit sichern
• die Roadmap für Weiterentwicklungen führen

Wichtig ist: Product Ownership ist nicht einfach Backlog-Verwaltung. Gerade bei KI-Produkten geht es häufig nicht nur um neue Features, sondern um die Frage, wie das Produkt in reale Arbeitsabläufe passt. Manchmal ist eine bessere Eingabestruktur wichtiger als ein neues Modell. Manchmal braucht es klarere Verantwortlichkeiten in der Nutzung. Manchmal muss die Lösung eingeschränkt werden, weil Anwender sie für ungeeignete Aufgaben verwenden.

Ein Beispiel aus dem internen Wissensmanagement: Das Business-Ziel lautet, dass Mitarbeitende schneller korrekte Antworten auf Standardfragen finden. Der Product Owner stellt nun fest, dass das Problem nicht nur in der Suchqualität liegt, sondern auch darin, dass gewisse Teams Inhalte nicht sauber pflegen und die Benutzeroberfläche zu wenig Kontext liefert. Die richtige Reaktion ist dann nicht einfach ein technischer Ausbau, sondern eine Kombination aus Produktanpassung, Prozessklärung und gezielter Priorisierung.

Gerade hier zeigt sich der Unterschied zwischen Business Ownership und Product Ownership sehr deutlich: Der Business Owner verantwortet den Nutzen und die Zielrichtung. Der Product Owner übersetzt diese Richtung in Entscheidungen zur Nutzung, Ausgestaltung und Weiterentwicklung der Lösung.

Für viele KMU ist das der Punkt, an dem aus einer KI-Idee ein steuerbares Produkt wird. Wer diesen Teil stärken will, sollte KI nicht isoliert betrachten, sondern als Bestandteil von Prozessen, Arbeitsweisen und digitaler Wertschöpfung. Genau dort setzt auch das Themenfeld Automatisierung und KI an.

Tech/Ops Ownership: Betrieb, Stabilität und Qualität im Griff behalten

Neben Business und Product braucht jedes KI-Produkt eine klare technische und operative Verantwortung. Tech/Ops Ownership sorgt dafür, dass die Lösung verlässlich, sicher und stabil betrieben werden kann.

Diese Rolle umfasst mehr als Infrastruktur. Bei KI geht es nicht nur darum, ob ein System erreichbar ist. Auch Datenabhängigkeiten, Output-Qualität, Schnittstellen, Berechtigungen und Releases beeinflussen direkt, ob das Produkt im Alltag brauchbar bleibt.

Typische Aufgaben in der Tech/Ops Ownership sind:

• Monitoring von Verfügbarkeit und Performance
• technischer Support und Incident-Bearbeitung
• Pflege von Schnittstellen und Datenflüssen
• Release-Management und Änderungen im Betrieb
• technische Qualitätssicherung
• Fehleranalyse und Behebung
• Kontrolle von Zugriffs- und Sicherheitsfragen
• Beobachtung von Veränderungen in Daten und Output-Verhalten

Gerade bei KI ist wichtig, dass sich die Ergebnisqualität verändern kann, obwohl kein offensichtlicher Fehler vorliegt. Wenn sich Datenquellen ändern, Inhalte veralten oder Eingabemuster im Alltag verschieben, wirkt sich das auf die Ausgabe aus. Das Produkt läuft technisch vielleicht weiterhin, liefert aber fachlich schlechtere Resultate.

Darum muss Tech/Ops Ownership eng mit Product und Business zusammenarbeiten. Wenn etwa eine Prognose-Lösung plötzlich weniger präzise wirkt, reicht es nicht, nur die Systemverfügbarkeit zu prüfen. Es braucht eine gemeinsame Einordnung: Liegt das Problem an den Daten? An geänderten Prozessen? An der Interpretation durch die Anwender? Oder an einer technischen Anpassung im Hintergrund?

Wichtig ist auch hier die saubere Abgrenzung: Die IT allein trägt nicht automatisch die gesamte Verantwortung für eine KI-Lösung. Sie ist aber unverzichtbar, wenn es um Stabilität, Sicherheit und verlässlichen Betrieb geht. Wer die operative Perspektive im Unternehmen stärken will, findet im Bereich IT und Digitalisierung hilfreichen Kontext zur Einbettung solcher Lösungen.

Wer trägt Verantwortung für Risiken, Bias und Compliance im Alltag?

Bei KI-Produkten wird oft früh über Risiken gesprochen, aber zu wenig über deren laufende Steuerung im Betrieb. Genau dort entstehen die entscheidenden Fragen: Wer erkennt problematische Ausgaben? Wer reagiert auf Verzerrungen? Wer klärt Zugriffsfragen? Wer bewertet Reputationsrisiken? Und wer stellt sicher, dass problematische Nutzung nicht stillschweigend zur Gewohnheit wird?

Die Verantwortung für Risiken darf nicht bei einer einzigen Rolle hängen bleiben. Sie muss zwischen Business, Product und Tech/Ops aufgeteilt und koordiniert werden.

Business Ownership verantwortet, welche geschäftlichen Entscheidungen oder Prozessschritte überhaupt von der KI unterstützt werden dürfen. Sie definiert die Tragweite und die akzeptablen Grenzen.

Product Ownership beobachtet, wie die Lösung tatsächlich genutzt wird, wo Missverständnisse entstehen und ob sich Fehlverhalten oder schlechte Nutzungsmuster einschleichen.

Tech/Ops Ownership stellt sicher, dass technische Kontrollen, Zugriffe, Protokollierung, Datenqualität und Betriebsstabilität im Griff bleiben.

Für KMU braucht es dabei keine schwere Governance-Struktur. Sinnvoll sind pragmatische Kontrollen, die regelmässig angewendet werden. Dazu gehören zum Beispiel:

• klare Definition, wofür die KI eingesetzt werden darf und wofür nicht
• stichprobenartige Prüfung von Ergebnissen
• einfache Eskalationswege bei problematischen Ausgaben
• regelmässige Überprüfung von Datenquellen und Berechtigungen
• transparente Dokumentation von bekannten Grenzen
• fachliche Review-Termine bei relevanten Änderungen

Bias ist im KMU-Kontext häufig weniger ein abstraktes Ethikthema als ein konkretes Qualitäts- und Entscheidungsproblem. Wenn etwa ein KI-System Anfragen systematisch falsch einordnet, gewisse Kundentypen schlechter bedient oder bei Prognosen wiederkehrende Verzerrungen zeigt, ist das nicht nur ein Modellthema, sondern ein betrieblicher Steuerungsfehler.

Entscheidend ist deshalb nicht, eine möglichst umfassende Richtlinie zu formulieren, sondern Verantwortung in den Alltag zu bringen. Risiken müssen dort bearbeitet werden, wo Nutzung, Prozesse und technische Realität aufeinandertreffen.

Ein einfaches Ownership-Modell für Schweizer KMU

Viele KMU brauchen keine grosse Governance, sondern eine kleine, klare Struktur. In der Praxis hat sich ein Modell mit drei benannten Rollen bewährt:

Business Owner

Der Business Owner verantwortet den geschäftlichen Zweck. Er oder sie legt fest, welchen Nutzen die KI-Lösung stiften soll, welche Prioritäten gelten und wie Erfolg gemessen wird. Diese Rolle sitzt idealerweise dort, wo der betroffene Prozess fachlich geführt wird.

Product Owner

Der Product Owner steuert das Produkt im Alltag. Er oder sie sammelt Feedback, priorisiert Verbesserungen, übersetzt Business-Ziele in konkrete Anforderungen und sorgt dafür, dass die Lösung von den Anwendern verstanden und genutzt wird.

Tech/Ops Owner

Der Tech/Ops Owner verantwortet den technischen Betrieb. Dazu gehören Stabilität, Monitoring, Schnittstellen, Berechtigungen, Support und technische Qualität im laufenden Einsatz.

Dieses Modell funktioniert auch in kleineren Organisationen. Wichtig ist nicht, dass für jede Rolle eine Vollzeitfunktion geschaffen wird. Wichtig ist, dass die Verantwortung benannt und verbindlich zugeordnet ist. In kleineren Teams kann eine Person mehrere Rollenanteile übernehmen, solange die Perspektiven nicht unklar vermischt werden. Wer etwa gleichzeitig Product und Tech/Ops verantwortet, sollte trotzdem sauber zwischen Nutzungsfragen und Betriebsfragen unterscheiden.

Für die Steuerung genügen meist wenige feste Elemente:

• ein klarer Owner je Rolle
• ein definierter Entscheidungsweg für Prioritäten
• ein Eskalationsweg bei Qualitäts- oder Risikofragen
• ein kurzer regelmässiger Review-Rhythmus, zum Beispiel monatlich oder quartalsweise
• einfache Kennzahlen für Nutzung, Nutzen und Stabilität

Ein solcher Review kann sehr pragmatisch aufgebaut sein:

1. Was wird tatsächlich genutzt?
2. Welcher Nutzen ist sichtbar?
3. Welche Probleme oder Risiken sind aufgetreten?
4. Welche Verbesserungen haben aktuell Priorität?
5. Welche Entscheidungen braucht es von Business, Product oder Tech/Ops?

Damit entsteht ein steuerbarer KI Lifecycle, ohne dass ein KMU in komplexe Rollenkaskaden oder Gremienmodelle abrutscht.

Ownership für die eigene KI-Lösung jetzt klären

Viele Unternehmen merken erst nach dem Go-live, dass ihre KI-Lösung zwar vorhanden ist, aber noch nicht sauber geführt wird. Genau dann lohnt sich ein nüchterner Blick auf Ownership, Nutzen und Betrieb.

Ein sinnvoller erster Schritt ist, bestehende oder geplante KI-Lösungen systematisch durchzugehen:

• Welche Lösung ist bereits im Einsatz oder kurz vor dem Einsatz?
• Wer verantwortet den Business Value?
• Wer steuert Nutzung und Weiterentwicklung?
• Wer trägt die technische Betriebsverantwortung?
• Wie werden Risiken, Datenqualität und problematische Ausgaben erkannt?
• Nach welchem Rhythmus wird überprüft, ob die Lösung den gewünschten Nutzen bringt?

Oft zeigt sich dabei schnell, dass die Technologie nicht das Hauptproblem ist. Häufig fehlt eine klare Zuordnung von Verantwortung, ein gemeinsames Zielbild oder ein praktikabler Review-Rhythmus. Genau diese Punkte entscheiden aber darüber, ob aus einem erfolgreichen Test ein dauerhaft nützliches Produkt wird.

Eine strukturierte Potenzialanalyse hilft, bestehende oder geplante KI-Lösungen entlang von Nutzen, Ownership, Betrieb und Risiken sauber einzuordnen. So werden unklare Zuständigkeiten sichtbar, relevante Anwendungsfälle besser priorisiert und der weitere Ausbau auf das ausgerichtet, was im KMU-Alltag wirklich zählt: verlässlicher Nutzen, tragfähige Prozesse und klare Verantwortung.

Häufig gestellte Fragen

Wer ist nach dem Go-live einer KI-Lösung verantwortlich?

Nach dem Go-live sollte die Verantwortung auf drei Perspektiven verteilt sein: Business Owner für Nutzen und Prioritäten, Product Owner für Nutzung und Weiterentwicklung sowie Tech/Ops Owner für Betrieb und Stabilität. Eine einzelne Rolle reicht in der Regel nicht aus, weil KI-Produkte fachliche, produktbezogene und technische Verantwortung gleichzeitig brauchen.

Worin liegt der Unterschied zwischen Projektleitung und Product Ownership?

Projektleitung ist zeitlich begrenzt und auf Einführung, Umsetzung und Übergabe fokussiert. Product Ownership ist eine laufende Verantwortung im Betrieb. Sie stellt sicher, dass die Lösung im Alltag genutzt wird, Feedback aufgenommen wird und Verbesserungen priorisiert und umgesetzt werden. Das eine endet mit dem Projekt, das andere beginnt dort erst richtig.

Muss die IT eine KI-Lösung allein betreiben?

Nein. Die IT oder Tech/Ops trägt eine wichtige Verantwortung für Betrieb, Stabilität, Sicherheit und Support. Der geschäftliche Nutzen und die Prioritäten müssen aber aus dem Business kommen, und die aktive Steuerung von Nutzung und Weiterentwicklung gehört in die Product Ownership. KI allein an die IT zu delegieren führt oft dazu, dass technisch funktionierende Lösungen fachlich nicht geführt werden.

Wie wird der Business Value einer KI-Anwendung laufend überprüft?

Der Business Value sollte an wenigen klaren Zielgrössen gemessen werden, die zum jeweiligen Anwendungsfall passen. Das können zum Beispiel Zeitersparnis, geringere Fehlerquote, schnellere Bearbeitung, bessere Planungsqualität oder höhere Servicequalität sein. Wichtig ist, dass diese Zielgrössen vorab definiert und in einem regelmässigen Review überprüft werden, statt nur auf ein einmaliges Einführungsprojekt zu schauen.

Wer entscheidet über Verbesserungen, wenn eine KI-Lösung im Alltag nicht gut genutzt wird?

Inhaltlich priorisiert wird idealerweise gemeinsam, aber mit klaren Rollen: Der Business Owner gibt die Zielrichtung vor, der Product Owner bewertet Nutzung und Verbesserungspotenzial und bereitet die Produktentscheide vor, und Tech/Ops klärt die technische Umsetzbarkeit und Auswirkungen auf den Betrieb. So werden Verbesserungen nicht isoliert technisch oder rein fachlich entschieden.

Wie lassen sich Risiken und Bias bei KI-Produkten im KMU sinnvoll kontrollieren?

Für KMU sind einfache, regelmässige Kontrollen meist wirksamer als umfangreiche Governance-Dokumente. Dazu gehören definierte Einsatzgrenzen, Stichproben bei Ergebnissen, klare Eskalationswege, Überprüfung von Datenquellen, saubere Zugriffsrechte und kurze Review-Termine für auffällige Fälle. Risiken und Bias sollten im Alltag beobachtet und gemeinsam von Business, Product und Tech/Ops bearbeitet werden.