+190 XP

GenAI Use Cases und Wertbeitrag im Unternehmen

# GenAI Use Cases und Wertbeitrag im Unternehmen

2023 hat eine global aufgestellte Privatkundenbank in neun Monaten 47 Proofs-of-Concept für generative KI aufgesetzt. Achtzehn Monate später waren genau drei davon in Produktion. Die anderen 44 starben an einem Ort, den der CDO der Bank heute "den Demo-Friedhof" nennt: ein Shared Drive voller Streamlit-Apps, die ein Steering Committee einmal beeindruckt haben und danach nie wieder angefasst wurden. Der Postmortem legte das Muster offen: Fast jedes gescheiterte Projekt war ausgewählt worden, weil es *technisch interessant* oder *im Management sichtbar* war, nicht weil jemand modelliert hatte, wo der Wert tatsächlich anfällt und wer nach dem Applaus die Verantwortung trägt.

Das ist das Kernproblem des CDO mit GenAI. Die Technologie demonstriert sich wunderbar und liefert ohne disziplinierte Auswahl fast nichts. Ihre Aufgabe ist nicht, Experimente zu fahren, das haben Ihre Grundlagen abgedeckt. Ihre Aufgabe ist, ein Portfolio zu bauen, das sich aufsummiert. Das verlangt andere Urteile als jede frühere Dateninitiative, denn GenAI kehrt mehrere Ihrer bisherigen Annahmen um.

Warum GenAI Ihre bestehenden Priorisierungsinstinkte aushebelt

Sie wissen längst, wie man Analytics-Projekte priorisiert: Wert schätzen, Kosten schätzen, mit Machbarkeit gewichten, nach Abhängigkeiten sequenzieren. GenAI verletzt drei der Annahmen, die unter dieser Methode liegen.

Die Grenzkosten sind nicht null, sie sind variabel und oft unvorhersehbar. Ein klassisches BI-Dashboard kostet gleich viel, ob es 10 oder 10.000 Nutzer bedient. Ein GenAI-Feature kostet pro Token, pro Call, pro Retrieval. Ein Summarization-Tool, das im Pilot mit 50 Nutzern günstig aussieht, kann im Enterprise-Maßstab zu einem sechsstelligen Monatsposten werden, besonders wenn Sie es auf einem Frontier-Modell gebaut haben und einen Aufpreis für Reasoning zahlen, das Sie eigentlich nicht brauchen. Unit Economics müssen *ab Tag eins* Teil der Use-Case-Auswahl sein, nicht ein Nachgedanke beim Skalieren.

Genauigkeit ist probabilistisch, also enthält die Wertgleichung einen Fehlerkosten-Term, den Sie nicht ignorieren können. Die relevante Frage ist nie "funktioniert es?" Es funktioniert oft genug für eine Demo. Die Frage ist: *Was kostet eine falsche Antwort, und wer fängt sie auf?* Ein GenAI-Tool, das Marketingtexte entwirft, hat triviale Fehlerkosten, ein Mensch prüft, und das Schlimmste ist ein verworfener Entwurf. Dieselbe Fähigkeit, angewandt auf die Zusammenfassung der Medikationshistorie eines Patienten, hat katastrophale Fehlerkosten. Gleiche Technologie, radikal anderes Wertprofil, getrieben allein von der Konsequenz eines Fehlers.

Der Moat ist selten das Modell. Jeder kann dieselbe API aufrufen wie Sie. Dauerhafter Vorteil kommt aus dem, was Sie um das Modell herum bauen: proprietäre Daten, domänenspezifische Evaluation, Workflow-Integration und das gesammelte Feedback, mit dem Sie intelligent tunen und routen können. Wenn Sie einen Use Case bewerten, fragen Sie, welchen Teil davon ein Wettbewerber bis zum nächsten Quartal *nicht* replizieren könnte. Lautet die Antwort "keinen", bauen Sie ein Feature, kein Asset.

Halten Sie diese drei Verschiebungen fest, variable Kosten, Fehlerkosten-Gewichtung und Ort des Moats, denn jedes folgende Framework baut darauf auf.

Ein Zwei-Achsen-Framework, um Wert von Theater zu trennen

Tragen Sie jeden Kandidaten-Use-Case auf zwei Achsen ein. Die erste ist Wertkonzentration: Greift dieser Use Case einen großen, messbaren Kosten- oder Umsatzpool an, oder verstreut er kleine Annehmlichkeiten über die Organisation? Die zweite ist Fehlertoleranz: Was kostet ein falscher Output, und wie eingegrenzt sind diese Kosten?

