Ein AI Product Owner verantwortet wie jeder Product Owner den Wert des Produkts und das Product Backlog. Bei KI-Produkten kommen drei Aufgaben dazu: Er legt Qualität über Evaluationen auf einem Testset fest, steuert Daten als Teil des Produkts und nimmt Fehlerrisiken sowie laufende Kosten pro Anfrage in die Priorisierung auf. „Fertig“ heißt bei einer KI-Funktion deshalb: Sie erreicht die vereinbarte Qualitätsschwelle im Testset. Eine überzeugende Demo reicht dafür nicht.
Sicherheit, Integration und Betrieb müssen ebenfalls geklärt sein. Welche Verantwortung bleibt, was neu dazukommt und was Sie vor einer Investition klären sollten, lesen Sie hier.
Was ist ein AI Product Owner?
Ein AI Product Owner ist ein Product Owner, der ein Produkt mit KI-Funktionen verantwortet. Der Scrum Guide 2020 kennt keine eigene Rolle dafür.
Laut Scrum Guide verantwortet der Product Owner die Maximierung des Produktwerts und ein wirksames Management des Product Backlogs. Das gilt ebenso für Produkte mit Modellen oder LLM-Funktionen. Der Zusatz „AI“ beschreibt den Kontext. Er begründet weder eine zusätzliche Scrum-Verantwortlichkeit noch eine vorgeschriebene Zertifizierung.
Die grundlegenden Product Owner Aufgaben bleiben bestehen: Ziele klären, priorisieren und Entscheidungen transparent machen.
Data Scientists entwickeln und untersuchen Modelle. ML Engineers übernehmen je nach Teamorganisation technische Aufgaben bei Bereitstellung und Betrieb. Der PO entscheidet über Wert, Prioritäten und fachliche Qualitätsziele. Er muss Modelle nicht selbst trainieren. Auch technische Verantwortung und rechtliche Pflichten liegen nicht pauschal bei ihm allein.
Klassischer Product Owner vs. AI Product Owner
Die Gegenüberstellung zeigt, wo zusätzliche Unsicherheit entsteht. Sie zieht keine scharfe Grenze: Auch klassische Produkte brauchen Datenqualität, Sicherheit und Monitoring.
| Dimension | Klassisches Produkt | Produkt mit KI-Funktion |
|---|---|---|
| Wertverantwortung | Produktwert maximieren | Bleibt unverändert |
| Output | Überwiegend spezifiziertes Verhalten | Teilweise probabilistische Ergebnisse |
| Qualitätsnachweis | Unter anderem Funktionsprüfungen | Zusätzlich Testsets und Evaluationen |
| Daten | Häufig wichtige Grundlage | Oft unmittelbare Produktabhängigkeit |
| Backlog | Funktionen und technische Arbeit | Zusätzlich Experimente, Datenarbeit und Monitoring |
| Priorisierung | Nutzen, Aufwand und Risiken | Zusätzlich Fehlerrisiko und variable Betriebskosten |
| Release | Vereinbarte Abnahmekriterien | Zusätzlich Qualitätsgrenzen und Fallbacks |
Bei KI lässt sich das gewünschte Ergebnis oft nicht vollständig vorab festschreiben. Eine Release-Entscheidung braucht deshalb einen belastbaren Nachweis über viele relevante Fälle. Gelungene Einzelbeispiele reichen nicht.
Vor dem Start: Fünf Entscheidungen, die Sie nicht delegieren können
Vor einer Investition klärt der PO fünf Fragen mit den zuständigen Beteiligten. Bleibt eine davon offen, sollten Sie noch nicht in die Umsetzung gehen.
Welches Problem lösen wir?
Benennen Sie eine konkrete Nutzeraufgabe und die Schwierigkeit, die heute dabei entsteht. Halten Sie auch fest, was Sie ausdrücklich nicht lösen wollen. „Wir brauchen einen Chatbot“ beschreibt eine Lösungsidee, noch kein ausreichend geklärtes Problem. Zur Einordnung möglicher Aufgaben helfen KI-Anwendungsfälle im Unternehmen.
Welche Daten dürfen wir verwenden?
Klären Sie Datenzugang, Nutzungsrahmen und Verantwortung. Eine vorhandene Dokumentensammlung ist noch keine freigegebene Datenbasis. Prüfen Sie auch, ob sie für die Aufgabe taugt.
Wie messen wir Qualität?
Vereinbaren Sie relevante Testfälle, Bewertungskriterien und Qualitätsschwellen in einem Evaluationskonzept. Das gehört vor die Optimierung und vor die erste Präsentation im Management.
Was passiert bei Fehlantworten?
Legen Sie fest, wie die Funktion mit Fehlern umgeht. Soll sie nachfragen, nicht antworten, eine menschliche Prüfung auslösen oder zum bestehenden Prozess zurückkehren? Klären Sie auch, wer dafür zuständig ist und welche Bearbeitungskapazität bereitsteht.
Was kostet eine Anfrage im Betrieb?
Sie brauchen Annahmen zum technischen Aufwand, zur menschlichen Nacharbeit und zu Budgetgrenzen. Diese Annahmen dürfen anfangs unsicher sein. Eine fehlende Kostenbetrachtung ist dagegen keine tragfähige Grundlage.
Bleibt eine Antwort offen, gehört sie in die Discovery. Mehr Implementierung beseitigt diese Unklarheit selten.
Was sich im Product Backlog ändert
Datenzugang, Testset-Aufbau, Evaluation, Fallback, Monitoring und Kostenkontrolle gehören ins Product Backlog. Sie sind Produktarbeit, die Sie priorisieren und sichtbar machen.
Ein hypothetisches Beispiel: Eine interne Assistenz beantwortet fachliche Fragen anhand freigegebener Unternehmensdokumente. Dafür muss das Team berechtigte Quellen erschließen und deren Aktualität klären. Gemeinsam mit dem Fachbereich sammelt und bewertet es Referenzfragen. Unbelegte Antworten soll das System erkennen und zur Prüfung weiterleiten.
Weitere Backlog-Einträge betreffen die Zugriffsrechte bei Suche und Antwortausgabe. Hinzu kommt die Erfassung der Kosten je Anfrage und erfolgreich bearbeitetem Vorgang.
Diese Anforderungen beschreiben zunächst Ergebnisse. Sie legen noch keine technische Architektur fest.
Die Antwortqualität lässt sich anhand fachlicher Richtigkeit und Quellenbezug mit vereinbarten Schwellen bewerten. Für Berechtigungen bleiben deterministische Abnahmekriterien sinnvoll: Nicht berechtigte Inhalte dürfen nicht ausgegeben werden.
Diese Arbeit muss beim Übergang vom Experiment zur nutzbaren Version ausdrücklich eingeplant sein. Darum geht es auch im Beitrag Vom Prototyp zum Produkt: ein KI-MVP entwickeln.
Qualität messen: Testset, Ground Truth und Human in the Loop
Wer KI-Qualität messen will, muss fachliche Erwartungen in einen wiederholbaren Prüfprozess übersetzen. Der Modellvergleich kommt erst danach.
Aufgaben und Bewertungsmaßstab festlegen
Wählen Sie relevante Nutzeraufgaben aus. Sammeln Sie typische Fragen und Grenzfälle. Dazu gehören auch Situationen, in denen die Funktion scheitert oder bewusst nicht antworten soll.
Definieren Sie anschließend die Referenz. Bei eindeutigen Aufgaben kann eine bekannte richtige Antwort als Ground Truth dienen. Bei offenen Antworten gibt es häufig mehrere vertretbare Lösungen. Dafür brauchen Sie eine fachliche Bewertungsrubrik statt eines starren Mustertexts.
Bei LLM-Ausgaben sollten Sie fachliche Korrektheit und Quellenbezug getrennt bewerten: Stimmen die Aussagen, und tragen die angegebenen Quellen die Antwort? Prüfen Sie außerdem die Vollständigkeit. Eine Antwort kann korrekt sein und trotzdem entscheidende Informationen auslassen. Ein weiteres Kriterium ist die angemessene Nichtbeantwortung: Erkennt die Funktion, wenn ihr die Grundlage für eine Antwort fehlt?
Bei einer ML-Klassifikation bestimmen die Fehlerfolgen, welche Kriterien geeignet sind. Precision fragt, wie viele positive Zuordnungen tatsächlich zutreffen. Recall fragt, wie viele tatsächlich relevante Fälle erkannt werden. Welches Maß wichtiger ist, hängt vom Anwendungsfall ab.
Qualitätsschwellen vor der Evaluation vereinbaren
Universelle Zielwerte helfen wenig. Eine unverbindliche Suchhilfe verträgt andere Fehler als eine Funktion, die Entscheidungen vorbereitet.
Vereinbaren Sie die Schwellen vor der Auswertung. Halten Sie außerdem ein separates Evaluationstestset zurück, das das Team nicht zur laufenden Optimierung nutzt. Sonst belegt ein gutes Ergebnis womöglich nur die Anpassung an bekannte Fälle.
Der Fachbereich bewertet Stichproben und strittige Antworten. Der PO führt diese Bewertung mit Produktziel und Risiken zusammen. Das Ergebnis ist eine dokumentierte Release-Entscheidung, die über eine technische Modellfreigabe hinausgeht.
Menschliche Prüfung konkret organisieren
Human in the Loop braucht einen benannten Prüf- oder Freigabeschritt. Wer prüft welche Ergebnisse? Wann eskaliert wer an wen? Was passiert, wenn die Kapazität fehlt?
Erst mit diesen Antworten wird der Begriff zum Qualitätsnachweis.
Nach Modell-, Prompt- oder relevanten Datenänderungen evaluiert das Team erneut. Im Betrieb ergänzen Monitoring, Fehlermeldungen und fachliche Stichproben die Tests. Auch ein bestandenes Testset deckt nicht jede spätere Nutzungssituation ab.
Daten werden Teil des Produkts
Daten liefern Sie bei einem KI-Produkt laufend zu. Ihre Verfügbarkeit, Qualität und Pflege beeinflussen die Funktion dauerhaft.
Dabei sind drei Zwecke zu unterscheiden. Trainingsdaten dienen der Modellentwicklung oder Anpassung. Kontextdaten liefern Informationen für eine konkrete Verarbeitung. Betriebsdaten helfen, Nutzung, Fehler und Kosten zu verstehen. Viele LLM-Funktionen kommen ohne eigenes Modelltraining aus.
Für die Produktentscheidung muss feststehen, welche Daten benötigt werden und wer sie bereitstellen darf. Prüfen Sie, ob sie aktuell und für die Zielaufgabe repräsentativ sind. Ebenso müssen Nutzungsrechte und Zugriffsbeschränkungen geklärt sein. Benennen Sie außerdem, wer Inhalte pflegt, korrigiert oder entfernt.
Zweck, Rechtsgrundlage, Datenminimierung, Aufbewahrung und Dienstleisterprüfung klären Sie gemeinsam mit Datenschutz und zuständigen Fachstellen.
Am Ende steht eine benannte Datenverantwortung. „Das Entwicklungsteam kümmert sich später darum“ ist keine tragfähige Vereinbarung.
Risiken und Regulierung: Fehlantworten brauchen einen vorgesehenen Umgang
Halluzinationen können falsche fachliche Auskünfte erzeugen. Bias kann systematisch ungleiche Ergebnisse verursachen. Fehlende Transparenz erschwert es, Empfehlungen nachzuvollziehen und anzufechten.
Die Schutzmaßnahmen müssen zu den möglichen Folgen passen. Dazu zählen Quellenbezug, begrenzte Aktionen, Freigaben, Protokollierung oder ein Fallback auf den bisherigen Prozess. Keine einzelne Maßnahme beseitigt alle Risiken. Eine Quellenangabe beweist beispielsweise noch nicht, dass die Funktion die Antwort korrekt daraus abgeleitet hat.
Das People + AI Guidebook von Google bietet Orientierung für nutzerbezogene Gestaltung und den Umgang mit Fehlern.
Ein zusätzlicher Prüfpunkt ist der EU AI Act (Verordnung (EU) 2024/1689). Er ist seit dem 1. August 2024 in Kraft, seine Pflichten gelten gestaffelt. Seit dem 2. Februar 2025 verlangt Artikel 4, dass Unternehmen beim Einsatz von KI-Systemen für ausreichende KI-Kompetenz ihres Personals sorgen. Lassen Sie Anwendungsfall, Unternehmensrolle und mögliche Risikoeinstufung fachlich prüfen. Dazu gehören auch einschlägige Pflichten und anwendbare Fristen. Nicht jede KI-Funktion ist ein Hochrisikosystem. Für eine konkrete Investitionsentscheidung zählt der jeweils aktuelle Rechtsstand.
Davon zu unterscheiden ist das NIST AI Risk Management Framework. Es bietet einen freiwilligen Rahmen für strukturiertes Risikomanagement. Gesetzliche Anforderungen ersetzt es nicht.
Priorisierung: Produktwert, Fehlerrisiko und Kosten zusammen betrachten
Eine Funktion kann in der Demo überzeugen und im Betrieb wirtschaftlich unattraktiv sein.
Betrachten Sie den erwarteten Nutzen deshalb gemeinsam mit dem Evaluationsnachweis und den Fehlerfolgen. Berücksichtigen Sie auch Daten- und Integrationsaufwand sowie den laufenden Betrieb. Hohe erwartete Nutzung rechtfertigt keine Freigabe, solange kritische Fehler ungeklärt bleiben.
Bei LLM-Funktionen gehören Modellaufrufe, Kontextumfang, zusätzliche Verarbeitung und Wiederholungen in die Kostenbetrachtung. Falls menschliche Prüfung nötig ist, zählt auch dieser Aufwand dazu. Modellkosten pro Anfrage sind nicht die Gesamtkosten eines erfolgreich bearbeiteten Vorgangs.
Bei anderen ML-Funktionen können Inferenz, Infrastruktur und Datenpflege anders ins Gewicht fallen.
Ein kleinerer Funktionsumfang kann deshalb die richtige Entscheidung sein. Ebenso kann es sinnvoll sein, nur einfache Fälle zu automatisieren. Schwierige Aufgaben gehen dann über einen manuellen Fallback in die Bearbeitung. Weniger Automatisierung kann wirtschaftlicher sein als eine breite Lösung mit hohem Betreuungsaufwand.
Welche Fähigkeiten braucht ein Product Owner für KI-Produkte?
Entscheidend ist, was ein PO beurteilen kann. Die Zahl der Tools, die er kennt, spielt eine kleinere Rolle.
Er braucht Problemverständnis, um eine sinnvolle Nutzeraufgabe abzugrenzen. Evaluationskompetenz hilft ihm, einen belastbaren Qualitätsnachweis von einer guten Vorführung zu unterscheiden. Datenverständnis ist nötig, um Abhängigkeiten und Grenzen zu erkennen.
Dazu kommen Risikoverständnis und wirtschaftliche Bewertung. Auch fachliche Prüfungen und Freigaben muss er organisieren können.
Programmieren muss ein AI Product Owner nicht zwingend. Er muss technische Aussagen aber ausreichend verstehen, um Annahmen, Einschränkungen und Alternativen zu hinterfragen. Für Modellverfahren und technische Bewertung bindet er Data Scientists und ML Engineers ein. Die fachliche Richtigkeit beurteilt der Fachbereich. Datenschutz und rechtliche Fragen klären die zuständigen Stellen.
Ob eine Antwort gut genug ist, entscheiden mehrere Rollen gemeinsam. Der PO verantwortet fachliche Qualitätsziele und Priorisierung. Die Bewertung liefern die dafür qualifizierten Rollen. Technische und rechtliche Freigaben bleiben bei den zuständigen Verantwortlichen.
Eine Kompetenzlücke rechtfertigt deshalb nicht in jedem Fall eine neue Stelle. Oft braucht es zunächst klarere Zusammenarbeit und gezielten Kompetenzaufbau.
Kurz eingeordnet: KI als Werkzeug im PO-Alltag
KI-Unterstützung für den PO ist etwas anderes als Produktverantwortung für eine KI-Funktion.
KI kann etwa Anforderungen aus Nutzersicht entwerfen, freigegebene Research-Ergebnisse zusammenfassen oder Testfälle vorschlagen. Die Ergebnisse bleiben Entwürfe, die der PO prüft.
Vertrauliche Informationen gehören ausschließlich in dafür freigegebene Systeme. Ein Tool übernimmt weder die Priorisierungsentscheidung noch die Verantwortung dafür.
Typische Fehler bei KI-Produkten
- Die Demo als Abnahme. Wer die Demo als Abnahme behandelt, lässt die Alltagstauglichkeit ungeprüft. Die Grundlage sollte eine vorab vereinbarte Evaluation mit relevanten Fehlerfällen sein.
- Kein Testset. Ohne Testset lassen sich Verbesserungen kaum belastbar vergleichen. Referenzfälle gehören deshalb vor die systematische Optimierung.
- Lösung statt Problem. „Wir brauchen einen Chatbot“ ersetzt keine Problemklärung. Die Aussage legt die Lösung zu früh fest. Zuerst müssen Nutzeraufgabe und Erfolgskriterium geklärt sein.
- Betriebskosten ausgeblendet. Bleiben Betriebskosten außen vor, kann selbst eine hilfreiche Funktion wirtschaftlich scheitern. Technischer Aufwand und menschliche Nacharbeit gehören von Beginn an zur Entscheidung.
- Fachbereich nicht eingebunden. Fehlt der Fachbereich, bleibt offen, wer die Qualität beurteilen kann. Vereinbaren Sie Bewertungsverantwortung und verfügbare Kapazität vor der Umsetzung.
- Kein Fallback. Ohne vorgesehenen Umgang mit Fehlantworten landen falsche Ergebnisse direkt bei Nutzern oder im Prozess. Legen Sie vor dem Release fest, wann die Funktion an einen Menschen oder an den bisherigen Ablauf übergibt.
Häufige Fragen
Ist der AI Product Owner eine eigene Scrum-Rolle?
Nein. Der Scrum Guide 2020 kennt nur den Product Owner. „AI Product Owner“ beschreibt einen Product Owner, der ein Produkt mit KI-Funktionen verantwortet. Er bleibt für Produktwert und Product Backlog rechenschaftspflichtig und braucht zusätzlich Wissen zu Evaluation, Daten und Risiken.
Muss ein AI Product Owner programmieren können?
Nicht zwingend. Er sollte technische Aussagen gut genug verstehen, um Annahmen, Grenzen und Alternativen zu hinterfragen. Modellverfahren und technische Bewertung übernehmen Data Scientists und ML Engineers, die fachliche Richtigkeit beurteilt der Fachbereich.
Wie formuliert man Acceptance Criteria für eine KI-Funktion?
Kombinieren Sie zwei Arten: Für Berechtigungen, Datenschutz und Fallbacks gelten feste Kriterien, etwa dass nicht berechtigte Inhalte nie ausgegeben werden. Für die Antwortqualität vereinbaren Sie vor der Auswertung eine Schwelle auf einem festen Testset, zum Beispiel für fachliche Richtigkeit und Quellenbezug.
Braucht jedes KI-Projekt einen eigenen Product Owner?
Nicht unbedingt. Ist die KI-Funktion Teil eines bestehenden Produkts, verantwortet sie meist dessen Product Owner. Fehlt ihm Wissen zu Evaluation oder Daten, helfen eine enge Zusammenarbeit mit Data Scientists und gezielter Kompetenzaufbau oft mehr als eine neue Stelle.
Fazit: Erst die Entscheidungsgrundlage, dann die KI-Funktion
Ein AI Product Owner bleibt für den Produktwert verantwortlich. Was sich ändert, sind die nötigen Nachweise, die Abhängigkeiten und die Bedingungen einer verantwortbaren Freigabe.
Produktklärung lässt sich mit AI Product Engineering verbinden. Wir übersetzen fachliche Anforderungen in überprüfbare Produktentscheidungen und betreibbare KI-Funktionen. Unser Ziel ist eine Funktion, die im Alltag Ihrer Nutzer trägt.
Können Sie Problem, Datenbasis, Qualitätsmessung, Fallback und Kostenmodell benennen? Wo Antworten fehlen, liegen konkrete Discovery-Aufgaben. Diese sollten Sie klären, bevor Sie weiter in die Umsetzung investieren.
