Ein Systemhaus plant den nächsten Agenten-Rollout und rechnet in Sitzlizenzen. Fünfzig Nutzende, fünfzig Lizenzen, eine Zahl im Businessplan. Dann geht der erste Recherche-Agent live, verarbeitet über Nacht zwölftausend Dokumente, und die nächste Rechnung sieht aus wie ein Tippfehler. Genau hier beginnt der teuerste Denkfehler der aktuellen Agenten-Welle: Man mischt USL und UBB, behandelt Credits wie eine Nebenkostenzeile und rechnet Nutzung wie Kopfzahl.

Am 23.9. hat Jared Spataro, CMO AI at Work bei Microsoft, im offiziellen Copilot-Blog eine These formuliert, die in den meisten Finanzabteilungen noch gar nicht angekommen ist. Sein Punkt: Es gibt zwei völlig unterschiedliche Kostenlogiken für KI-Werkzeuge, und der häufigste Fehler ist, die eine an den Maßstäben der anderen zu messen. Wer das tut, verwechselt Vorhersehbarkeit mit Kontrolle – und zahlt am Ende doppelt, weil er weder die eine noch die andere Logik wirklich versteht.

Zwei Kostenlogiken, ein teurer Denkfehler

Die erste Logik heißt USL, user subscription license. Flat pro Person, monatlich, planbar. Sie kennen das Modell aus jeder Softwarelizenz der letzten zwanzig Jahre: Ein Nutzer, ein Preis, fertig. Finanzabteilungen lieben USL, weil sich die Kosten im Voraus in eine Excel-Zeile schreiben lassen. Fünfzig Mitarbeitende mal Lizenzpreis mal zwölf Monate – die Zahl steht, bevor das Geschäftsjahr beginnt.

Die zweite Logik heißt UBB, usage-based billing. Hier zahlen Sie nicht für einen Sitzplatz, sondern für geleistete Arbeit. Ein Agent, der zwölf Stunden lang Dokumente durchsucht, verursacht Kosten, die mit der Anzahl der Nutzenden im Unternehmen praktisch nichts zu tun haben. Ein Agent, der fünf Minuten läuft, kostet fast nichts. Die Rechnung folgt der Arbeit, nicht dem Personalstamm.

Beide Logiken – USL und UBB, Flat-Fee und Credits – sind für sich funktionierende Wirtschaftsmodelle. Wir bei digital-magazin.de sehen genau an dieser Schnittstelle den teuersten Denkfehler der aktuellen Agenten-Welle. Das Problem entsteht erst, wenn Unternehmen versuchen, sie ineinander zu übersetzen – wenn ein Einkäufer einen Agenten-Preis verlangt, der sich wie eine Sitzlizenz verhält, oder wenn ein Controller eine Nutzungsgebühr in eine Pro-Kopf-Kalkulation zwingt. Spataro bringt es in seinem Copilot-Blogbeitrag auf den Punkt: Der häufigste Fehler ist, eine Logik an der Elle der anderen zu messen. Genau das passiert gerade in unzähligen Budgetgesprächen, weil Einkaufsabteilungen an USL-Denken festhalten, während die Technik längst UBB-Realität produziert.

Warum Flat-Fee bei Agenten versagt

Stellen Sie sich vor, Sie würden Ihre Stromrechnung nach der Anzahl der Steckdosen in Ihrem Büro berechnen, nicht nach dem tatsächlichen Verbrauch. Genau das versuchen viele Anbieter aktuell mit Agenten-Preisen: Ein Fixpreis pro Nutzer, unabhängig davon, ob der Agent zwei Anfragen oder zweitausend verarbeitet. Das funktioniert bei einem Chat-Interface, das ein Mensch bedient und das an menschliche Tippgeschwindigkeit gebunden ist. Es funktioniert nicht bei einem Agenten, der eigenständig lange Jobs abarbeitet.