Daraus ergeben sich vier Quadranten, und jeder verlangt ein anderes Vorgehen.

Hoher Wert, hohe Fehlertoleranz, hier zuerst bauen

Das ist der fruchtbare Boden, und genau hier starten die meisten Unternehmen *nicht*, weil es weniger glamourös ist als das Riskante. Denken Sie an Agent Assist im Contact Center, das Antworten entwirft, die ein Mensch verschickt, Code-Completion für Entwickler, Extraktion von Vertragsklauseln mit einem Anwalt in the loop oder Erstentwürfe für Wissensarbeit mit hohem Volumen. Der Wertpool ist real und groß; der Mensch in the loop absorbiert die Fehlerkosten.

Der klassische Referenzpunkt ist Klarnas Kundenservice-Assistent, der laut Unternehmen das Volumen von hunderten Agents abgearbeitet hat. Funktioniert hat das nicht wegen der Modellraffinesse, sondern weil der Use Case genau in diesem Quadranten saß: enormes, messbares Ticketvolumen (konzentrierter Wert) mit menschlichen Eskalationspfaden und einer abgegrenzten Domäne (eingegrenzte Fehlerkosten). So sieht eine erste Wette aus.

Hoher Wert, niedrige Fehlertoleranz, bauen, aber entsprechend architekturieren

Autonome Finanzabstimmung, klinische Entscheidungsunterstützung, automatisiertes Underwriting. Der Preis ist groß, aber eine falsche Antwort ist teuer oder gefährlich. Diese sind *nicht* tabu, hier liegen langfristig die größten Vorteile, aber sie verlangen Investitionen in Guardrails, Evaluation Harnesses, menschliche Review-Gates und oft ein "Confidence Routing"-Design, bei dem das System nur oberhalb einer kalibrierten Sicherheitsschwelle autonom handelt und alles andere eskaliert. Sequenzieren Sie diese, *nachdem* Sie im sichereren Quadranten organisatorische Muskeln aufgebaut haben.

Niedriger Wert, hohe Fehlertoleranz, der Demo-Friedhof

Der interne "Chat mit unserem Wiki"-Bot. Der Meeting-Summarizer, dem niemand genug vertraut, um das Meeting zu überspringen. Diese sind günstig zu bauen, sicher im Betrieb und leicht zu demonstrieren, und genau deshalb metastasieren sie. Sie erzeugen Aktivität und verbrauchen Roadmap, ohne eine Zahl zu bewegen, die irgendjemand dem Board berichtet. Beenden Sie sie schnell oder bündeln Sie sie in ein Platform-Vorhaben, aber lassen Sie sie nie Ihr Portfolio verankern.

Niedriger Wert, niedrige Fehlertoleranz, vermeiden

Hohes Risiko, geringer Ertrag. Landet ein Use Case hier, ist die einzig richtige Handlung, ihn nicht zu machen, oder den Workflow so umzubauen, dass die Fehlerkosten sinken, bevor Sie ihn anfassen.

Die Disziplin, die dieses Framework erzwingt: *Sie rechtfertigen einen Use Case nie allein mit Machbarkeit.* "Wir können es bauen" gehört in keinen Quadranten. Wert und Fehlerkosten sind die einzigen Zulassungskriterien.

Das Portfolio scoren: von Quadranten zur Rangliste

Quadranten sortieren; sie ranken nicht. Um ein Portfolio zu sequenzieren, übersetzen Sie jeden überlebenden Kandidaten in vier Zahlen, die Ihr CFO und Ihr Board wiedererkennen.

1. Wertpool ($): Die adressierbaren Kosten oder Umsätze, die der Use Case berührt, multipliziert mit einer realistischen Capture Rate. Seien Sie brutal bei der Capture Rate, ein Tool, das jedem Analysten 30 Minuten pro Tag spart, schafft nur Wert, wenn diese Zeit in Output oder Headcount umgesetzt wird, nicht wenn sie in längeren Kaffeepausen verdampft. Modellieren Sie den *realisierten* Wert, nicht den theoretischen.

2. Unit Economics im Maßstab ($ pro Transaktion): Schätzen Sie die Kosten pro nutzbarem Output beim prognostizierten Volumen, mit dem Modell, das Sie tatsächlich deployen würden, nicht mit dem Flaggschiff-Modell, mit dem Sie prototypisiert haben. Die meisten Produktions-Use-Cases laufen gut auf kleineren oder Open-Weight-Modellen, sobald Retrieval und Prompting getunt sind.

