So arbeitest du mit dem KI-Entscheidungs-Canvas

Ablauf

So läuft die Arbeit ab

Ein Use Case beginnt meist in einem Workshop: Eine Person moderiert, das Team trägt Notizen in die neun Felder ein. Jede Notiz bekommt eine ID (zum Beispiel N3), einen Typ und einen Status. Drei Regeln gelten: Eine Notiz enthält genau einen Punkt, ein Ziel braucht eine verknüpfte Test-Notiz, und „belegt“ verlangt einen Nachweis mit Geltungsbereich. Typ, Status und Pflichtfelder beschreibt die Anleitung Notizen im KI-Entscheidungs-Canvas.

• Verknüpfungen. Ein Ziel lässt sich mit einem Test verbinden, etwa Test N11 mit Ziel N3. So ist nachvollziehbar, was geprüft werden soll, ob die Prüfung stattgefunden hat und was herauskam.
• Review (Reiter „Offene Punkte“). Es meldet konkrete Lücken: eine belegt-Notiz ohne Nachweis, eine offene Notiz ohne Verantwortlichen, ein Ziel ohne verknüpften Test, ein Typ, der nicht zum Feld passt. Die Meldungen sind Hinweise, keine Bewertung: „Anzahl ist kein Risikowert.“ Gleichartige Hinweise sind gruppiert („11× Verantwortliche Person fehlt“), ein Kurzcheck zeigt zuerst nur die wichtigsten Regeln, und fehlende Verantwortliche oder Termine trägst du für die ganze Gruppe auf einmal ein.
• Entscheidung. Am Ende stehen ein Ergebnis (zum Beispiel Pilot unter Bedingungen starten oder Stoppen), Empfehlung, Bedingungen, die entscheidungsbefugte Person oder Instanz und der Termin der nächsten Entscheidung.
• Sichern. Der Fall lässt sich als JSON, Markdown-Entscheidungsnotiz und Prüfaufträge (CSV oder Backlog-Markdown) exportieren und als PDF drucken. Über das Speichern-Symbol legst du Versionsstände an, vergleichst sie mit dem aktuellen Arbeitsstand und stellst sie wieder her (vorher sichert die App deinen aktuellen Stand automatisch). Das sind lokale Momentaufnahmen, keine revisionssichere Historie. Formate und Versionsstände beschreibt die Anleitung Speichern, Exportieren und Versionsstände.

Den Fall mit allen neun Feldern zeigt der Beitrag Beispielfall: Der interne Wissensassistent Schritt für Schritt.

Rollen

Wer damit arbeitet

Der Canvas ist kein Formular, das ein Product Owner allein ausfüllt und an die Umsetzung weitergibt. Am besten bearbeiten ihn Produkt, Fachbereich und Engineering gemeinsam. Die Moderation kann ein PO, Technical PO oder eine andere geeignete Person übernehmen. Sie hält Problem, Nutzen und nächste Entscheidung zusammen.

Nicht jede Rolle braucht eine eigene Person. Fehlt Kompetenz, steht das als offene Voraussetzung im Canvas und wird nicht durch Vermutungen ersetzt. Datenschutz, Informationssicherheit, Betrieb und UX kommen nach Bedarf dazu. Die interdisziplinäre Zusammenarbeit und die klare Zuordnung von Verantwortung orientieren sich am NIST AI Risk Management Framework. Der konkrete Workshopablauf ist mein eigener Vorschlag.

Ein externer PO oder Berater kann moderieren und macht dabei transparent, was vom Kunden stammt, was seine eigene Einschätzung ist und welche unabhängige Fachprüfung nötig bleibt.

Zeitpunkte

Wann der Canvas eingesetzt wird

• Vor einer größeren Umsetzungszusage: Verstehen wir Problem, Alternativen und Voraussetzungen gut genug, um einen sinnvollen Test zu planen?
• Nach einem ersten technischen Test: Welche Annahmen wurden gestützt, welche widerlegt? Rechtfertigt die Evidenz einen begrenzten Pilot?
• Nach dem Pilot: Qualität, Nutzung, Prüfaufwand und Kosten gemeinsam betrachten. Weiterbetreiben, verändern, erweitern oder stoppen?
• Bei wesentlichen Änderungen wie neuen Datenquellen, Schreibrechten, Nutzergruppen, Modellen oder zusätzlicher Autonomie: Gelten die bisherigen Annahmen und Grenzen noch?

Der Canvas bleibt damit eine versionierte Übersicht und kein einmaliges Workshop-Ergebnis.

Einstieg

Die erste Sitzung

