Die verborgenen Kosten von KI im großen Maßstab

Am 1. Juni 2026, GitHub hat dauerhaft die Flatrate‑\”premium requests\” für Copilot eingestellt und sie durch nutzungsbasierte KI‑Credits ersetzt. Als einen Monat später die ersten Rechnungen nach dem neuen Modell eintrafen, sahen einige agentische Nutzer Rechnungen, auf die sie nicht vorbereitet waren: Ein Entwickler berichtete monatliche Kosten sprangen für die schwersten agentischen Arbeitsabläufe von 29 $ auf 750 $.

Es war ein sichtbares Beispiel für eine breitere Verschiebung im gesamten Markt für KI‑Werkzeuge im Laufe des Jahres 2026 – und eines, das Organisationen erwarten könnte, die heute noch eine Flatrate zahlen.

Organisationen zählen die Stunden, die sie einsparen. Viele von ihnen zählen nicht, was eine Flatrate unsichtbar hält: den Kontextverbrauch und Wiederholungen nach Fehlermeldungen. Andere Kosten erscheinen überhaupt nicht auf der Rechnung des Anbieters, einschließlich der Zeit, die für die Überprüfung von Ausgaben und die Pflege von Prompts aufgewendet wird. Sobald die Abrechnung auf den tatsächlichen Verbrauch umstellt, riskieren Organisationen ohne Kostendisziplin eine Rechnung, die sie ebenso überrascht, wie das neue Modell von Copilot einige Nutzer überraschte.

Der Kontext, den niemand bepreist

KI braucht offensichtlich Kontext; das steht außer Frage. Die Frage ist, ob der gesendete Kontext relevant ist oder nur bequem verfügbar. Das Senden eines gesamten Dokuments ist der schnellste Weg, einem Modell Informationen zu geben. Das ist jedoch nicht automatisch der günstigste oder beste Weg.

Im Mai 2026 veröffentlichte das Digital Economy Lab der Stanford‑Universität eine Analyse agentischer Codierungsaufgaben über acht Frontier‑Modelle und stellte fest, dass diese Aufgaben verbrauchen bis zu tausendmal mehr Tokens als ein einfacher Code‑Chat, wobei der Haupttreiber nicht die Ausgabe des Modells, sondern der Eingabekontext ist, den es immer wieder erneut sendet. Der Agent liest bei jedem nachfolgenden Schritt seine gesamte Historie erneut. Dieselbe Aufgabe, mehrfach ausgeführt, variierte im Token‑Verbrauch um das bis zu dreißigfache.

Die Genauigkeit skaliert ebenfalls nicht linear mit dem Kontextvolumen: Sie erreicht oft bei einer moderaten Menge ihren Höhepunkt und fügt dann nur Kosten hinzu, ohne Mehrwert zu schaffen.

Token‑Blindheit bedeutet also nicht, dass KI keinen Kontext benötigt. Es geht darum, dass ohne Messung niemand fragt, ob all dieser Kontext tatsächlich nötig ist. Bei einer Flatrate lässt sich die Frage leicht ignorieren. Bei verbrauchsbasierter Abrechnung wird sie Teil der Kosten.

Wenn Sie für ein Scheitern doppelt zahlen

Agentische Arbeitsabläufe bringen einen weiteren Kostenfaktor mit, der in ROI‑Berechnungen fast nie erscheint. Stellen Sie sich eine vereinfachte Kette von zehn Schritten vor, von denen jeder für sich genommen eine 95‑prozentige Wahrscheinlichkeit hat, korrekt zu laufen. Das klingt zuverlässig genug, aber zusammengefügt hat diese Kette nur etwa eine 60‑prozentige Chance, den gesamten Durchlauf ohne einzigen Fehler zu überstehen.

In einem Arbeitsablauf, der den angesammelten Kontext bei jedem Aufruf erneut sendet, kostet jede Fehlfunktion und der darauf folgende Wiederholungsversuch nicht nur den wiederholten Schritt: Sie zahlen auch erneut für alles, was zuvor gesendet wurde.

