KI-Use-Cases auswählen, die sich wirklich rechnen

Inzwischen hat jede IT-Organisation, mit der ich spreche, einen Rückstau an KI-Ideen. Das Brainstorming war der einfache Teil, die Wände hängen voller Use Cases. Der schwere Teil ist die Auswahl, und sie ist folgenreicher, als sie aussieht: Die Differenz zwischen einem guten und einem schlechten ersten Use Case entscheidet häufig darüber, ob die gesamte Initiative ihre Finanzierung behält.

Nach einigen Jahren mit diesen Projekten hat sich mein Filter auf vier Fragen eingependelt. Sie sind unspektakulär, aber sie sortieren zuverlässig.

Frage 1: Wie oft passiert es?

Automatisierung verdient pro Vorgang. Eine Aufgabe, die fünfzig Mal am Tag anfällt, schlägt eine beeindruckende, die zweimal im Monat vorkommt, fast unabhängig davon, wie lange die seltene dauert. Das klingt banal, wird aber in Workshops systematisch ignoriert, weil die seltenen Fälle die besseren Geschichten abgeben. Der Major-Incident-Bericht ist erzählerisch attraktiver als die fünfzigste Passwort-Anfrage, wirtschaftlich ist es umgekehrt.

Die Frequenzdaten existieren bereits, in den Incident- und Request-Tabellen der eigenen Instanz. Sie zu ziehen kostet eine Stunde und ersetzt gefühlte Wahrheiten durch Zahlen. Bei der Topic-Auswahl für den Virtual Agent gilt übrigens dieselbe Logik, das Prinzip ist übertragbar.

Frage 2: Wie messbar ist das Ergebnis?

Wenn sich vor dem Start nicht sagen lässt, wie Erfolg in Zahlen aussieht, wird hinterher darüber gestritten. Lösungszeit, Bearbeitungszeit pro Ticket, Akzeptanzrate der Vorschläge, abgelenkte Kontakte: Die Metrik wird zuerst gewählt, dann wird gebaut, und die Baseline wird vor dem Go-live gemessen, nicht danach rekonstruiert.

Dieser Punkt hat einen unterschätzten Nebeneffekt. Use Cases, deren Erfolg sich nicht messen lässt, sind oft auch fachlich unscharf. Die Messbarkeitsfrage entlarvt sie früh, bevor Budget hineinfließt.

Frage 3: Wie schlimm ist eine falsche Antwort?

Diese Frage trennt die Use-Case-Kategorien sauberer als jede Technologie-Diskussion. Eine mittelmäßige Zusammenfassung kostet ein Achselzucken. Ein falscher Wissensvorschlag kostet einen Klick. Eine falsche automatisierte Änderung an einem Produktivsystem kostet ein Wochenende, manchmal mehr.

Die Konsequenz für die Reihenfolge: dort anfangen, wo Fehler billig und sichtbar sind, Vertrauen verdienen, dann die Risikoleiter hochklettern. Das deckt sich mit dem Prinzip der abgestuften Autonomie: lesende und vorschlagende Use Cases zuerst, schreibende mit Kontrolle, nach außen wirkende zuletzt. Organisationen, die diese Leiter überspringen, bezahlen die Abkürzung fast immer mit einem Vorfall, der die gesamte Initiative zurückwirft.

Frage 4: Taugen die Daten darunter?

Die am häufigsten übersprungene Frage. Ein KI-Use-Case erbt die Qualität der Daten, auf denen er arbeitet: Zusammenfassungen erben die Ticket-Hygiene, Wissensantworten erben die Knowledge Base, Agenten erben die CMDB. Wenn die Datenlage im betroffenen Bereich schlecht ist, gibt es zwei ehrliche Optionen: erst die Daten in Ordnung bringen oder einen anderen Use Case wählen. Die dritte Option, es trotzdem zu versuchen, produziert verlässlich die Demo, die nach drei Monaten niemand mehr nutzt.

Was nach dem Filter übrig bleibt

Lässt man eine typische Ideenliste durch diese vier Fragen laufen, dünnt sich das Feld schnell aus. Was erfahrungsgemäß übrig bleibt: Zusammenfassungen in Warteschlangen mit hohem Volumen, Triage-Unterstützung, Wissensbereitstellung während der Incident-Bearbeitung und eine Handvoll eng umrissener Agenten-Szenarien mit überwiegend lesendem Fußabdruck. Das ist weniger glamourös als die Vision vom vollautomatischen Service Desk, aber es rechnet sich, und es trägt die Vision, statt sie zu verbrennen.

Der eigentliche Zweck des ersten Use Case

Ein letzter Gedanke, der bei der Priorisierung oft fehlt. Der erste Use Case hat in Wahrheit weniger mit Rendite zu tun als mit Glaubwürdigkeit. Er ist der Beweis, an dem die Organisation entscheidet, ob sie dem Thema traut.

Deshalb lohnt ein zusätzliches Kriterium: Wähle etwas, das die Skeptiker im eigenen Haus in ihrer täglichen Arbeit bemerken. Nicht die Innovationsabteilung, die ohnehin überzeugt ist, sondern die Service-Desk-Mannschaft, die schon drei Tool-Einführungen überlebt hat. Bekehrte Skeptiker sind die besten Botschafter, die eine KI-Initiative bekommen kann, und sie sind durch keine Management-Präsentation zu ersetzen.