Der PO bereitet einen konkreten Use Case vor, nicht die gesamte KI-Strategie. Die erste Sitzung dauert nach meinem Vorschlag höchstens 90 Minuten und endet mit einem nächsten Schritt, Verantwortlichen und einer Entscheidungsfrage statt mit einer vollständigen Planung. Die neun Felder sind eine Gesprächsstruktur und müssen nicht in einer Sitzung vollständig beantwortet werden. Vorbereitung, Zeitbox und Rollen beschreibt die Anleitung Die erste Sitzung im KI-Entscheidungs-Canvas.

Ergebnis

Welche Entscheidungen möglich sein müssen

Ein gutes Ergebnis ist nicht zwingend die Freigabe eines KI-Projekts. Mögliche Entscheidungen sind: keine zusätzliche KI, zunächst Voraussetzungen klären, eine begrenzte Lösung testen, Umfang oder Architektur ändern, einen Pilot starten, nach einem Pilot begrenzt weiterbetreiben oder erweitern, oder das Vorhaben stoppen. Der Canvas ist keine Aufforderung, möglichst viel KI einzusetzen.

Abgrenzung

Wie der Canvas das Refinement ergänzt

Viele Fragen des Canvas klären Teams auch im Refinement, und für viele KI-Funktionen reicht das. Der Canvas ersetzt diese Arbeit nicht. Er hält die übergreifende Entscheidungsgrundlage an einem Ort fest: ob und unter welchen Bedingungen man eine KI-Lösung baut. Das verteilt sich sonst leicht über mehrere Backlog-Einträge und Zuständigkeiten.

• Akzeptanzkriterien brauchen bei KI mehr als Beispielantworten. Ein Sprachmodell antwortet bei gleicher Eingabe mal richtig, mal falsch, mal überzeugend falsch. Es braucht ein Testset, überprüfbare Qualitätsgrenzen und Regeln für den Betrieb (Felder 02 und 07).
• Die Risiken reichen über die einzelne Story hinaus. Welche Daten darf das System sehen, was landet beim Anbieter, was darf es tun (Felder 04 bis 06)? Dazu kommen Prüfen und Korrigieren durch Menschen, Pflege der Quellen, erneute Tests bei Modellwechseln und laufende Kosten (Feld 08).
• Der Auslöser ist oft eine Lösung, und die Verantwortung bleibt sonst unklar. Wenn „Wir brauchen einen Chatbot“ ankommt, droht man nur noch zu schätzen, statt zu prüfen, ob das Problem so gelöst werden sollte (Felder 01 und 03). Der Canvas hält fest, was belegt, angenommen oder offen war, wer entschieden hat und unter welchen Bedingungen (Feld 09).

Nicht jede KI-Funktion braucht einen eigenen Canvas. Bei einfachen, risikoarmen Anwendungen reicht häufig eine kürzere Prüfung im Arbeitsablauf. Entscheidend sind Daten, Nutzung und Fehlerfolgen, nicht der Funktionsname. Der Canvas lohnt sich vor allem, wenn mindestens eines zutrifft: Die Ergebnisse fließen in Entscheidungen oder an Kunden, das System greift auf vertrauliche Daten zu, es handelt selbst, oder der Gesamtaufwand ist groß.

Ehrlich gesagt

Was der Canvas nicht leistet

Ein ausgefüllter Canvas beweist weder technische Machbarkeit noch wirtschaftlichen Nutzen. Er ersetzt keine Architektur-, Sicherheits-, Datenschutz- oder Rechtsprüfung und ist kein Freigabezertifikat. Er macht sichtbar: Was wissen wir? Was nehmen wir an? Was ist noch offen? Welche Nachweise brauchen wir für die nächste Entscheidung? Die Freigabe von Budget, Pilot und Betrieb trifft die dafür befugte Instanz, auch ein Product Owner kann einen Pilot nur empfehlen.

Der Canvas ist ein eigener, auf Berufserfahrung gestützter Arbeitsentwurf. Das beschriebene Vorgehen ist eine praktische Empfehlung und kein wissenschaftlich nachgewiesenes Erfolgsverfahren. Die lokale Speicherung im Browser ist nicht verschlüsselt und keine Sicherung: Wichtige Fälle sicherst du zusätzlich als JSON-Datei.

Zwei Funktionen fehlen bewusst:

• Kein Reifegrad-Score. Ein Wert wie „87 Prozent bereit“ würde eine Genauigkeit vortäuschen, die der Canvas nicht belastbar ermitteln kann. Er zeigt stattdessen konkrete offene Fragen und Prüfaufträge.
• Kein automatisches Ausfüllen durch ein Sprachmodell. Das Team soll eigene Annahmen formulieren und Wissenslücken erkennen. Plausible Vorschläge eines Sprachmodells könnten diese Lücken in diesem Ablauf verdecken.