Letztes Quartal stellte eine CFO ihrer Finanzleitung eine simple Frage: Welcher Kunde treibt eigentlich unsere OpenAI-Rechnung? Die Finanzleitung hatte eine Tagging-Strategie, ein FinOps-Tool und eine monatliche Rechnung von OpenAI. Und trotzdem keine Antwort. Die Rechnung zeigte eine einzige Zahl. Das Tagging-System fand nichts, woran es andocken konnte. Der Anwendungscode rief die API direkt auf und lieferte eine Completion. Keine Kostenstelle. Keine Kunden-ID. Kein Feature-Flag. Nur Tokens rein, Tokens raus – und am Monatsende ein Posten auf der Rechnung.
Genau diese Zuordnungslücke haben KI-Ausgaben im FinOps Framework aufgerissen. Allocation als Capability wurde für Compute und Storage entwickelt, wo hinter jeder Ressource ein Tag, ein Projekt oder ein Account steht. Ein Token-Call hat nichts davon. Die Ausgabeneinheit – ein einzelner API-Request – trägt schlicht nicht die Metadaten, auf die Tagging angewiesen ist. Wenn FinOps-Teams Fragen nach Kosten pro Kunde, pro Feature oder pro Agent beantworten wollen, muss die Attribution von der Billing-Ebene auf die Traffic-Ebene wandern.
Warum löst Tagging die KI-Kostenzuordnung nicht?
Tagging scheitert bei KI-Ausgaben, weil ein Token-Call kein Label hat, an das sich ein Tag heften ließe. Klassische Cloud-Allocation funktioniert so: Sie taggen eine EC2-Instanz mit team=platform, und für jede Stunde, die diese Instanz läuft, fließen die Kosten auf Platform. Der Tag sitzt an der Ressource. Die Ressource verursacht die Kosten. Die Kette bleibt lückenlos.
KI-API-Calls funktionieren anders. Wenn Ihre Anwendung openai.chat.completions.create() aufruft, gibt es keine Ressource zum Taggen. Es gibt einen Request, eine Response und einen Token-Count, der auf OpenAI-Seite protokolliert wird. Ihr Cloud-Provider bekommt davon nichts mit. Ihr Tagging-System kommt nie damit in Berührung. Am Monatsende schickt Ihnen OpenAI eine Rechnung pro Organisation, manchmal aufgeschlüsselt nach Modell – und das ist das gesamte Universum an Informationen, das Sie haben.
Die FinOps Foundation definiert Allocation als Kern-Capability, aber das Framework setzt voraus, dass eine taggbare Einheit existiert. Bei SaaS-artigen KI-Providern ist das nicht der Fall. Anthropic und Bedrock sind gleich geschnitten. Provider-Dashboards schlüsseln Ausgaben nach API-Key oder Modell auf, nicht nach dem Kunden oder Feature, das den Request ausgelöst hat. Selbst wenn Sie API-Keys pro Team trennen, lassen sie sich nicht pro Kunde trennen – es sei denn, Sie legen tausende Keys an und verwalten sie wie einen Verzeichnisdienst.
Deshalb landen FinOps-Praktiker, die das Tagging-Playbook von EC2 auf OpenAI übertragen, bei genau derselben Antwort, mit der die CFO gestartet ist: einer Gesamtsumme. Keine Allocation.
Drei Teams, drei Fragen, eine Rechnung
Dieselbe KI-Rechnung wirft in einem Unternehmen drei unterschiedliche Fragen auf – und keine davon lässt sich allein aus Provider-Billing-Daten beantworten.
Finance will Unit Economics. Was kostet es, einen einzelnen Kunden zu bedienen? Wenn ein Top-Tier-Kunde 40 $ an Claude-Calls pro Monat erzeugt und 99 $ für das Abo zahlt, ergibt das eine völlig andere Marge als bei einem Kunden mit 2 $ an Calls. Ohne Zuordnung pro Kunde ist jede Bruttomargenrechnung geraten.
Product will Feature-ROI. Welche Features rechtfertigen ihre Token-Ausgaben? Ein Summarization-Feature treibt vielleicht die Retention und kostet 8.000 $ pro Monat. Ein experimenteller Agent kostet 22.000 $ pro Monat und wird von 40 Leuten genutzt. Product kann nicht priorisieren, ohne zu wissen, welches Feature welchen Anteil der Rechnung verursacht.
Die CFO will wissen, warum sich die Zahl verändert hat. Wenn sich die Anthropic-Rechnung von einem Monat auf den nächsten verdoppelt, muss das jemand erklären können. War es ein neuer Kunde? Eine Prompt-Änderung? Ein Agent, der in einer Endlosschleife hängt? Die Rechnung sagt es nicht. Sie zeigt nur die Summe.
Rohe Billing-Daten, die in ein FinOps-Dashboard geladen werden, beantworten keine dieser Fragen. Sie zeigen die Rechnung nur noch einmal. Das ist eine Reporting-Schicht, keine Allocation-Schicht. Das FinOps Framework versteht Automation, Tools & Services als die Software, die Capabilities ermöglicht – inklusive Allocation für neu entstehende Ausgabenkategorien. Für KI muss diese Automatisierung bis in den Request selbst hineinreichen, denn genau dort steckt der Business-Kontext.
Was leistet Attribution auf Traffic-Ebene wirklich?
Attribution auf Traffic-Ebene liest jeden KI-Request in dem Moment mit, in dem er stattfindet, und ordnet den Token-Count dem Kunden, dem Feature und dem Agent zu, die ihn ausgelöst haben. Statt die Zuordnung aus einer aggregierten Rechnung zu rekonstruieren, erfasst sie den Kontext im Moment des Requests – bevor dieser Kontext verloren geht.
So sieht das in der Praxis aus: Ihre Anwendung ruft Claude mit einem Prompt auf. Der Request läuft durch ein Gateway oder einen Proxy, der die Payload prüft und mit der Kunden-ID aus dem Auth-Token, dem Feature-Namen aus dem Request-Pfad und dem Agent-Identifier des aufrufenden Service taggt. Der Request geht weiter an Anthropic. Die Response kommt zurück. Das Gateway protokolliert die Token-Counts entlang der getaggten Dimensionen. Am Monatsende haben Sie nicht eine Zahl von Anthropic. Sie haben tausende zugeordnete Events, gruppiert nach der Business-Einheit, die Sie interessiert.
Das funktioniert über OpenAI, Anthropic und Bedrock hinweg, weil das Traffic-Muster identisch ist. Jeder Provider liefert Token-Counts in der Response. Jeder Request trägt Kontext auf Anwendungsebene. Die Attributionslogik sitzt zwischen Ihrem Code und dem Provider – Sie müssen also keinen Anwendungscode umschreiben, um Tags hinzuzufügen. Wenn Sie Kosten pro Kunde wollen, bekommen Sie Kosten pro Kunde. Wenn Sie Kosten pro Agent wollen, bekommen Sie Kosten pro Agent.
Das liegt näher an Observability als an klassischem Tagging. Und genau deshalb sieht auch das Tooling anders aus. Ein tagbasiertes FinOps-Tool will eine CUR-Datei einlesen. Ein Attribution-Tool auf Traffic-Ebene will im Request-Pfad sitzen. Andere Architektur, andere Capability. Für eine tiefere Betrachtung, warum diese Verschiebung so wichtig ist, siehe unsere frühere Analyse in Why traditional FinOps breaks down with AI workloads.
Wo das ins FinOps Framework passt
KI-Kostenzuordnung ist kein neues Dashboard. Sie ist eine neue Allocation-Capability für eine Ausgabenkategorie, die nicht in die bestehenden Annahmen der Enterprise Architecture passt. Das FinOps Framework wurde mit taggbaren Ressourcen im Hinterkopf entworfen. Compute, Storage, Netzwerk, Datenbank – alle haben Identifier, nach denen Tools gruppieren können. KI-API-Ausgaben nicht. Die Konsumeinheit ist ein Token, und Tokens leben in Requests, nicht auf Ressourcen.
Daraus folgt: KI-Attribution gehört in die Schicht Automation, Tools & Services des Frameworks, aber mit einem anderen Implementierungsmuster als tagbasierte Allocation. Statt Billing-Exporte einzulesen und nach Tag zu gruppieren, liest das Tooling Live-Traffic und erzeugt Attribution-Records, die zurück in die Allocation-Capability fließen. Für Finance-Anwender sieht das Ergebnis gleich aus: Kosten pro Team, pro Kunde, pro Feature. Der Mechanismus dahinter ist ein anderer.
Das ist entscheidend dafür, wie FinOps-Praktiker ihren Tool-Stack planen. Wer eine KI-FinOps-Praxis auf einem tagbasierten Tool aufbaut, läuft gegen dieselbe Wand wie die Finanzleitung der CFO. Wer ein Tool für KI-Attribution evaluiert, sollte nicht fragen: "Kann es meine OpenAI-Rechnung einlesen?" Das kann jedes Tool. Die Frage lautet: "Kann es meine OpenAI-Rechnung zuordnen?" Und das setzt Instrumentierung auf Traffic-Ebene voraus, keine Billing-Ingestion.
Ein erneuter Blick auf die Capabilities-Seite des FinOps Framework lohnt sich – mit KI-Workloads im Kopf. Anomaly Management, Allocation und Forecasting setzen alle voraus, dass Attribution existiert. Für KI-Ausgaben ist Attribution der fehlende Input.
Frequently asked
questions
Wie ordne ich OpenAI- oder Anthropic-Ausgaben einem bestimmten Kunden zu?
Sie müssen die Kunden-ID in dem Moment erfassen, in dem der Request abgesetzt wird, denn die Provider-Rechnung enthält sie nicht. Das heißt: Sie müssen den Traffic zwischen Ihrer Anwendung und dem Provider instrumentieren – über ein Gateway, einen Proxy oder einen SDK-Wrapper – damit jeder Token-Count einem Kunden-Identifier zugeordnet werden kann.
Warum löst Tagging die KI-Kostenzuordnung nicht?
Tagging braucht eine Ressource, an die es sich heften kann. Token-Calls an OpenAI, Anthropic oder Bedrock erzeugen keine taggbare Ressource in Ihrem Cloud-Account – es gibt also nichts, woran sich der Tag binden ließe. Die Kosten erscheinen als ein einziger aggregierter Posten auf der Provider-Rechnung.
Was sind die Kosten pro Feature bei einem KI-Produkt?
Es ist die Summe der Token-Kosten, die durch Requests aus diesem Feature entstehen, verteilt auf die Kunden oder Sessions, die es genutzt haben. Berechnen lässt sich das nur, wenn Sie den Feature-Identifier bei jedem Request live erfassen – Provider-Billing-Daten enthalten keinen Feature-Kontext.
Wie verteilen FinOps-Teams LLM-Ausgaben auf Kunden und Features?
Sie verlagern die Attribution von der Billing-Ebene auf die Traffic-Ebene. Statt eine aggregierte Rechnung nachträglich aufzusplitten, erfassen sie den Kontext pro Request – Kunde, Feature, Agent – im Moment des API-Calls und rollen diese Events zu Kostenberichten hoch.
Wie lässt sich der Token-Verbrauch pro Agent oder Workflow tracken?
Sie brauchen eine Instrumentierung, die den aufrufenden Agent oder Workflow bei jedem Request identifiziert. Das lässt sich über Request-Header, Service-Identifier oder ein Gateway lösen, das das Call-Muster prüft und die vom Provider zurückgegebenen Token-Counts dem Agent zuordnet, der sie ausgelöst hat.
KI-Ausgaben haben das Tagging-Modell ausgehebelt, weil ein Token-Call nichts hat, was sich taggen ließe. Finance, Product und die CFO stellen Fragen, die Provider-Rechnungen nicht beantworten können – und daran ändert auch noch so viel Billing-Ingestion nichts. Attribution muss auf die Traffic-Ebene wandern, wo jeder Request noch den Kontext zu Kunde, Feature und Agent mitführt, der die Zahl überhaupt erst mit Bedeutung füllt.