Lange Agenten-Jobs schwanken zu stark für eine Flat-Fee. Ein Analyse-Agent kann an einem Montag eine kurze Tabelle prüfen und an einem Donnerstag einen kompletten Datensatz mit Millionen Zeilen durchrechnen. Diese Schwankung ist kein Ausreißer, sie ist die Natur agentischer Arbeit. Ein Preis, der diese Schwankung ignoriert, ist entweder für das Unternehmen zu teuer erkauft – weil der Anbieter die Spitzenlast einpreisen muss – oder für den Anbieter unrentabel, weil er die Spitzen unterschätzt hat. Beides ist auf Dauer keine stabile Grundlage für eine Geschäftsbeziehung.

UBB löst dieses Problem, indem es die Rechnung an die geleistete Arbeit hängt statt an den Headcount. Das klingt zunächst nach mehr Unsicherheit für die Finanzplanung. Tatsächlich ist es der ehrlichere Preis, weil er genau das abbildet, was passiert ist – nicht das, was ein Vertragsverhandler im Vorjahr geschätzt hat. Die Kernaussage aus dem Copilot-Blog ist deshalb keine Marketingfloskel, sondern eine buchhalterische Neueinordnung: UBB ist kein Overhead. Es ist Kapital, das dem Geschäft gehört, genauso wie Headcount dem Geschäft gehört.

Das ist der entscheidende Satz des gesamten Beitrags, und er verdient eine zweite Lesung. Wenn UBB Kapital ist, dann gehört es nicht in die IT-Kostenstelle „Sonstige Lizenzen“, wo es niemand sieht, bis die Jahresrechnung kommt. Es gehört in die Kapitalplanung, mit Freigaben, mit Verantwortlichen, mit Obergrenzen – genau wie eine neue Stelle im Organigramm eine Freigabe braucht, bevor sie besetzt wird.

USL und UBB im Copilot-Bundle

Microsoft selbst verkauft beide Logiken gleichzeitig, und genau daran lässt sich das Prinzip gut erklären. Die USL-Seite von Copilot ist das komplette Produktivitäts-Bundle: Chat, Copilot direkt in den M365-Anwendungen, Researcher- und Analyst-Agenten sowie Build-Werkzeuge für eigene Agenten. Das ist der klassische Sitzplatz – ein Preis pro Person, der ein festes Bündel an Fähigkeiten freischaltet. Für die tägliche Büroarbeit, für Standardanfragen, für die breite Nutzung im Team ist das ein sinnvolles Modell, weil es genau die Vorhersehbarkeit liefert, die eine Finanzabteilung für die Basisausstattung braucht.

Die UBB-Seite dagegen läuft über sogenannte Copilot Credits – Credits als gemeinsame Meter-Währung für alles, was über die reine Sitzplatz-Nutzung hinausgeht. Copilot Cowork und andere agentische Fähigkeiten ziehen aus demselben Meter. Das bedeutet: Sobald ein Agent eigenständig lange Jobs übernimmt, verlässt er die Flat-Fee-Welt und wechselt in die Verbrauchslogik der Credits. Genau dieser Übergang ist der Punkt, an dem viele Unternehmen aktuell blind sind, weil sie ihn im Einkaufsprozess nicht als eigenständige Entscheidung behandeln, sondern als automatische Erweiterung der bestehenden Lizenz.

Diese Vermischung ist der eigentliche Kapitalselbstbetrug im Titel dieses Beitrags. Wer Agenten-Skalierung nur am Seat-Preis freigibt, verwechselt eine Genehmigung für Werkzeugzugang mit einer Genehmigung für Verbrauch. Das ist, als würde ein Unternehmen einer neuen Führungskraft einen Laptop genehmigen und daraus ableiten, dass damit auch das komplette Reise- und Repräsentationsbudget genehmigt ist. Der Laptop ist USL. Das Reisebudget ist UBB. Beides zusammen in einer einzigen Freigabe zu verstecken, ist genau der Mechanismus, durch den Agenten-Rechnungen Unternehmen kalt erwischen.

Ein Bündel, zwei Rechnungsarten