3. Fehlerkosten-Exposure: Die erwarteten Kosten eines falschen Outputs, Fehlerwahrscheinlichkeit mal Konsequenz mal Volumen, minus dem, was Ihre Review-Schicht abfängt. Hier erzwingen Sie das Confidence-Gespräch, bevor gebaut wird.

4. Moat-Beitrag: Summiert sich dieser Use Case auf? Erzeugt er proprietäre Feedbackdaten, vertieft er ein Workflow-Lock-in oder baut er wiederverwendbare Platform-Fähigkeiten? Ein Use Case mit moderatem Wert, der eine wiederverwendbare Retrieval- und Evaluation-Plattform aufbaut, kann einen höherwertigen Einzelfall überholen.

Ein einfacher gewichteter Score macht die Tradeoffs explizit und in einem Governance-Forum verteidigbar:

priority_score = (
    value_pool * capture_rate          # realisierter Jahreswert ($)
    - annual_run_cost                  # Tokens + Infrastruktur im Maßstab ($)
    - expected_error_cost              # P(Fehler) * Konsequenz * Volumen ($)
) * moat_multiplier                    # 1.0 Baseline, bis ~1.5 beim Plattformaufbau

Das Ergebnis ist keine präzise Dollarzahl, behandeln Sie es als Ranking-Instrument. Seine wahre Stärke ist prozedural: Es zwingt die Person, die ein Lieblingsprojekt verteidigt, ihre Capture Rate und ihre Fehlerkosten laut auszusprechen, vor Kollegen. Die Hälfte des Demo-Friedhofs wäre nie ausgehoben worden, wenn Sponsoren eine Capture Rate benennen müssen.

How to Build a Generative AI Strategy for the Enterprise

Watch on YouTube

Noch eine Sequenzierungsregel: Richten Sie Ihre ersten zwei oder drei Produktionswetten auf Use Cases aus, die Infrastruktur teilen. Wenn Ihr höchstgerankter Contact-Center-Tool und Ihr drittplatziertes Vertragsanalyse-Tool beide eine Dokument-Retrieval-Pipeline und einen Evaluation Harness brauchen, wird der zweite durch gemeinsames Bauen deutlich günstiger und Ihr Platform-Moat beginnt sich aufzusummieren. Genau hier schlägt Portfolio-Denken das Projekt-Denken.

Wissenscheck

1. Warum bricht GenAI laut Lektion die traditionelle Analytics-Priorisierung aus Wertschätzung, Kostenschätzung und Machbarkeit?

2. Die Lektion stellt den Einsatz von GenAI für Marketingtexte dem Zusammenfassen der Medikationshistorie eines Patienten gegenüber. Welches Kernkonzept illustriert dieser Vergleich?

3. Was ist laut Lektion die zentrale Aufgabe des CDO bei GenAI?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Annahmen der traditionellen Analytics-Priorisierung aus, die GenAI laut Lektion verletzt.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen aus, die die Argumentation der Lektion dazu wiedergeben, warum so viele GenAI-Proofs-of-Concept auf dem "Demo-Friedhof" landeten.

Wählen Sie alle richtigen Antworten aus.

Das Portfolio so steuern, dass Wert tatsächlich ankommt

Gute Auswahl bringt Ihnen eine gute Roadmap. Wert zu realisieren verlangt drei Governance-Mechanismen, die die meisten Organisationen zu spät anschrauben.

Stage-Gates mit vorab definierten Kill-Kriterien. Jeder Use Case läuft über Pilot → begrenzte Produktion → Skalierung, und *jedes Gate hat eine numerische Schwelle, die vor Arbeitsbeginn gesetzt wird.* Nicht "sieht die Demo gut aus", sondern "erreicht sie X Genauigkeit auf dem Held-out-Evaluation-Set UND liegt innerhalb von Y Kosten pro Transaktion UND zeigt messbare Adoption bei den Zielnutzern". Die Bank am Anfang hatte keine Kill-Kriterien, also starb nichts planmäßig, Projekte hingen als Zombies herum, verbrauchten Budget und produzierten nichts. Vorab festgelegte Kill-Kriterien sind das Gegenmittel zur Sunk-Cost-Paralyse. Die Bereitschaft zu beenden ist selbst eine Wettbewerbsfähigkeit: Sie setzt Kapital frei, um es auf Gewinner zu konzentrieren.

