GenAI-Use-Cases im Unternehmen und ihr Wert

2023 stellte eine globale Privatkundenbank in neun Monaten 47 Proofs-of-Concept für generative KI auf die Beine. Achtzehn Monate später waren genau drei davon in Produktion. Die anderen 44 starben an dem Ort, den der CDO der Bank heute "Demo-Friedhof" nennt: ein Shared Drive voller Streamlit-Apps, die einmal ein Steering Committee geblendet haben und danach nie wieder angefasst wurden. Die Nachanalyse zeigte das Muster: **fast jedes tote Projekt war ausgewählt worden, weil es *technisch interessant* oder *auf Vorstandsebene sichtbar* war**, nicht weil jemand modelliert hätte, wo der Wert tatsächlich anfällt oder wer es nach dem Applaus verantwortet.

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 Fundamentals abgedeckt. Ihre Aufgabe ist es, ein Portfolio aufzubauen, das sich verzinst. Das verlangt andere Urteile als jede frühere Dateninitiative, denn GenAI kehrt mehrere Annahmen um, mit denen Sie bisher gearbeitet haben.

Warum GenAI Ihre bisherigen Priorisierungsinstinkte aushebelt

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

Die Grenzkosten sind nicht null, sie sind variabel und oft unvorhersehbar. Ein klassisches BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →-Dashboard kostet gleich viel, ob es 10 oder 10.000 Nutzer bedient. Ein GenAI-Feature kostet pro TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →, pro Call, pro Retrieval. Ein Summarization-Tool, das in einem Pilot mit 50 Nutzern billig aussieht, kann im Enterprise-MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßstab zu einem sechsstelligen Monatsposten werden, vor allem wenn Sie es auf einem Frontier-Modell gebaut haben und einen Aufpreis für Reasoning zahlen, das Sie gar nicht brauchen. Unit Economics müssen *ab Tag eins* Teil der Use-Case-Auswahl sein, nicht ein nachgelagerter Gedanke beim Skalieren.

Genauigkeit ist probabilistisch, also enthält die Wertgleichung einen Fehlerkostenterm, den Sie nicht ignorieren können. Die relevante Frage ist nie "funktioniert es?" Es funktioniert oft genug für eine Demo. Die Frage lautet: *Was kostet eine falsche Antwort, und wer fängt sie ab?* 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 des Irrtums.

Der Burggraben ist selten das Modell. Jeder kann dieselbe APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → aufrufen wie Sie. Dauerhafter Vorteil entsteht 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 kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ö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, Fehlerkostengewichtung und Ort des Burggrabens, denn jedes Framework unten baut darauf auf.

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

Tragen Sie jeden Kandidaten-Use-Case auf zwei Achsen ab. Die erste ist Wertkonzentration: Greift dieser Use Case einen großen, messbaren Kosten- oder Umsatztopf an, oder verteilt ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → kleine Bequemlichkeiten über die Organisation? Die zweite ist Fehlertoleranz: Was kostet ein falscher Output, und wie eingegrenzt sind diese Kosten?

Daraus entstehen 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 Zeug. Denken Sie an Agent Assist im Contact Center, das Antworten entwirft, die ein Mensch versendet, an Code-Completion für Entwickler, an Vertragsklausel-Extraktion mit einem Juristen in the loop oder an 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 der Kundenservice-Assistent von Klarna, der laut Unternehmen ein Volumen im Gegenwert von Hunderten von Agents bewältigte. Was ihn funktionieren ließ, war nicht die Modellraffinesse, es war, dass der Use Case genau in diesem Quadranten lag: enormes, messbares Ticketvolumen (konzentrierter Wert) mit menschlichen Eskalationspfaden und einer klar begrenzten Domäne (eingegrenzte Fehlerkosten). So sieht eine erste Wette aus.

Hoher Wert, geringe Fehlertoleranz, bauen, aber entsprechend architektieren

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 am Ende die größten Vorteile, aber sie verlangen Investitionen in GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen →, Evaluation Harnesses, Human-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**.

