Ein mittelständischer Händler mit 40 Millionen Euro Jahresumsatz führt im Januar einen internen Copilot für den Kundenservice ein. Sechs Wochen später liegt die erste Rechnung von OpenAI auf dem Tisch. 11.400 Euro. Niemand im Unternehmen kann sagen, welches Team welchen Anteil verursacht hat. Der Product-Owner zeigt auf sein Dashboard, der IT-Leiter auf sein Snowflake-Konto, die Agentur auf ihre Pauschale. Drei Zahlen, drei Wahrheiten, null Steuerbarkeit.
Das ist kein Einzelfall. Es ist der Standard in Unternehmen, die generative KI 2024 und 2025 schnell eingeführt haben, ohne die Kostenarchitektur mitzubauen. GenAI-Ausgaben wachsen nicht linear mit Nutzerzahlen, sondern mit Token-Volumen, Modellwahl und Kontextlänge — drei Variablen, die in den meisten E-Commerce-Stacks nicht auf Abteilungsebene erfasst werden.
Warum wächst der KI-Aufwand schneller als der Umsatz?
Weil die Kostenlogik von LLMs eine andere ist als die von klassischer SaaS. Bei einer Shopify-Plus-Lizenz kennt die Buchhaltung den Preis pro Monat. Bei der OpenAI-API kennt sie nur den Gesamtbetrag, der am Monatsende vom Konto abgeht. Dazwischen liegt eine Blackbox.
Ein einziger Kundenservice-Prompt mit System-Prompt, Produktkatalog-Kontext, Bestellhistorie und Gesprächsverlauf kann 8.000 bis 15.000 Input-Tokens verbrauchen — bevor das Modell überhaupt ein Wort generiert. Wird dieser Prompt für jede Anfrage neu gesendet (was in schlecht gebauten Agenten der Normalfall ist), kostet eine einzige Support-Interaktion bei GPT-4o schnell 4 bis 9 Cent. Bei 50.000 Tickets pro Monat landet man bei 2.000 bis 4.500 Euro — nur für einen Workflow.
Die Kosten wachsen dann, wenn drei Dinge gleichzeitig passieren: mehr Nutzer, längere Kontexte, teurere Modelle. In vielen Häusern passiert genau das parallel, ohne dass jemand die Summe kennt.
Was ist die häufigste Ursache für die Intransparenz?
Die Trennung zwischen Abrechnungsebene und Nutzungsebene. OpenAI, Anthropic, Google und Azure stellen Rechnungen auf Account- oder Organisationsebene. Die Fachteams arbeiten aber auf Anwendungsebene. Zwischen beiden Ebenen fehlt fast immer die Zuordnung.
Wer das auflösen will, braucht drei Bausteine:
- Tagging auf Request-Ebene: Jeder API-Call wird mit Cost-Center, Team, Use-Case und Modellversion markiert. Das bedeutet Instrumentierung im Code, nicht nachträgliche Excel-Aufteilung.
- Token-basierte Metriken: Kosten pro 1.000 Anfragen, pro aktiven Nutzer, pro gelöstem Ticket. Ohne diese Kennzahlen ist jede Optimierung blind.
- Zentrale Sicht: Ein Dashboard, das Multi-Provider-Kosten (OpenAI, Anthropic, Azure OpenAI, Mistral, AWS Bedrock) und Self-Hosting-GPU-Kosten nebeneinanderstellt.
Tools wie Helicone, Langfuse, Portkey oder die kostenlosen Usage-Dashboards der Provider decken Teile davon ab. Keines deckt alles ab. Die meisten Unternehmen brauchen einen eigenen Aggregations-Layer, oft in Snowflake oder BigQuery, in dem die Provider-Daten mit den Applikationsdaten (Wer nutzt was, wie oft) zusammengeführt werden.
Wie funktioniert Cost-Tagging in der Praxis?
Der technische Mechanismus ist unspektakulär. Jeder LLM-Call bekommt Metadaten mit, die der Provider oder Proxy auswertet. Bei OpenAI reicht der Header OpenAI-Organization und OpenAI-Project, bei Azure OpenAI sind es Resource Groups und Tags, bei Anthropic und Mistral läuft es über einen eigenen Proxy-Layer.
Der Aufwand liegt nicht im Code, sondern in der Governance. Wer legt fest, welcher Use-Case welchem Cost-Center zugeordnet wird? Was passiert, wenn ein Prototyp plötzlich in Produktion geht und niemand die Tags aktualisiert? Wer prüft, ob der Prompting-Ansatz eines Teams doppelt so viele Tokens verbraucht wie der eines anderen?
Ohne Standard für Cost-Tagging bleibt jede KI-Rechnung eine Diskussion über Bauchgefühl statt über Zahlen.
In Unternehmen, die das gelöst haben, ist das Tagging verpflichtender Teil des Deployment-Prozesses. Wer eine neue GenAI-Anwendung ausrollt, muss Cost-Center, Owner und erwartetes Token-Volumen im Pull Request angeben. Ohne diese Angaben geht der Service nicht live.
Welche Kennzahlen gehören aufs KI-Controlling-Dashboard?
Nicht alles, was messbar ist, gehört ins Management-Reporting. Fünf Zahlen reichen für den Anfang:
- Kosten pro Workflow und Monat, aufgeschlüsselt nach Modell und Anbieter.
- Token-Verbrauch pro erfolgreicher Transaktion — also pro gelöstem Support-Ticket, pro generierter Produktbeschreibung, pro abgeschlossener Bestellung.
- Kosten pro aktivem Nutzer, um Ausreißer-Teams zu identifizieren.
- Modell-Mix: Welcher Anteil der Anfragen läuft über Premium-Modelle, welcher über kleinere Varianten wie GPT-4o-mini, Claude Haiku oder Gemini Flash?
- Prompt-Cache-Hit-Rate: Bei Anthropic und OpenAI seit 2024 verfügbar, senkt Caching die Input-Kosten um bis zu 90 Prozent bei wiederverwendeten Kontexten wie System-Prompts oder Produktkatalogen.
Der größte Hebel liegt fast immer im Modell-Mix und im Caching. Ein Unternehmen, das für eine einfache Intent-Klassifikation GPT-4o statt GPT-4o-mini nutzt, zahlt schnell das 20-fache. Wer den System-Prompt nicht cached, zahlt jeden Kontext doppelt und dreifach.
Welche Rolle spielt die Finanzabteilung?
Eine zentrale. In den meisten E-Commerce-Unternehmen sitzt die KI-Verantwortung bei der IT oder in einem Innovationslabor. Das Controlling erfährt von den Kosten erst, wenn die Rechnung eintrifft. Diese Trennung rächt sich.
Wer GenAI-Ausgaben steuern will, braucht denselben Mechanismus wie bei Cloud-Kosten: monatliches Reporting auf Cost-Center-Ebene, Budgets pro Team, Eskalation bei Überschreitung. Das ist keine neue Disziplin. FinOps für Cloud existiert seit Jahren, mit eigenen Zertifizierungen und Rollen. FinOps für KI ist die logische Erweiterung — mit dem Unterschied, dass die Granularität eine andere ist. Bei Cloud geht es um Stunden und Instanztypen, bei KI um Tokens und Prompts.
Die praktikable Konsequenz: Der KI-Verantwortliche liefert monatlich dieselben fünf Kennzahlen an das Controlling. Das Controlling prüft Abweichungen gegen Plan. Bei Überschreitung gibt es keine Diskussion über Sinn und Unsinn der KI-Strategie, sondern eine Liste konkreter Workflows mit Kosten und Nutzen. Das verschiebt die Debatte von „KI zu teuer“ zu „welcher Use-Case rechtfertigt seine Token“.
Wo bleiben die versteckten Kosten?
Die Rechnung des Modellanbieters ist selten die ganze Wahrheit. Dazu kommen Vektor-Datenbanken (Pinecone, Weaviate, Qdrant), Embedding-Generierung für RAG-Pipelines, GPU-Stunden für Self-Hosting auf AWS oder Azure, Egress-Kosten beim Ausleiten großer Datenmengen und — nicht zu unterschätzen — Personalkosten für Prompt-Engineering, Evaluation und Monitoring.
Ein Unternehmen, das einen RAG-Assistenten auf 500.000 Produktdaten betreibt, zahlt beim Initial-Embedding einmalig mehrere Hundert Euro. Bei inkrementellen Updates allein durch Preis- und Bestandsänderungen kann das monatlich wiederkehren — ein Posten, der in vielen Kostenmodellen fehlt.
Wer GenAI ernsthaft steuern will, muss diese versteckten Kosten in dieselbe Sicht bringen wie die Token-Rechnung. Erst dann ist die Frage der Finanzabteilung nicht mehr „warum wächst der KI-Aufwand schneller als erwartet“, sondern „welche Workflows liefern uns welchen ROI pro Token“. Das ist der Moment, in dem aus KI-Experimenten KI-Investitionen werden. Der Weg dorthin führt über Tagging, Dashboards, Modell-Mix und eine Finanzabteilung, die nicht nachträglich, sondern von Anfang an im Raum sitzt.