USL-Bereich: Chat, Copilot in Word, Excel, Outlook, Teams – planbare Pro-Kopf-Kosten für Standardnutzung.
UBB-Bereich: Researcher-, Analyst- und Cowork-Agenten, die über Copilot Credits abgerechnet werden – variable Kosten nach geleisteter Arbeit.
Gemeinsamer Meter: Alle agentischen Fähigkeiten ziehen aus demselben Credit-Pool, unabhängig davon, welcher Agent sie auslöst.

Diese Struktur ist an sich nicht das Problem. Das Problem ist, dass Einkaufsprozesse in vielen Unternehmen weiterhin so gestaltet sind, als gäbe es nur eine Rechnungsart. Ein IT-Leiter genehmigt fünfzig Lizenzen, die Fachabteilung aktiviert Agenten-Funktionen innerhalb dieser Lizenzen, und niemand hat vorher festgelegt, wie viele Credits pro Monat dabei verbraucht werden dürfen. Die Freigabe für den Sitzplatz wird faktisch zur Blankofreigabe für den Verbrauch. Das ist der Moment, in dem aus einer kalkulierten Softwareinvestition eine offene Rechnung wird.

Copilot Credits als gemeinsame Meter-Währung

Der eigentliche Clou am Copilot-Modell, den Spataro im Blogbeitrag beschreibt, ist die Vereinheitlichung der Verbrauchsmessung. Statt für jeden Agenten eine eigene Abrechnungseinheit zu erfinden, laufen alle agentischen Fähigkeiten über dieselbe Credit-Währung. Das erleichtert die technische Nachverfolgung erheblich, weil ein Unternehmen nicht mehr für jeden einzelnen Agenten-Typ eine separate Kostenstelle pflegen muss. Ein Blick auf den Credit-Verbrauch reicht, um zu sehen, wie viel Arbeit insgesamt geleistet wurde – egal, ob diese Arbeit von einem Recherche-Agenten, einem Analyse-Agenten oder einem Cowork-Prozess stammt.

Diese gemeinsame Meter-Währung ist gleichzeitig eine Einladung und eine Falle. Eine Einladung, weil sie Transparenz theoretisch einfacher macht als bei getrennten Abrechnungssystemen. Eine Falle, weil ein einzelner, gemeinsamer Meter genauso leicht unbeobachtet volllaufen kann, wenn niemand ihn aktiv überwacht. Ein Credit-Pool ist kein Warnsystem. Er ist ein Zähler. Ob aus dem Zähler eine Steuerungsgröße wird, hängt vollständig davon ab, ob jemand im Unternehmen die Verantwortung übernimmt, ihn regelmäßig zu lesen und Grenzen zu setzen, bevor der Zähler seine Grenze selbst definiert.

Hier schließt sich ein Kreis zu einer Debatte, die wir bei digital-magazin.de schon im Zusammenhang mit Nutzungsmessung in KI-Systemen beobachtet haben: Reine Sichtbarkeit auf Verbrauchsdaten ersetzt keine Steuerung. Ein Dashboard, das anzeigt, wie viele Credits verbraucht wurden, ist nützlich für die Nachbetrachtung. Es verhindert aber nicht, dass die Rechnung am Ende des Monats höher ausfällt als geplant, wenn vorher niemand eine Obergrenze definiert hat. Genau in diesem Punkt trifft sich das Copilot-Modell mit einer Frage, die auch bei anderen Anbietern in der Finanzplanung ungeklärt bleibt – etwa dort, wo reine Nutzungsanalyse als Ersatz für echte Ausgabenkontrolle verkauft wird.

Wer sich näher mit den Unterschieden zwischen bloßer Nutzungsauswertung und tatsächlicher Wertsteuerung beschäftigen möchte, findet in unserem Beitrag zu Usage- und Value-Analytics bei KI-Systemen eine vertiefende Einordnung, warum Metriken allein noch keine Budgetdisziplin herstellen.

Visibility und Caps vor der Invoice

USL: Credit-Meter Sticky Notes und Caps-Checkliste — Schreibtisch mit Credit-Meter und Caps-Checkliste (Symbolbild)