Geringer Wert, hohe Fehlertoleranz, der Demo-Friedhof

Der interne "Chat mit unserem Wiki"-Bot. Der Meeting-Summarizer, dem niemand genug vertraut, um das Meeting zu schwänzen. Diese sind billig zu bauen, sicher zu betreiben und leicht zu demonstrieren, und genau deshalb wuchern sie. Sie erzeugen Aktivität und fressen Roadmap, ohne eine Kennzahl zu bewegen, die irgendjemand dem Board berichtet. Töten Sie sie schnell oder bündeln Sie sie in einem Platform Play, aber lassen Sie sie nie Ihr Portfolio verankern.

Geringer Wert, geringe Fehlertoleranz, meiden

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 verbliebenen 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 bei der Capture Rate brutal, ein Tool, das jedem Analysten 30 Minuten pro Tag spart, schafft nur dann Wert, wenn diese Zeit in Output oder Headcount umschlägt, nicht wenn sie in längeren Kaffeepausen verdunstet. 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 dem Flaggschiffmodell, mit dem Sie prototypisiert haben. Die meisten Produktions-Use-Cases laufen problemlos auf kleineren oder Open-Weight-Modellen, sobald Retrieval und PromptingPromptingPrompt Engineering ist die Praxis, Texteingaben so zu gestalten und zu verfeinern, dass große Sprachmodelle präzise, relevante und verlässliche Ergebnisse liefern.Vollständige Definition ansehen → 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 vor dem Bauen.

4. Moat-Beitrag: Verzinst sich dieser Use Case? Erzeugt er proprietäre Feedback-Daten, vertieft er ein Workflow-Lock-in oder baut er wiederverwendbare Plattformfähigkeit auf? Ein Use Case mit moderatem Wert, der eine wiederverwendbare Retrieval- und Evaluationsplattform aufbaut, kann einen höherwertigen Einzelfall überholen.

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

priority_score = (
    value_pool * capture_rate          # realized annual value ($)
    - annual_run_cost                  # tokens + infra at scale ($)
    - expected_error_cost              # P(error) * consequence * volume ($)
) * moat_multiplier                    # 1.0 baseline, up to ~1.5 for platform-building

Das Ergebnis ist keine präzise Dollarzahl, behandeln Sie es als Ranking-Instrument. Seine eigentliche Kraft ist prozedural: Es zwingt die Person, die ein Lieblingsprojekt vorantreibt, ihre Capture Rate und ihre Fehlerkosten laut vor Kollegen zu nennen. Der halbe Demo-Friedhof wäre nie ausgehoben worden, wenn Sponsoren eine Capture Rate hätten nennen müssen.

Noch eine Sequenzierungsregel: Richten Sie Ihre ersten zwei oder drei Produktionswetten auf Use Cases aus, die Infrastruktur teilen. Wenn Ihr bestplatziertes Contact-Center-Tool und Ihr drittplatziertes Vertragsanalyse-Tool beide eine Dokumenten-Retrieval-Pipeline und ein Evaluation Harness brauchen, ist das zweite bei gemeinsamem Bau deutlich billiger und Ihr Plattform-Moat beginnt sich zu verzinsen. Genau hier schlägt Portfoliodenken das Projektdenken.

Das Portfolio so steuern, dass der 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 durchläuft Pilot → begrenzte Produktion → Skalierung, und *jedes Gate hat eine numerische Schwelle, die vor Arbeitsbeginn gesetzt wird.* Nicht "sieht die Demo gut aus", sondern "erreicht es X Genauigkeit auf dem Held-out-Evaluationsset UND bleibt es unter Y Kosten pro Transaktion UND zeigt es messbare Adoption bei den Zielnutzern." Die Bank aus unserem Einstieg hatte keine Kill-Kriterien, also starb nie etwas planmäßig, Projekte hingen als Zombies herum, verbrauchten Budget und produzierten nichts. Vorab festgelegte Kill-Kriterien sind das Gegenmittel gegen Sunk-Cost-Lähmung. Die Bereitschaft zu töten ist selbst eine Wettbewerbsfähigkeit: Sie macht Kapital frei, um es auf Gewinner zu konzentrieren.