Evaluation als Asset erster Klasse, nicht als Nachgedanke. Für jeden Produktions-Use-Case brauchen Sie ein domänenspezifisches Evaluation-Set, eine kuratierte Sammlung von Inputs mit bekannt guten Outputs, laufend bewertet. Hier lebt Ihr proprietärer Moat physisch. Zwei Wettbewerber, die dasselbe Foundation Model nutzen, unterscheiden sich vollständig darüber, wessen Evaluation Harness besser ist, denn genau das erlaubt Ihnen, Modelle zu tauschen, Prompts zu tunen und Regressionen ohne Angst zu erkennen. Behandeln Sie Ihre Eval-Sets wie Ihre Stammdaten: mit Owner, versioniert und governed. Wenn ein neues Modell erscheint, weiß die Organisation mit starkem Eval Harness innerhalb eines Tages, ob sie wechseln sollte; die Organisation ohne rät.

Wertattribution vor dem Launch verdrahtet. Entscheiden Sie *wie Sie beweisen werden*, dass ein Use Case Wert geschaffen hat, bevor Sie ihn ausliefern. Das heißt, die Baseline jetzt zu instrumentieren, aktuelle Handle Times, aktueller Zyklus von Entwurf bis Veröffentlichung, aktuelle Fehlerquoten, denn sobald das Tool live ist, können Sie die Welt ohne es nicht mehr messen. Wo möglich, fahren Sie ein echtes Holdout: eine Kontrollgruppe, die das Tool nicht bekommt. GitHubs Produktivitätsaussagen zum Coding-Assistenten hatten Gewicht, gerade weil sie mit kontrollierter Messung untermauert waren, nicht mit Bauchgefühl. Vage "Effizienzgewinne" werden von jedem CFO abgeschlagen, der diese Formulierung schon gehört hat; ein verteidigbarer Vorher-Nachher-Vergleich mit Kontrollgruppe ist das, was die nächste Finanzierungsrunde freischaltet.

Diese drei Mechanismen verwandeln ein Portfolio von einer Folie in eine Maschine. Stage-Gates sorgen dafür, dass Kapital zu den Gewinnern fließt. Evaluation Harnesses bauen den technischen Moat. Wertattribution baut den *Glaubwürdigkeits*-Moat, der das Board dazu bringt, das Programm durch das unvermeidliche Tal nach dem Abklingen der ersten Euphorie weiter zu finanzieren.

Die CDOs, die in drei Jahren weitsichtig wirken, sind nicht die, die die meisten Experimente gefahren haben. Es sind die, die bei den vier Quadranten rücksichtslos waren, die Capture Rates offengelegt haben, die gemeinsame Infrastruktur über ihre Top-Wetten hinweg gebaut haben und die mit Kontrollgruppe und ohne rot zu werden beweisen konnten, welchen Wert jedes Produktionssystem genau geschaffen hat.

Die wichtigsten Erkenntnisse

  • Zulassung erfordert Wert und Fehlerkosten, nie Machbarkeit. "Wir können es bauen" rechtfertigt nichts. Tragen Sie jeden Kandidaten auf Wertkonzentration gegen Fehlertoleranz ein und starten Sie im Quadranten hoher Wert/hohe Toleranz, wo ein Mensch das Risiko absorbiert.
  • Modellieren Sie Unit Economics im Produktionsmaßstab ab Tag eins, mit dem Modell, das Sie tatsächlich deployen würden, nicht mit dem Frontier-Modell aus dem Prototyp. Ein Tool, das im Pilot mit 50 Nutzern günstig ist, kann im Maßstab sechsstellige Monatskosten bedeuten.
  • Zwingen Sie jeden Sponsor, eine Capture Rate und ein Fehlerkosten-Exposure laut zu nennen. Der wahre Wert der Scoring-Übung ist prozedural: Sie beendet Lieblingsprojekte, bevor sie Roadmap verbrauchen.
  • Sequenzieren Sie nach gemeinsamer Infrastruktur. Richten Sie Ihre ersten Wetten auf Use Cases aus, die dieselbe Retrieval-Pipeline und denselben Evaluation Harness nutzen, damit Ihr Platform-Moat sich aufsummiert statt zu zersplittern.
  • Setzen Sie numerische Kill-Kriterien und instrumentieren Sie die Baseline, bevor Sie ausliefern. Vorab festgelegte Gates besiegen die Sunk-Cost-Paralyse, und ein kontrollierter Vorher-Nachher-Vergleich ist die einzige Wertaussage, die Ihr CFO nicht abschlägt.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • KI-Unit-Economics von Tag eins an für den Produktionsmaßstab modellieren
Vollständiges Action Playbook ansehen