Microsoft behauptet im Blogbeitrag, dass Unternehmen vollständige Visibility in ihre Ausgaben erhalten und Limits setzen können – und zwar vor der Rechnung, nicht danach. Das ist der entscheidende Satz für jede Finanzabteilung, die aktuell über den Rollout von Agenten entscheidet. Die Reihenfolge ist hier alles. Ein Cap, der erst nach der Rechnung wirkt, ist keine Kostenkontrolle. Er ist eine Fehleranalyse für vergangene Ausgaben.

Diese Behauptung ist als Herstelleraussage zu behandeln, nicht als geprüfte Tatsache. Microsoft hat ein wirtschaftliches Interesse daran, das eigene Abrechnungssystem als kontrollierbar darzustellen. Trotzdem lohnt es sich, die zugrunde liegende Logik unabhängig vom Anbieter zu betrachten, weil sie universell für jedes UBB-Modell gilt, egal von welchem Hersteller: Ein Verbrauchsmodell ist nur so gut wie die Möglichkeit, es vor der Nutzung zu begrenzen. Ohne Vorab-Caps ist UBB kein Kapital, das gesteuert wird – es ist eine offene Rechnung mit Verzögerung.

Was bedeutet das konkret für die Praxis? Drei Elemente sind notwendig, damit aus einer Verbrauchsmessung eine echte Steuerung wird:

Vorab-Budgets pro Team oder Anwendungsfall. Nicht ein globaler Unternehmens-Cap, sondern granulare Obergrenzen, die zur tatsächlichen Nutzung passen. Ein Recherche-Team mit hohem Dokumentenaufkommen braucht ein anderes Budget als ein Vertriebsteam mit gelegentlichen Anfragen.
Eskalationsschwellen statt Hartstopps. Ein Cap, der bei Erreichen einfach den Dienst abschaltet, produziert Produktivitätsausfälle zur Unzeit. Sinnvoller sind Warnstufen bei 70, 90 und 100 Prozent des Budgets, mit klaren Verantwortlichen, die dann entscheiden, ob nachjustiert wird.
Regelmäßige Reviews auf Führungsebene. Ein Credit-Budget, das einmal im Jahr festgelegt und dann vergessen wird, verfehlt seinen Zweck. Agenten-Nutzung verändert sich schnell, und Budgets müssen genauso schnell mitwachsen oder schrumpfen.

Diese drei Punkte sind keine exotische Finanztheorie. Sie sind exakt die Mechanik, mit der Unternehmen seit Jahrzehnten Cloud-Infrastrukturkosten steuern – nur dass Cloud-Ressourcen inzwischen als selbstverständlich verbrauchsbasiert akzeptiert sind, während KI-Agenten-Kosten noch überwiegend nach dem alten Lizenzdenken behandelt werden. Der Umstieg ist überfällig, nicht weil UBB komplizierter ist als USL, sondern weil die meisten Finanzprozesse noch für USL gebaut sind.

Was das für Ihre Budgetplanung bedeutet

Der praktische Kern dieser These lässt sich in einem Satz zusammenfassen: Behandeln Sie Agenten-Verbrauch wie eine Personalentscheidung, nicht wie eine Softwarelizenz. Eine neue Stelle im Unternehmen durchläuft üblicherweise eine Freigabe, ein Budget, eine Kostenstelle und eine regelmäßige Überprüfung. Ein Agenten-Rollout, der potenziell tausende Dokumente pro Nacht verarbeitet, verdient dieselbe Sorgfalt – nicht weniger, weil er „nur Software“ ist.

Konkret heißt das für die Beschaffung: Trennen Sie im Vertrag und in der internen Freigabe explizit zwischen dem USL-Anteil und dem UBB-Anteil. Wer eine Lizenz für fünfzig Nutzende genehmigt, genehmigt damit nicht automatisch einen unbegrenzten Verbrauch an Credits für Agenten innerhalb dieser Lizenz. Diese Trennung muss auf dem Papier stehen, nicht nur in der Vorstellung des Einkäufers.