Evaluation als erstklassiges Asset, nicht als Nachgedanke. Für jeden Produktions-Use-Case brauchen Sie ein domänenspezifisches Evaluationsset, eine kuratierte Sammlung von Inputs mit bekannten guten Outputs, laufend gescort. Hier wohnt Ihr proprietärer Moat physisch. Zwei Wettbewerber, die dasselbe Foundation Model nutzen, unterscheiden sich allein darüber, wessen Evaluation Harness besser ist, denn das ist es, was Ihnen erlaubt, Modelle zu tauschen, Prompts zu tunen und Regressionen ohne Angst zu erkennen. Behandeln Sie Ihre Eval-Sets wie Ihre Stammdaten: mit Owner, versioniert und governt. Wenn ein neues Modell erscheint, weiß die Organisation mit einem starken Eval Harness binnen eines Tages, ob sie wechseln soll; die ohne rät.

Wertzuordnung vor dem Launch verdrahtet. Entscheiden Sie *wie Sie beweisen werden*, dass ein Use Case Wert geschaffen hat, bevor Sie ihn ausliefern. Das heißt, jetzt die Baseline zu instrumentieren, aktuelle Handle Times, aktueller Draft-to-Publish-Zyklus, 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. Die Produktivitätsangaben von GitHub zu seinem Coding-Assistenten hatten genau deshalb Gewicht, weil sie durch kontrollierte Messung gestützt waren, nicht durch Bauchgefühl. Vage "Effizienzgewinne" werden von jedem CFO abgezinst, der die Phrase schon einmal gehört hat; ein belastbarer 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. Wertzuordnung baut den *Glaubwürdigkeits*-Moat, der das Board dazu bringt, das Programm auch durch das unvermeidliche Tal nach dem Abklingen der Anfangseuphorie zu finanzieren.

Die CDOs, die in drei Jahren weitsichtig aussehen werden, sind nicht die, die die meisten Experimente gefahren haben. Es sind die, die bei den vier Quadranten rücksichtslos waren, die Capture Rates offen erzwungen haben, die geteilte Infrastruktur über ihre Top-Wetten hinweg gebaut haben und die mit einer Kontrollgruppe und ernstem Gesicht genau beweisen konnten, welchen Wert jedes Produktionssystem geschaffen hat.

Wichtigste Erkenntnisse

• Zulassung verlangt Wert und Fehlerkosten, nie Machbarkeit. "Wir können es bauen" rechtfertigt nichts. Tragen Sie jeden Kandidaten auf Wertkonzentration gegen Fehlertoleranz ab 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 dem Frontier-Modell, auf dem Sie prototypisiert haben. Ein Tool, das im Pilot mit 50 Nutzern billig ist, kann im Maßstab sechsstellige Monatskosten verursachen.
• Zwingen Sie jeden Sponsor, eine Capture Rate und ein Fehlerkosten-Exposure laut zu nennen. Der eigentliche Wert der Scoring-Übung ist prozedural: Sie tötet Lieblingsprojekte, bevor sie Roadmap fressen.
• Sequenzieren Sie nach geteilter Infrastruktur. Richten Sie Ihre ersten Wetten auf Use Cases aus, die dieselbe Retrieval-Pipeline und dasselbe Evaluation Harness wiederverwenden, damit Ihr Plattform-Moat sich verzinst statt zu zersplittern.
• Setzen Sie numerische Kill-Kriterien und instrumentieren Sie die Baseline vor dem Launch. Vorab festgelegte Gates besiegen die Sunk-Cost-Lähmung, und ein kontrollierter Vorher-Nachher-Vergleich ist die einzige Wertaussage, die Ihr CFO nicht abzinst.