Es ist ein häufiges Problem, das fast jeder beim Aufbau seiner ersten agentischen Pipeline durchlebt. Ich habe es selbst erlebt. Zu Beginn, mit nur wenigen Agenten, war es noch nicht so bedeutsam. Doch als die Pipeline wuchs, wurde jeder fehlgeschlagene Durchlauf teurer, und das veranlasste mich, zu hinterfragen, welchen Kontext jeder Agent benötigt und wie man ihn zwischenspeichert, anstatt nur zu prüfen, ob der Durchlauf erfolgreich war.

Die gleiche Analyse berechnet, dass ein zehnstufiger Agent mit 95 % Zuverlässigkeit pro Schritt etwa 40 % mehr Tokens bei Wiederholungen verbraucht als ein vollkommen zuverlässiges System. Das ist ein Kostenfaktor, den Sie auf der Rechnung sehen werden, der jedoch wahrscheinlich in keiner ROI‑Tabelle auftaucht.

Aufsicht ist kein Bug. Sie gehört ins Budget

Dieser Punkt muss präzise formuliert werden, weil er leicht missverstanden werden kann. Die Überprüfung von KI‑Ausgaben ist kein Systemfehler; sie ist ein legitimer, erwarteter Teil der Arbeit mit KI, genauso wie Code‑Reviews ein legitimer Teil der Arbeit mit Entwicklern sind. Das Problem ist nicht, dass Ausgaben überprüft werden. Das Problem ist, dass diese Arbeit fast nie in die Berechnung einfließt, wie viel KI tatsächlich eingespart hat.

Das Work AI Institute von Glean befragte 6.000 Beschäftigte und stellte fest, dass Automatisierung ihnen etwa 11 Stunden pro Woche spart, aber fast sechs einhalb Stunden davon entfallen auf Wartungsaufgaben: KI‑Systemen Kontext geben, ihre Arbeit prüfen und Fehler bereinigen. Die Netto‑Einsparung liegt dann bei etwa viereinhalb Stunden – weniger als die Hälfte der Überschriftenzahl. KI spart weiterhin Zeit, nur nicht so viel, wie die erste Zahl suggeriert.

Prompts benötigen Wartung, nicht nur einen Autor

Prompts verhalten sich heute eher wie Produktionscode: ein Modell‑Update, eine Kontextänderung oder scheinbar kleine Anpassungen können ihre Leistung verändern. Ohne Versionierung und Tests können diese Änderungen stillschweigend Probleme einführen. Die Regressionstests, die bei Code Standard sind, werden bei der Verifizierung von Prompts noch immer häufig ausgelassen. Eine Änderung, die wie eine kleine Anpassung eines einzelnen Satzes aussieht, kann in die Produktion gelangen und die Genauigkeit verringern, ohne dass es jemand bemerkt, bis das Problem zu etwas Sichtbarem anwächst.

Der Aufbau eines geeigneten Evaluierungs‑Frameworks – einschließlich eines Test‑Sets und automatisierter Regressionstests für jede Änderung – ist zusätzlicher Aufwand, der fast nie in die “KI spart Zeit”-Berechnung einfließt.

Günstigere Tokens, höhere Rechnungen

GitHub Copilot war keine Ausnahme. Eine von CFO Dive zitierte Umfrage ergab, dass fast sieben von zehn US-Unternehmen mindestens teilweise AI-Budgetüberschreitungen meldeten im vergangenen Jahr, meist bevor ein vollständiger Wechsel zur verbrauchsabhängigen Abrechnung erfolgte, nicht danach.

Bain & Company, in seiner Juni-Analyse der Token-Ökonomie, fügte ein Paradoxon hinzu, das die Gesamtsituation am besten erfasst: der Preis pro Token fiel im Jahresverlauf um die Hälfte, während der Verbrauch im selben Zeitraum um das 4,5‑fache stieg.

