Vierzehn KI-Piloten, drei davon im Betrieb, und für keinen gibt es eine belastbare Zahl dazu, was ein abgeschlossener Vorgang kostet. So oder ähnlich sieht die KI-Landschaft vieler Konzerne nach zwei Jahren Experimentieren aus. Die Modelle funktionieren meistens. Was fehlt, ist eine Rechnung, die zeigt, welche dieser Wetten das Unternehmen tragen kann, und genau an dieser Lücke setzt die KI-Geschäftsmodellierung auf Konzernebene an (im Englischen Corporate AI Business Modelling).
Der Ansatz prüft auch, ob sich ein einzelner Anwendungsfall lohnt. Seine eigentliche Frage liegt aber eine Ebene höher: Wie bewertet ein Konzern alle KI-Vorhaben zusammen, welche kommen zuerst, wie gehen sie in Betrieb und wie behält man die Kosten im Griff? Der Unterschied zur klassischen Produktplanung: Mit jeder KI-Funktion kommen neue Kosten, Risiken, Regeln und Anforderungen an das Können der Mitarbeiter ins Haus.
In der Praxis scheitern KI-Initiativen selten daran, dass der technische Kern unbrauchbar wäre. Häufiger erwartet das Unternehmen zu viel Ertrag, rechnet die laufenden Kosten pro Vorgang (Cost-to-Serve) schön oder behandelt KI als Reihe einzelner Projekte. Ein Machbarkeitstest kann überzeugen und trotzdem keine Grundlage für den breiten Einsatz sein. Ein Modell kann im Labortest stark aussehen und im echten Betrieb zu teuer werden. Und ein Team kann kurzfristig Produktivität gewinnen, während Überwachung, Nachtrainieren, Compliance und Support langfristig mehr Komplexität erzeugen, als der Nutzen rechtfertigt.
Deshalb der wichtigste Wechsel im Denken: KI wird als Bündel von Fähigkeiten gesteuert, nicht als Liste von Projekten. Schnelle Einsparungen, bessere Abläufe und Entscheidungen sowie langfristige Wetten auf eigene Modelle, Datenprodukte oder KI-native Umsatzlinien stehen nebeneinander und müssen gegeneinander abgewogen werden. Erst ein gemeinsamer Bezugsrahmen für diese sehr unterschiedlichen Wetten macht aus vielen Projekten ein belastbares KI-Geschäftsmodell für das Gesamtunternehmen.
Ein einzelner Business Case unterschätzt, was KI im Haus verändert
Im Management-Alltag wird diese Sicht selten durchgehalten. Ein häufiger Fehler: Jede KI-Initiative bekommt wie eine normale Produktfunktion ihren eigenen kleinen Business Case. Das greift zu kurz, denn KI wirkt quer durch Abteilungen, Daten und Abläufe.
Ein Assistent im Kundenservice verändert neben den Ticketlaufzeiten auch Eskalationsmuster, Wissenspflege, Trainingsdaten, Qualitätskontrolle und Compliance-Risiken. Ein Empfehlungssystem wirkt über die Conversion hinaus auf die Sichtbarkeit von Angeboten, das Support-Aufkommen und die Wahrnehmung von Fairness. Wer solche Systeme nur lokal bewertet, sieht den Gewinn in der eigenen Abteilung und übersieht die Kosten in der nächsten.
Ein Portfoliomodell ordnet die Investitionen deshalb danach, wie sie Wert schaffen und wann sie sich auszahlen, unabhängig davon, welches Team sie betreibt. Drei Gruppen haben sich bewährt:
- Effizienz- und Automatisierungsinitiativen wie Dokumentenverarbeitung, Klassifikation, Routing oder Support-Automation liefern oft schon innerhalb von zwölf Monaten messbaren ROI.
- Initiativen für ein besseres Kundenerlebnis und Personalisierung verändern, wie Kunden das Produkt nutzen und annehmen. Sie zahlen sich eher mittelfristig aus.
- Strategische KI-Produkte wie eigene Branchenmodelle, ganz auf KI gebaute Produktlinien oder wiederverwendbare Datenplattformen sollen das Unternehmen über mehrere Jahre vom Wettbewerb abheben.
Diese drei Kategorien folgen unterschiedlichen Erfolgslogiken. Misst man sie mit derselben Messlatte, etwa einer Amortisation unter zwölf Monaten, gewinnt immer die Automatisierung, und das Unternehmen baut nie die Fähigkeit auf, die es in drei Jahren braucht. Eine einfache Regel hilft: Jede Kategorie bekommt ein eigenes Budget und ein eigenes Erfolgskriterium, und Initiativen konkurrieren nur innerhalb ihrer Kategorie.
Eine saubere Portfoliosicht zwingt außerdem zur Entscheidung: Welche Initiativen helfen nur kurzfristig, welche nützen vielen anderen Vorhaben mit, und welche wirken bloß spannend? Ohne diese Disziplin wuchert die KI-Landschaft: viele Einzellösungen, wenig Wiederverwendung, lokale Erfolgsgeschichten, aber keine Fähigkeit, die das Unternehmen als Ganzes trägt.
KI lohnt sich dort, wo sie eine vorhandene Stärke verstärkt
Wo man KI einsetzen kann, ist schnell beantwortet: fast überall. Ergiebiger ist die Frage, wo KI die bestehende Differenzierung des Unternehmens verstärken sollte. Wer nach Einsatzmöglichkeiten sucht, findet Dutzende Use Cases. Wer nach strategischer Verstärkung sucht, wird selektiver und investiert meist klüger.
Wie das aussieht, hängt davon ab, worin das Unternehmen stark ist. Liegt die Stärke in proprietären Daten, sollte KI diese Daten in bessere Entscheidungen und schwer kopierbare Erkenntnisse übersetzen. Besteht die Differenzierung in operativer Exzellenz, sollte KI Durchsatz, Genauigkeit und Geschwindigkeit erhöhen. Liegt der Vorteil im Domänenwissen, gehört KI dorthin, wo genau dieses Wissen skaliert oder in Produkte eingebettet werden kann. Und wenn das Kundenerlebnis der entscheidende Hebel ist, muss KI spürbar schnellere und verlässlichere Interaktionen erzeugen; „mehr Intelligenz“ an sich bemerkt kein Kunde.
Für die Wahl zwischen solchen Richtungen braucht es Szenariomodellierung. Es hilft, strategische Optionen als Szenarien zu modellieren, statt sie als abstrakte Richtungen zu diskutieren. Dann zeigt sich früher, welche KI-Wette das Unternehmen technisch, wirtschaftlich und organisatorisch tragen kann.
Für den Anfang genügt ein einfaches Raster. Für jede Option werden erwarteter Wert, Risiko, Zeit bis zum ersten Nutzen und Beitrag zum Fähigkeitsaufbau geschätzt, einmal vorsichtig und einmal optimistisch. Angenommen, Option A bringt vorsichtig gerechnet 0,4 und optimistisch 1,2 Millionen Euro im Jahr, Option B 0,7 und 0,9 Millionen. A sieht auf der Folie besser aus. Wenn das Unternehmen aber in diesem Jahr keinen Fehlschlag verkraften kann, ist B die richtige Wahl. Optionen, die nur im optimistischen Fall tragen, sind Wetten und gehören in das Budget für Wetten; im Effizienztopf haben sie nichts verloren.
Die Eskalationsquote entscheidet über den ROI, nicht der Token-Preis
Kaum eine Größe wird in KI-Initiativen so häufig zu niedrig angesetzt wie Cost-to-Serve. Viele Teams starten mit Piloten, in denen ein Entwickler nebenbei aufpasst und niemand die Nacharbeit zählt. Inferenzkosten pro Anfrage sind der sichtbarste Posten, aber nur einer von vielen.
Auch die Menge an Text pro Anfrage, die Suche in den eigenen Dokumenten (Retrieval), spezielle Datenbanken, je nach Region unterschiedliche Rechenkosten, Überwachung, Nachtrainieren, menschliche Prüfung und Qualitätskontrolle treiben die Betriebskosten nach oben. Entscheidend ist deshalb der Preis eines erfolgreich abgeschlossenen KI-gestützten Vorgangs. Was „das Modell“ kostet, ist nur ein Teil davon.
Was ein abgeschlossener Vorgang wirklich kostet (alle Werte in diesem Abschnitt frei gewählt)
Nehmen wir einen KI-gestützten Ablauf im Kundenservice. Pro Anfrage fallen an:
- Inferenz und Retrieval pro Versuch: 0,05 Euro
- Anteil, der zur menschlichen Nachbearbeitung eskaliert: 20 Prozent
- Kosten je eskaliertem Fall (Bearbeitungszeit): 4,00 Euro
- Umgelegte Betriebskosten (Monitoring, Retraining, Vektor-Infrastruktur): 0,03 Euro pro Anfrage
Cost-to-Serve je abgeschlossener Anfrage:
0,05 € + (0,20 × 4,00 €) + 0,03 € = 0,88 €
Die reine Modellkostensicht hätte nur die 0,05 Euro ausgewiesen, also rund ein Siebzehntel des tatsächlichen Werts. Der eigentliche Kostentreiber ist die Eskalationsquote. Sinkt sie von 20 auf 10 Prozent, fällt der Wert auf 0,48 Euro; steigt sie auf 30 Prozent, klettert er auf 1,28 Euro. Über die Wirtschaftlichkeit entscheidet damit vor allem die Qualität von Retrieval und Prüflogik, weit mehr als der Token-Preis.
Die Stückkosten allein sagen aber noch nicht, ob sich das System lohnt. Dafür fehlen das Volumen und die Fixkosten. Angenommen, ein Fall kostet ohne KI ebenfalls 4,00 Euro, und Plattform, Betriebsteam und Wissenspflege schlagen mit 60.000 Euro im Monat zu Buche. Jede automatisierte Anfrage spart dann 4,00 Euro minus 0,88 Euro, also 3,12 Euro. Die Fixkosten sind erst ab 60.000 geteilt durch 3,12, also rund 19.200 Anfragen im Monat gedeckt. Bei 50.000 Anfragen bleiben etwa 96.000 Euro Einsparung pro Monat. Bei 10.000 Anfragen verliert das System rund 29.000 Euro im Monat, egal wie gut das Modell antwortet. Steigt die Eskalationsquote auf 30 Prozent, rückt die Schwelle auf etwa 22.000 Anfragen.
Daraus folgt eine Entscheidungsregel, die in jedes Investitionskomitee gehört: Liegt das erwartete Volumen nicht mindestens doppelt so hoch wie die Break-even-Menge, läuft die Initiative im Budget für Wetten.
Mit den echten Stückkosten verschiebt sich auch die ROI-Diskussion, denn Einsparungen sind nur eine von vier Wertkategorien. Es gibt direkte Kosteneffekte wie weniger manuelle Bearbeitungszeit und kürzere Rückstände. Es gibt Produktivitätsgewinne, also mehr Durchsatz und geringere Fehlerraten. Es gibt strategische Effekte wie höhere Kundenbindung oder geringeres Compliance-Risiko. Und es gibt zusätzliche Umsätze durch Premium-KI-Funktionen oder KI-native Produktlinien. Schwierig wird es, wenn Unternehmen diese Kategorien vermischen und „ROI“ sagen, obwohl sie vage Effizienzannahmen meinen. Ein belastbares Modell bindet deshalb jede Wertkategorie an eine operative Kennzahl: Bearbeitungszeit in Minuten, Fehlerquote in Prozent, Kündigungsrate im Quartal.
Ein Pilot beweist wenig, solange niemand die Gegenprobe macht
Selbst sauber gerechnete Stückkosten beruhen auf einer Annahme über die Wirkung, und diese Annahme muss ein Pilot erst belegen. Im Konzern reicht dafür ein einfacher Online-Test selten. KI-Systeme verändern zu viele Dinge gleichzeitig: Geschwindigkeit, Fehlermuster, Eskalationslogik, Nutzungsverhalten, Support-Last und manchmal die Zuständigkeiten zwischen Teams.
Skepsis ist schon deshalb angebracht, weil ein typischer Pilot unter Bedingungen läuft, die es im Rollout nicht mehr gibt. Er dauert wenige Wochen, ein motiviertes Team betreut ihn, die Fälle sind oft vorsortiert, und eine Vergleichsgruppe fehlt. Jeder dieser Umstände schiebt das Ergebnis nach oben. Wer in einem Konzern fünf KI-Piloten startet und fünf Erfolgsmeldungen bekommt, sollte also eher die Messung prüfen als die Sektflaschen öffnen.
Ob sich die Investition lohnt, prüft man deshalb auf mehreren Ebenen. Ein Labortest zeigt die Qualität des Modells unter kontrollierten Bedingungen. Ein Pilot mit Vergleichsgruppe zeigt die Wirkung im Alltag. Analysen auf Aufgabenebene machen sichtbar, wo genau Zeit gespart wird. Und Beobachtung über mehrere Monate zeigt, ob der Effekt stabil bleibt oder sich wieder abbaut.
Der tückischste Fall ist der Effekt zweiter Ordnung. Ein Prozess wird schneller, schiebt die Arbeit aber nur in die nächste Abteilung weiter. Im Support-Beispiel könnte das so aussehen: Der Bot schließt 80 Prozent der Anfragen, doch ein Teil der Kunden ruft zwei Tage später erneut an oder beschwert sich schriftlich. Ohne Messung über die Prozessgrenze hinweg, etwa der Wiederkontaktquote innerhalb von 72 Stunden, sieht das wie ein Erfolg aus.
Eine praktikable Regel für das Skalierungsgremium: Ein Pilot erhält nur dann Budget für den Rollout, wenn er eine vorab festgelegte Zielgröße gegen eine Vergleichsgruppe erreicht hat und die wichtigste Gegenkennzahl, etwa Wiederkontakte oder Beschwerden, nicht schlechter geworden ist. Den eigentlichen Wert eines Experimentier-Frameworks macht dieser Schutz vor voreiligen Erfolgsgeschichten aus: Ein Pilot, dessen Erfolg nur Zufall war, kommt gar nicht erst ins Rollout.
Die zweite Anwendung muss billiger sein als die erste
Auch sauber validierte Piloten bringen wenig, solange sie Einzelfälle bleiben. Viele Unternehmen verharren in einer Zwischenwelt: genug KI, um überall Aktivität zu zeigen, aber zu wenig Struktur, um daraus ein tragfähiges System zu machen.
Warum das so teuer ist, zeigt ein Blick in jedes gewachsene ML-System. Der eigentliche Modellcode macht den kleinsten Teil aus. Den Rest bilden Datenaufbereitung, Konfiguration, Überwachung und Infrastruktur, und diese Teile hängen so eng zusammen, dass eine Änderung an einem Merkmal Folgen für Schwellenwerte, Dashboards und nachgelagerte Modelle hat. Wer jeden Piloten mit eigener Pipeline baut, bezahlt diesen Rest bei jedem Anwendungsfall erneut.
Eine Transformations-Roadmap führt in drei Phasen aus der Zwischenwelt heraus.
In der ersten Phase geht es um Discovery. Das Unternehmen identifiziert geeignete Arbeitsabläufe, testet Piloten, bewertet die Datenqualität und beobachtet frühes Modellverhalten. Ein gescheiterter Pilot ist hier ein brauchbares Ergebnis, solange klar wird, woran er gescheitert ist. Oft wirft ausgerechnet die Bestandsaufnahme der Daten den Plan um. Wer diese Phase überspringt, merkt im achten Monat, dass die Datenbasis den Plan nicht trägt.
In der zweiten Phase wird aus Experimenten eine gemeinsame Grundlage. Dazu gehören wiederverwendbare Bausteine für die Textsuche, ein zentrales Verzeichnis aller Modelle, einheitliche Qualitätstests, gemeinsam genutzte Datenmerkmale, Warnungen, wenn ein Modell schlechter wird, sowie Sicherheits- und Compliance-Abläufe. Erst damit lässt sich ein Erfolg wiederholen. Hier entsteht der Hebel, um den es eigentlich geht: Kostet der erste Use Case 100 Einheiten, sollte der dritte auf derselben Plattform deutlich weniger als die Hälfte kosten. Gelingt das nicht, war die Plattform bloß ein weiteres Projekt.
In der dritten Phase skaliert das Unternehmen. KI wird in Geschäftsbereiche integriert, in mehrstufige Abläufe eingebettet und über Modellfamilien hinweg konsolidiert. Wer ohne verlässliche Evaluation, klare Zuständigkeiten und tragfähige Betriebsprozesse skaliert, vervielfacht die Schwächen des Piloten.
Eine messbare Probe für den Übergang von Phase eins zu Phase zwei: Man vergleicht die Entwicklungszeit des jüngsten Use Case mit der des ersten. Sinkt sie nicht spürbar, wird noch immer projektweise gebaut, egal was die Roadmap behauptet.
Fähigkeiten und Governance gehören als Zeilen in den Business Case
Technologie skaliert nicht von selbst. Im Rechenbeispiel hängt fast die gesamte Wirtschaftlichkeit an der Eskalationsquote, und die senkt kein Modell-Update allein. Dafür braucht es Leute, die Retrieval-Fehler erkennen, die Prüflogik nachschärfen und den Effekt sauber messen.
Product Manager müssen dafür wissen, was Modelle nicht können, Daten und Kosten lesen, Tests planen und Teams über Abteilungsgrenzen hinweg steuern. Engineering-Teams müssen weit mehr können, als ein Modell in Betrieb zu nehmen. Sie sorgen dafür, dass es auch bei vielen Anfragen schnell bleibt, merken, wenn es schlechter wird, trainieren es automatisch nach, überwachen es und lassen mehrere Modelle zusammenspielen. Data Science liefert Fehlerkategorien, Testdaten und Prüfungen auf Verzerrungen und erfundene Antworten. Ohne diese Fehlerkategorien und Testdaten bleibt jede Qualitätsvorgabe Papier.
Kompetenzaufbau ist deshalb ein Kostenposten, den jede Initiative mitträgt, und kein Extra, das in der Budgetrunde als Erstes fällt. Die Rechnung dazu liefert das Support-Beispiel selbst: Jeder Prozentpunkt Eskalationsquote kostet 4 Cent pro Anfrage, bei 50.000 Anfragen im Monat also 2.000 Euro. Ein Team, das Retrieval-Fehler nicht lesen kann, drückt keinen dieser Punkte, und eine Schulung, die die Quote um zwei Punkte senkt, hat sich nach wenigen Monaten bezahlt gemacht.
Reife Organisationen verankern diese Fähigkeiten über Lernsysteme: interne KI-Akademien, Gilden, Wissensdatenbanken, Szenariosimulationen. So hängt der Fortschritt nicht an einer Handvoll Fachleute, die jederzeit kündigen können.
Ähnlich verhält es sich mit Governance. Sobald KI geschäftskritische Entscheidungen beeinflusst, lässt sie sich nicht nachträglich ergänzen. Dazu gehören Datensatz-Governance, Modelldokumentation, Regeln für menschliche Prüfung, Risikobewertung, Auditierbarkeit und Versionskontrolle. Das wirkt bürokratisch. Ohne diese Mechanismen werden Systeme mit wachsender Nutzung aber unberechenbar, teuer oder regulatorisch riskant. Gut aufgesetzt erlaubt Governance einem regulierten Unternehmen, den zweiten und dritten Use Case einzuführen, ohne die Vertrauensfrage jedes Mal neu zu verhandeln.
Wichtig ist, dass Risikokategorien explizit modelliert werden. Halluzinationen, Datenschutzfragen, Datenresidenz, Compliance-Verstöße, Modelldegradation, gezielter Missbrauch, Bias und unvorhersehbare Kostenlasten verändern Pricing, Produktgrenzen und operative Anforderungen. Jedes dieser Risiken gehört als eigene Zeile in den Business Case, mit einem Preis.
Im Support-Beispiel hieße das: Jede Halluzination, die erst der Kunde bemerkt, wird zu einem Eskalationsfall für 4,00 Euro, der in der Annahme von 20 Prozent womöglich noch gar nicht steckt. Bemerkt der Kunde jede hundertste falsche Antwort erst nachträglich, steigt die Eskalationsquote um einen Punkt und die Stückkosten um 4 Cent. Ein Risiko ohne Preis kommt später als Kostenblock ohne Budget zurück.
Sechs Spalten zeigen, was dem Portfolio noch fehlt
Die Bausteine der vorigen Abschnitte wirken erst, wenn sie in einem Modell zusammenlaufen. Ein KI-Geschäftsmodell auf Konzernebene führt deshalb sechs Ebenen zusammen. Die strategische Positionierung legt fest, wo Differenzierung entsteht. Die technische Grundlage beschreibt, wie Daten, Modelle, die Steuerung der Abläufe und die Oberfläche zusammenspielen. Das Finanzmodell umfasst Cost-to-Serve, Stückkosten, Margen, Zyklen für das Nachtrainieren und Amortisation. Das Governance-Modell sichert Compliance und Dokumentation über den Lebenszyklus. Das Organisationsmodell klärt Rollen und Reifegrade. Das Experimentiermodell verbindet Offline-Evaluierung, Online-Tests und die Prüfung des Business Case.
Der praktische Nutzen dieser Verknüpfung zeigt sich, sobald sich eine Annahme ändert. Wird ein Modell billiger, kommt eine neue Regulierung oder fällt ein Datenproblem auf, lässt sich die Wirkung durch alle sechs Ebenen verfolgen. Sinkt etwa der Inferenzpreis um die Hälfte, ändert das im Support-Beispiel die Stückkosten nur von 0,88 auf 0,855 Euro. Steigt dagegen die Eskalationsquote um fünf Punkte, wächst derselbe Wert um 20 Cent. Ein verknüpftes Modell zeigt sofort, welche Nachricht die Budgetrunde beschäftigen sollte.
Für den Einstieg reicht eine Liste aller laufenden KI-Initiativen mit sechs Spalten, eine pro Ebene. Für jede Initiative wird eingetragen, welche Differenzierung sie stützt, auf welcher Infrastruktur sie läuft, was ein abgeschlossener Vorgang kostet (einschließlich Eskalationen), welche Kontrollen greifen, wer sie fachlich verantwortet und wie ihr Nutzen gemessen wird. Die leeren Zellen sind das eigentliche Ergebnis der Übung. Eine Initiative ohne belastbare Cost-to-Serve-Zahl oder ohne Messkonzept ist noch nicht reif für ein Skalierungsbudget.
Bleibt die Sorge, dass so viel Steuerung gerade die schnellen Teams ausbremst. Ein Gremium, das jede Initiative durch sechs Spalten schickt, kostet Wochen, und manche der erfolgreichsten KI-Anwendungen sind entstanden, weil ein Team einfach angefangen hat.
Solange ein Unternehmen nur wenige Initiativen hat, die weder Daten noch Infrastruktur teilen, stimmt das, und ein zentrales Modell ist bloßer Mehraufwand. Ab etwa fünf laufenden Initiativen, oder sobald zwei davon auf denselben Datenbestand zugreifen, kippt die Rechnung: Doppelt gebaute Pipelines und widersprüchliche Kennzahlen werden dann teurer als jedes Gremium.
Ist die Liste gefüllt, folgt die Priorisierung. Den größten Use Case zuerst zu finanzieren, liegt nahe, ist aber selten die beste Wahl. Mehr bringt meist die wiederverwendbare Fähigkeit, die das Portfolio als Ganzes tragfähiger macht: ein gemeinsames Evaluierungsframework, ein Feature Store, eine saubere Datenbasis für mehrere Arbeitsabläufe. In der Budgetrunde lautet die Frage dann: Welche leere Zelle schließt ein Use Case, und welche reißt er neu auf? Eine Initiative, die eine Lücke im Evaluierungsframework füllt, kann mehr wert sein als ein Pilot mit doppelt so großem Umsatzversprechen, weil sie die Cost-to-Serve aller anderen Initiativen mitsenkt.