Warum die ROI-Frage bei KI anders läuft

Klassische IT-Vorhaben lassen sich meist anhand definierter Deliverables bewerten: Ein System wird eingeführt, die Lizenzen sind bekannt, die Einführungskosten kalkulierbar, der Nutzen liegt oft auf der Prozessseite. KI-Projekte verhalten sich anders. Der Aufwand verteilt sich nicht nur auf Software, sondern auch auf Daten, Qualitätssicherung und Betrieb. Der Nutzen entsteht selten durch ein einzelnes Feature, sondern durch viele kleine Effekte über mehrere Bereiche hinweg.

Das macht die Wirtschaftlichkeitsfrage nicht unbeantwortbar, aber anspruchsvoller. Wer nur Lizenzkosten gegen eingesparte Stunden rechnet, kommt schnell auf Zahlen, die entweder zu optimistisch oder zu pessimistisch sind. Ein belastbarer Business Case braucht mehr Disziplin: klare Bezugseinheiten, realistische Kosten- und Nutzenabschätzung und eine ehrliche Einschätzung der Faktoren, die sich nicht leicht quantifizieren lassen.

Drei Ebenen der Wirtschaftlichkeit

In der Praxis lohnt sich eine Unterscheidung auf drei Ebenen. Die erste Ebene ist der einzelne Use Case: Kostet ein konkreter KI-Assistent über zwei oder drei Jahre weniger, als er an Zeit oder Zusatzqualität liefert? Diese Frage ist am einfachsten zu bewerten, weil sich die Bezugsgrößen klein halten lassen.

Die zweite Ebene ist die Plattform: Wenn mehrere Use Cases auf derselben Grundlage aufsetzen, wird das Verhältnis zwischen einmaligen Plattformkosten und wiederkehrendem Nutzen relevant. Ein Retrieval-System, Monitoring, Berechtigungen und Tests sind Investitionen, die sich über mehrere Anwendungen amortisieren. Diese Sicht erklärt, warum der dritte oder vierte Use Case meist schneller und günstiger wird als der erste.

Die dritte Ebene ist das Portfolio: Über mehrere Fachbereiche und Vorhaben hinweg betrachtet, zeigt sich, ob die gesamten KI-Investitionen eine sinnvolle Wirkung entfalten oder ob das Unternehmen viele kleine Inseln mit überschaubarem Einzelnutzen betreibt. Erst die Portfolioebene macht strategische Aussagen möglich.

Kosten: die Blöcke, die regelmäßig fehlen

In Business Cases tauchen fast immer Modellkosten und Entwicklungsaufwand auf. Vier Blöcke fehlen dagegen häufig. Erstens: Datenaufbereitung. Bestehende Inhalte müssen gesichtet, strukturiert, entdoppelt und regelmäßig aktualisiert werden. Diese Arbeit ist selten technisch anspruchsvoll, aber zeitintensiv und oft unterschätzt.

Zweitens: Qualitätssicherung. Testdatensätze, Regressionsprüfungen, Monitoring und die Pflege aller dieser Artefakte sind kein einmaliger Aufwand. Sie gehören zum Betrieb und skalieren mit der Anzahl der Use Cases. Drittens: Betrieb und Support. Produktive KI braucht Zuständigkeiten für Nutzerfragen, für Änderungen und für Vorfälle. Diese Arbeit verteilt sich typischerweise auf mehrere Teams, was die Kalkulation erschwert.

Viertens: Organisation und Enablement. Schulungen, Abstimmungen, neue Rollen, Abstimmung mit Fachbereichen — all das ist weicher als Lizenzen, aber real. Wer diese Blöcke nicht einpreist, bekommt einen Business Case, der rechnerisch stimmt und im Alltag nicht.

Nutzen: harte und weiche Effekte

Der harte Teil des Nutzens ist gut bekannt: eingesparte Bearbeitungszeit, kürzere Durchlaufzeiten, reduzierte Fehlerquote, reduzierte Anfragen in nachgelagerten Teams. Wenn diese Effekte auf einen konkreten Use Case bezogen werden, lassen sie sich realistisch schätzen — am besten mit einem Referenzfall, der gemessen wurde, bevor der Assistent eingeführt wurde.

Weicher, aber real: schnellere Reaktionszeiten gegenüber Kundschaft, höhere Datenqualität im CRM, spürbare Entlastung von Fachexpertise für anspruchsvollere Aufgaben, bessere Einarbeitung neuer Mitarbeitender. Diese Effekte treten oft später ein, wirken aber nachhaltiger. Ein ehrlicher Business Case benennt sie, ohne sie zu überbewerten, und trennt sie sauber von den harten Einsparungen.

Ein Business Case, der hält

Vier Eigenschaften kennzeichnen einen belastbaren KI-Business-Case. Erstens: klar benannte Bezugseinheiten. „Wir senken die durchschnittliche Bearbeitungszeit pro Ticket um X Minuten" ist stärker als „wir werden effizienter". Zweitens: definierter Zeithorizont, in der Regel mindestens drei Jahre. Viele Effekte werden im ersten Jahr überschätzt und in den Folgejahren unterschätzt.