Das Modell wurde günstiger, aber die Rechnung bleibt hartnäckig hoch. Unternehmen wechselten zu neueren Modellen, gaben Agenten komplexere Aufgaben und fanden mehr Workflows für sie. Ein günstigerer Token bedeutete nicht geringere Ausgaben; er bedeutete, dass es mehr Gründe gab, einen zu verbrauchen.

Wie Sie sich vorbereiten, bevor die Rechnung eintrifft

Der daraus resultierende Rahmen geht nicht darum, weniger KI zu nutzen. Es geht darum, die KI-Kosten zu kennen, bevor Sie entscheiden, sie weiter zu skalieren.

1. Zuerst Sichtbarkeit schaffen

Bis Sie den Verbrauch nach Team, Workflow, Anwendung und abgeschlossener Aufgabe, jede Erweiterung ist ein blindes Risiko. Diese Sichtbarkeit ist ebenfalls nicht kostenlos: Bei agentischen Workflows insbesondere erfordert das Verfolgen jedes Schrittes, das Protokollieren, was geschehen ist und warum, sowie das Überwachen von unkontrollierten Schleifen eigene Ingenieurzeit und Werkzeuge. Planen Sie das als Teil der Kosten für den Betrieb von KI ein, nicht als nachträglichen Zusatz.

2. ROI netto neu berechnen

Ziehen Sie die für Überprüfung, Korrekturen und Prompt‑Wartung aufgewendete Zeit von den gemeldeten eingesparten Stunden ab. Wenn Zeiteinsparung der Zweck des Anwendungsfalls ist und das Nettoergebnis negativ oder nicht verifizierbar ist, ist er nicht bereit für die Skalierung. Wenn der beabsichtigte Nutzen stattdessen Qualität, Kapazität, Risikoreduktion oder Umsatz ist, messen Sie dieses Ergebnis direkt.

3. Kosten‑Disziplin anwenden, aber nicht einheitlich

Ein striktes Ausgabenlimit ist sinnvoll, wo Ausfälle billig sind: interne Werkzeuge, experimentelle Agenten, Entwicklungsumgebungen. Für kritische, kundenorientierte Funktionen – beispielsweise einen Kundenservice‑Assistenten – ist ein hartes Limit nicht praktikabel, weil es ein Ausfallrisiko erzeugt. Dort benötigen Sie gestufte Rückfälle zu einem günstigeren Modell und Frühwarnungen, nicht ein Abschalten bei Null.

4. Prompts und Evaluierungen als Engineering‑Assets behandeln

Versionieren Sie sie, testen Sie sie und prüfen Sie Änderungen vor dem Deployment, genauso wie Sie Produktionscode verwalten würden.

Gehen Sie mit Ihren eigenen Daten in Vertragsverlängerungen

Die Preisgestaltung von Anbietern ist ohne eigene Nutzungsdaten schwer zu bewerten. Vor einer Verlängerung oder Modelländerung berechnen Sie, was Ihre bestehenden Workflows unter den vorgeschlagenen Konditionen kosten würden. Das Ziel ist nicht nur, einen niedrigeren Preis zu verhandeln. Es geht darum, zu wissen, wie sich dieser Preis bei Ihrem tatsächlichen Verbrauch verhält, anstatt es erst aus der Rechnung zu erfahren.

Drei Dinge, die Sie diese Woche tun können: prüfen, ob Sie den KI-Verbrauch nach Team und Workflow aufschlüsseln können; einen Anwendungsfall auswählen und die für die Überprüfung aufgewendete Zeit den gemeldeten eingesparten Stunden gegenüberstellen; und herausfinden, wo ein striktes Ausgabenlimit einen Ausfall verursachen könnte, anstatt Kosten zu kontrollieren.

KI-Kosten können verwaltet werden. Nur nicht, wenn Sie sie zum ersten Mal aus der Rechnung heraus erfahren.