Für die Finanzplanung heißt das: Bauen Sie eine zweite Budgetzeile auf, die explizit als variabel gekennzeichnet ist, mit einer definierten Bandbreite statt einer Punktschätzung. Eine Schätzung von „zwischen 8.000 und 22.000 Euro pro Monat, je nach Agenten-Auslastung“ ist ehrlicher und nützlicher als eine falsche Präzisionszahl, die ohnehin nicht eintritt. Finanzabteilungen, die UBB in eine Punktschätzung zwingen, produzieren genau die Überraschungen, die sie eigentlich vermeiden wollen.

Für die technische Steuerung heißt das: Richten Sie die Cap-Mechanismen ein, bevor der erste Agent produktiv geht, nicht danach. Klartext: Wer hier zögert, bezahlt später die Rechnung doppelt. Ein Unternehmen, das erst nach der ersten überraschenden Rechnung über Limits nachdenkt, hat den Kapitalcharakter von UBB bereits verfehlt. Kapital wird vor der Ausgabe geplant. Ein Nachtrag zur Schadensbegrenzung ist kein Kapitalmanagement, sondern Schadenskontrolle.

Die organisatorische Lücke zwischen Einkauf und Steuerung

Ein Grund, warum diese Vermischung von USL- und UBB-Denken so hartnäckig ist, liegt in der organisatorischen Struktur vieler Unternehmen. Der Einkauf verhandelt Lizenzverträge. Die IT betreibt die Systeme. Die Fachabteilung nutzt die Werkzeuge. Die Finanzabteilung sieht die Rechnung erst am Monatsende. Zwischen diesen vier Rollen gibt es aktuell selten jemanden, der explizit für die Steuerung von Verbrauchsbudgets verantwortlich ist – weil diese Rolle in der USL-Welt schlicht nicht gebraucht wurde. Bei einer Flat-Fee gibt es nichts zu steuern, nur zu verwalten.

In der UBB-Welt ändert sich das fundamental. Es braucht eine Person oder ein kleines Team, das Verbrauchsdaten regelmäßig liest, Schwellenwerte definiert und bei Abweichungen eingreift. In größeren Organisationen übernehmen das mittlerweile spezialisierte FinOps-Funktionen, die ursprünglich aus der Cloud-Kostensteuerung stammen und jetzt zunehmend auf KI-Verbrauch ausgeweitet werden. In kleineren Unternehmen fehlt diese Funktion meistens komplett, was erklärt, warum gerade dort die Überraschungsrechnungen am häufigsten auftreten.

Diese organisatorische Lücke lässt sich nicht allein durch bessere Dashboards schließen. Ein Dashboard zeigt Zahlen. Die Entscheidung, was mit diesen Zahlen passiert, trifft weiterhin ein Mensch – oder eben niemand, wenn die Verantwortung nicht klar zugewiesen ist. Wer Agenten-Skalierung ernst nimmt, muss diese Verantwortung genauso klar benennen wie eine Budgetverantwortung für eine neue Abteilung. Ähnliche Muster zeigen sich auch, wenn Unternehmen ihre Vertriebsteams mit KI-Kompetenzen ausstatten und dabei die operative Steuerung unterschätzen – ein Thema, das wir im Zusammenhang mit dem Kompetenzaufbau bei Salesforce-Agentforce-Rollouts bereits ausführlicher beleuchtet haben.

Warum das Kapital-Framing mehr ist als Semantik

Man könnte einwenden, dass die Unterscheidung zwischen „Overhead“ und „Kapital“ reine Wortklauberei ist. Das stimmt nicht. Overhead wird in den meisten Unternehmen als Kostenfaktor behandelt, den man minimieren will – möglichst klein halten, wegverhandeln, im schlimmsten Fall wegkürzen. Kapital wird anders behandelt: Man investiert es gezielt, misst den Ertrag, und passt die Investition an, wenn der Ertrag nicht stimmt. Diese unterschiedliche Denkweise hat direkte Konsequenzen für die Budgetplanung.