Drittens: Einrechnung der versteckten Kostenblöcke. Wer Qualität und Betrieb systematisch einpreist, kommt zu Zahlen, die nicht nach einem halben Jahr kollabieren. Viertens: Szenarien statt Punktschätzungen. Ein Business Case mit Min-, Erwartungs- und Max-Szenario erklärt das Risiko, statt es zu verstecken. Genau diese Art strukturierter Bewertung ist Kernbestandteil unserer Arbeit im AI Consulting.

Messen im Betrieb: was wirklich etwas aussagt

Der ROI wird nicht im Powerpoint entschieden, sondern im Alltag. Deshalb lohnt sich eine frühe Festlegung, was genau gemessen wird, bevor die Anwendung live geht. Typische Kennzahlen: Dauer bis zur ersten nützlichen Antwort, Anteil an Fällen ohne menschliches Nacharbeiten, Anzahl der Folgeanfragen pro Fall, Zufriedenheit der Nutzer auf einer kurzen Skala, Anteil sauber weitergereichter Eskalationen.

Wichtig ist die Vergleichsgruppe. Ein Assistent, der 1000 Fälle im Monat bearbeitet, liefert noch keine Aussage über seinen Beitrag, solange nicht klar ist, was im Vergleichsfall passiert wäre. Kontrollgruppen oder Vorher-Nachher-Messungen mit derselben Datenbasis liefern belastbarere Aussagen als bloße Aktivitätszahlen. Diese Messung hat Überschneidungen mit LLM-Qualitätssicherung, aber einen anderen Fokus: dort geht es um Antwortqualität, hier um den geschäftlichen Beitrag.

Build, Buy und die ROI-Rechnung

Die Entscheidung zwischen Eigenentwicklung und gekaufter Lösung verändert die Kostenstruktur grundsätzlich. Gekaufte Lösungen haben niedrigere Einstiegskosten, dafür laufende Lizenzen, die mit Nutzerzahl skalieren. Eigene Entwicklungen haben höhere Initial- und Betriebskosten, dafür geringere Grenzkosten pro Use Case, wenn die Plattform trägt.

Für den Business Case ist wichtig, diese Unterschiede nicht zu vermischen. Eine Drei-Jahres-Rechnung zu einer gekauften Lösung gegen eine Ein-Jahres-Rechnung zu einer Eigenentwicklung ist wenig aussagekräftig. Wer diese Frage strukturiert behandeln will, findet mehr dazu in unserem Artikel Build vs. Buy bei KI-Assistenten.

Typische Fehler in KI-Business-Cases

Der häufigste Fehler ist, alle Effizienzgewinne als Einsparung zu rechnen. In den meisten Organisationen führt eingesparte Zeit nicht direkt zu weniger Personalkosten, sondern zu mehr Bearbeitungszeit für anspruchsvollere Aufgaben. Das ist real, aber anders zu kalkulieren als eine direkte Personalreduktion.

Der zweite Fehler ist, den Initialaufwand einmalig anzusetzen. Viele Investitionen in KI sind wiederkehrend: Datenaufbereitung, Tests, Modellwechsel, Prompt-Pflege. Ein Business Case mit einmaligem Investment und laufendem Nutzen ist fast immer zu positiv.

Der dritte Fehler ist, den Nutzen zu zentralisieren. Ein Assistent, der in Service, Vertrieb und Backoffice Wirkung zeigt, kann in drei getrennten Business Cases auftauchen — oder in einem zusammengeführten. Welche Sicht richtig ist, hängt vom Entscheidungskontext ab. Wichtig ist, die Zuordnung bewusst zu treffen, nicht sie dem Zufall zu überlassen.

Der vierte Fehler ist, den Business Case nach der Einführung nicht zu aktualisieren. Reale Zahlen weichen fast immer von Schätzungen ab. Ohne regelmäßige Gegenüberstellung bleibt ein einmaliger Business Case ein Dokument, das niemand mehr ernst nimmt, während die eigentliche Erkenntnislage im Dunkeln bleibt.

Wann professionelle Unterstützung sinnvoll ist

Für einen einzelnen, klar geschnittenen Use Case lässt sich ein tragfähiger Business Case oft intern erstellen, wenn die Fachbereiche ehrlich am Tisch sind. Sobald aber mehrere Use Cases, eine Plattform und strategische Fragen zusammenkommen, zahlt sich ein Blick von außen aus. Nicht, um die Zahlen aufzuhübschen, sondern um die Bezugsgrößen, Kosten- und Nutzenrechnung sauber zu strukturieren und Vergleichbarkeit zwischen Vorhaben herzustellen.

Wir arbeiten mit Unternehmen, die KI-Investitionen bewusst steuern wollen: von der Einordnung einzelner Use Cases über die Bewertung einer gemeinsamen Plattform bis zur Portfolio-Sicht über mehrere Bereiche. Wenn Sie vor einer solchen Entscheidung stehen, lohnt es sich, die Wirtschaftlichkeitsfrage früh zu strukturieren, bevor sich Pfade verhärten, die später nur schwer zu korrigieren sind.