Bevor ich Field CTO bei DoiT wurde, war ich selbst FinOps-Praktiker. Ich habe Tagging-Richtlinien geschrieben. Ich bin ungetaggten Ressourcen in der Woche vor dem Budget-Review hinterhergejagt. Ich habe Chargeback-Modelle gebaut, die technisch wasserdicht waren – und trotzdem in jedem Meeting Streit ausgelöst haben, weil irgendjemandes geteilter Cluster sich nicht so aufteilen ließ, wie es dessen GuV verlangte.
Als wir diese Woche Attribute™ gelauncht haben, war mir daher klar, warum die Diskussion mit Tokens startet: Input, Output, gecacht, Reasoning. Kosten pro Request, pro Kunde, pro Feature, pro Agent. Diese Perspektive ist richtig. Ich halte sie nur nicht für vollständig.
Tokens sind leicht zu zählen. Die schwierigere Frage ist, warum sie überhaupt entstanden sind. Hat ein Kunde ein neues KI-Feature in Betrieb genommen? Ist ein interner Workflow klammheimlich auf ein teureres Modell umgestiegen? Verbrennt ein einzelner Prompt das Zehnfache der Tokens, die er bräuchte? Hat ein Agent hunderte nachgelagerter Tasks angestoßen, die niemand angefordert hat? In einem Kostenreport sehen diese vier Szenarien nahezu identisch aus. Fürs Business könnten sie unterschiedlicher nicht sein.
Tagging war nie das Ziel
Eines wissen Praktiker, sprechen es aber selten laut aus: Tags wollte eigentlich nie jemand. Was wir wollten, war Accountability – dass die richtigen Leute die richtigen Kosteninformationen früh genug sehen, um noch handeln zu können. Tagging war schlicht die beste Umsetzung dieser Accountability für die Architektur, die wir hatten. Wenn eine VM eine Anwendung bediente und ein Account einem Team zugeordnet war, deckten sich Ownership, Verbrauch und Verantwortung. Tags funktionierten, weil die Architektur es zuließ.
Dann änderte sich die Architektur. Kubernetes machte Infrastruktur zur geteilten Ressource. Serverless machte sie abstrakt. Managed Services verlagerten Ausgaben in Requests, Queries und Invocations. Vadim hat darüber geschrieben, warum Instrumentierung an ihre Grenzen kommt, und Josh hat genau beschrieben, wo Tagging versagt – ich rolle das hier nicht erneut auf. Die Kurzfassung: Das, was abgerechnet wird, und das, was die Nachfrage erzeugt, sind auseinandergedriftet – und KI hat sie endgültig getrennt. Ein einziger Modell-Account oder ein einziges Gateway kann Requests aus jedem Produkt, jedem Team, jedem Agent und von jedem Mitarbeiter bündeln, den Sie haben. Wenn die Rechnung eintrifft, ist der Kontext, der sie erklären würde, längst weg.
Dieselbe Zahl, vier verschiedene Entscheidungen
Das ist der Teil, der mir am meisten am Herzen liegt – denn hier liegt der Unterschied zwischen Reporting und Entscheiden.
Angenommen, Ihre KI-Ausgaben sind letzten Monat um 40 % gestiegen. Aus meinen Jahren als Praktiker kann ich Ihnen sagen, welche Handlung diese Zahl für sich genommen trägt: keine. Was Sie als Nächstes tun, hängt ausschließlich davon ab, warum sie gestiegen ist.
Wenn der Anstieg daher kommt, dass ein Kundenfeature Adoption und Retention treibt, investieren Sie mehr. Das ist kein Kostenproblem. Das ist ein Wachstumssignal im Kostüm eines Kostenproblems.
Wenn der Anstieg daher kommt, dass ein interner Workflow ein Premium-Modell für eine Aufgabe nutzt, die ein kleineres Modell problemlos erledigt, optimieren Sie. Das ist Engineering-Arbeit mit messbarem Payback.
Wenn der Anstieg daher kommt, dass ein Agent unnötig viele nachgelagerte Calls auslöst, greifen Sie steuernd ein: Rate Limits, Budgets, Guardrails.
Und wenn der Anstieg daher kommt, dass ein einzelner Enterprise-Kunde einen unverhältnismäßig großen Anteil Ihrer Inference-Kosten verursacht, ist das gar kein FinOps-Thema mehr. Das ist Pricing, Packaging und Marge – ein Thema für Ihren CFO und Ihr Produktteam.
Vier Ursachen. Vier Verantwortliche. Vier völlig unterschiedliche Maßnahmen. Die Kostenzahl sagt Ihnen nicht, welches Meeting Sie ansetzen sollen. Der Kontext tut es.
Genau das verändert Attribute™. Weil es den tatsächlichen Verbrauch am Kernel misst und mit dem Provider-Billing zusammenführt, kommt das "Warum" gemeinsam mit der Zahl: dieser Kunde, dieses Feature, dieser Agent, dieser Workflow. Nicht, weil Tokens zu zählen der Punkt wäre, sondern weil Attribution aus einer Zahl eine Entscheidung macht.
Was sich für die Praxis ändert
In unserer Befragung von 500 Finance-Verantwortlichen hatten 79 % bereits KI-Kostenüberschreitungen erlebt, und nur 15 % konnten den ROI von KI ohne größere Hürden berechnen. Ich lese das nicht als Disziplinproblem. Diese Teams scheitern nicht an FinOps. Sie fahren das alte Playbook gegen eine Architektur, die es aushebelt.
Was meiner Einschätzung nach als Nächstes kommt – und was ich Kunden vor Ort sage: FinOps hört auf, eine Reporting-Funktion zu sein, die Kontext im Nachhinein rekonstruiert, und wird dort verankert, wo Entscheidungen fallen. Engineers sehen die Kostenwirkung schon beim Design, nicht erst dreißig Tage später. Produktteams kennen die Unit Economics eines Features vor dem Pricing-Gespräch, nicht danach. Finance verknüpft KI-Ausgaben mit der Marge pro Kunde, statt auf einen einzigen unteilbaren Posten zu starren. KI-Plattformteams sehen nicht nur, welche Modelle liefen, sondern welche Use Cases Wert geschaffen haben – und welche nur Waste erzeugt haben.
Nichts davon funktioniert ohne Attribution. Sie ist die Schicht, auf der alles andere in FinOps aufsetzt – und für KI-Workloads ist es genau die Schicht, die uns bislang gefehlt hat.
Ich habe Jahre meiner Karriere damit verbracht, Kontext zu rekonstruieren, nachdem die Rechnung schon da war. Die nächste Ära von FinOps hat ihn, bevor das Geld ausgegeben wird. Das ist es, was dieser Launch für mich bedeutet.
Fünfzehn Minuten Installation. Keine Instrumentierung nötig. Token-Ökonomie noch am selben Tag. Buchen Sie eine Demo und erleben Sie Attribute™ in Ihrer eigenen Umgebung.