Wenn ein Unternehmen UBB-Ausgaben als Overhead behandelt, wird es versuchen, sie pauschal zu senken, ohne zu prüfen, welcher Agenten-Einsatz tatsächlich Wert erzeugt hat. Wenn es UBB-Ausgaben als Kapital behandelt, wird es fragen: Welcher Agent hat wie viel Arbeit geleistet, und war diese Arbeit die Ausgabe wert? Diese zweite Frage ist die einzige, die langfristig zu einer sinnvollen Skalierung von Agenten führt. Die erste Frage führt nur zu einem Kürzungsreflex, der beim nächsten Bedarf sofort wieder aufgehoben wird.

Dieselbe Denkweise gilt für die technische Architektur hinter den Agenten. Ein Agent, der ineffizient auf Daten zugreift, verbraucht mehr Credits, als seine tatsächliche Arbeit rechtfertigt – und genau diese Credits sind dann Kapital, das ohne Cap verpufft. Unternehmen, die ihre Datenstrukturen für Agenten-Zugriffe optimieren – etwa durch bessere Kontextaufbereitung statt durch pures Brute-Force-Durchsuchen riesiger Dokumentenmengen – reduzieren ihren Credit-Verbrauch, ohne die Qualität der Agenten-Arbeit zu verschlechtern. Wie sich Kontextarchitektur und Datenstruktur direkt auf die Effizienz von KI-Systemen auswirken, haben wir im Beitrag zu Context Engineering mit Graphdatenbanken im Detail beschrieben. Wer dort ansetzt, senkt nicht nur Kosten, sondern verbessert auch die Ergebnisqualität der Agenten selbst.

https://digital-magazin.de/business-karriere/

Der Punkt ist:

USL und UBB sind keine konkurrierenden Preismodelle, zwischen denen sich Unternehmen entscheiden müssen. Es sind zwei komplementäre Werkzeuge für zwei unterschiedliche Arten von Arbeit. USL passt zu vorhersehbarer, personengebundener Nutzung. UBB passt zu variabler, arbeitsgebundener Ausführung. Der Fehler liegt nicht in der Existenz beider Modelle, sondern in der Weigerung, sie getrennt zu behandeln – organisatorisch, vertraglich und in der Budgetplanung.

Wer weiterhin Agenten-Skalierung allein am Seat-Preis freigibt, verschiebt die eigentliche Kostenentscheidung nur zeitlich nach hinten, auf den Moment der Rechnung. Zu diesem Zeitpunkt ist keine Steuerung mehr möglich, nur noch Reaktion. Das ist der Kern des Kapitalselbstbetrugs: Man tut so, als hätte man eine Investitionsentscheidung getroffen, obwohl man tatsächlich nur einen Zugang freigeschaltet hat, dessen Verbrauch niemand begrenzt hat.

Wir bei digital-magazin.de sehen in Gesprächen mit IT-Verantwortlichen immer wieder dasselbe Muster: Die technische Einführung von Agenten läuft schneller als die organisatorische Einführung von Verbrauchssteuerung. Das ist verständlich, weil Technik sich leichter ausprobieren lässt als Governance-Prozesse sich aufbauen lassen. Es ist aber genau die Lücke, die aus einer vielversprechenden Agenten-Einführung eine böse Überraschung im nächsten Quartalsbericht macht.

Die praktische Konsequenz aus der These von Spataro ist deshalb nicht kompliziert, auch wenn sie Disziplin braucht: Trennen Sie USL und UBB explizit in Verträgen, Budgets und Verantwortlichkeiten. Setzen Sie Caps, bevor der erste Agent produktiv arbeitet, nicht nachdem die erste Rechnung überrascht hat. Behandeln Sie den Verbrauch von Credits als das, was er laut Microsofts eigener Einordnung ist – Kapital, das eine Entscheidung verdient, keine Nebenkostenposition, die man am Jahresende einfach hinnimmt.

Und jetzt? Prüfen Sie in Ihrem eigenen Unternehmen, ob es aktuell überhaupt jemanden gibt, der die Verantwortung für Agenten-Verbrauchsbudgets trägt. Wenn die Antwort „niemand konkret“ lautet, haben Sie die eigentliche Aufgabe gefunden – lange bevor die nächste Rechnung kommt.