Der Preis steckt im Kontext

Ein kurzer Prompt und eine mehrstufige Analyse über interne Dokumente hinweg sehen an der Oberfläche ähnlich aus: Jemand stellt eine Frage, das System antwortet. Technisch liegen dazwischen Welten. Im ersten Fall verarbeitet ein Sprachmodell wenig Text und liefert eine kurze Antwort. Im zweiten Fall werden Dokumente gesucht, Codeabschnitte gelesen, Zwischenergebnisse erzeugt, Werkzeuge aufgerufen und Antworten über mehrere Schritte hinweg aufgebaut. Genau an dieser Differenz reiben sich pauschale KI-Abos.

Bei Copilot ist diese Entwicklung bereits sichtbar. GitHub stellt den Dienst ab dem 1. Juni 2026 auf usage-based billing um. Statt bisheriger Premium Requests sollen GitHub AI Credits verbraucht werden. Nach GitHubs Darstellung zählen dafür Input Tokens, Output Tokens und Cached Tokens sowie das jeweils genutzte KI-Modell. Die Begründung ist nüchtern: Eine kurze Chatfrage verursacht andere Inferenzkosten als eine längere agentische Coding-Session.

Damit wird eine Entwicklung sichtbar, die über einen Anbieter hinausgeht. KI-Produkte entfernen sich von einfachen Nutzungsversprechen und rücken näher an Abrechnungsmodelle, die den tatsächlichen Ressourcenverbrauch abbilden. Das ist keine bloße Preisänderung. Es verändert, wie KI im Unternehmen geplant, begrenzt, gemessen und verantwortet werden muss.

Bei vielen Software-Abos war die Rechnung lange überschaubar. Ein Nutzerkonto kostete einen festen Betrag pro Monat. Ob die Anwendung intensiv oder nur gelegentlich genutzt wurde, änderte an der Abrechnung wenig. Generative KI passt nur bedingt in dieses Muster, weil zwei Anfragen mit derselben Oberfläche sehr unterschiedliche Rechenlast erzeugen können.

Die Aufspaltung zeigt die Copilot-Dokumentation zur nutzungsbasierten Abrechnung besonders deutlich. Funktionen wie Copilot Chat, CLI, Cloud Agent, Spaces, Spark und Drittanbieter-Agenten verbrauchen AI Credits. Code Completions und Next Edit Suggestions bleiben in bezahlten Plänen dagegen unbegrenzt enthalten. „Unbegrenzt“ bedeutet damit nicht mehr automatisch: Das gesamte Produkt kann ohne Verbrauchslogik genutzt werden. Es kann auch heißen: Einzelne Funktionen bleiben pauschal enthalten, während leistungsintensivere Funktionen nach Credits, Tokens oder Budgets gesteuert werden.

Bei Cursor zeigte sich 2025, wie erklärungsbedürftig solche Nutzungsversprechen geworden sind. In einer Klarstellung seines Preismodells schrieb das Unternehmen, der Pro-Plan enthalte unbegrenzte Nutzung von Tab und KI-Modellen im Auto-Modus, während Frontier-Modelle über ein monatliches Guthaben und danach zu API-Kosten abgerechnet würden. Cursor räumte ein, dass die Kommunikation rund um „unlimited usage“ nicht klar genug war. Interessant ist daran weniger der einzelne Vorgang als das Muster: KI-Abos müssen inzwischen genauer gelesen werden als klassische Flatrates.

Die relevante Frage verschiebt sich. Es reicht nicht mehr, die Zahl der Lizenzen und den Monatspreis zu vergleichen. Entscheidend ist, welche Funktionen tatsächlich pauschal enthalten sind, welche Nutzung ein Budget verbraucht, wie Zusatzverbrauch abgerechnet wird und ob sich kostenintensive Funktionen organisatorisch begrenzen lassen.

Tokens sind die Einheiten, in denen Sprachmodelle Texte verarbeiten und erzeugen. Mehr Kontext bedeutet mehr Input. Längere Antworten bedeuten mehr Output. Wiederkehrende Textbestandteile können je nach Anbieter über Caching günstiger werden, verschwinden aber nicht aus der technischen Rechnung. Schon diese Grundlogik reicht aus, um zu erklären, warum KI-Kosten im Betrieb stark schwanken können.

In typischen Unternehmensszenarien bleibt es selten bei einer isolierten Chatfrage. Eine Dokumentenanalyse lädt Vertragsentwürfe, Richtlinien, Protokolle oder technische Spezifikationen in den Kontext. Ein RAG-System ergänzt eine Anfrage um Ausschnitte aus internen Wissensbeständen. Ein Coding-Assistent bezieht Dateien, Tests, Fehlermeldungen und Abhängigkeiten im Projekt ein. Ein Agent führt Zwischenschritte aus, verwirft Ergebnisse, ruft Werkzeuge auf und probiert Alternativen. Aus einer Nutzeranfrage wird dann eine Folge von Modellaufrufen.

An Agenten wird der Kostenunterschied besonders greifbar. Cursor hat die Agentennutzung im Teams-Plan von festen Anfragekosten auf variable Kosten umgestellt, weil eine einfache Syntaxfrage weniger Aufwand verursacht als ein Agent, der einen vollständigen Pull Request umsetzen soll. In der Begründung zu Teams und Auto folgt der Preis also nicht der Oberfläche des Produkts, sondern der Arbeit, die im Hintergrund entsteht.

Diese Logik steckt auch in den öffentlichen API-Preislisten der KI-Anbieter. OpenAI unterscheidet auf seiner Preisseite zwischen Input, Cached Input und Output; Google trennt bei der Gemini API ebenfalls nach Input, Output, Kontext-Caching und zusätzlichen Funktionen wie Grounding. Der Listenpreis eines KI-Modells sagt daher nur begrenzt etwas über die Kosten eines konkreten Arbeitsprozesses aus. Entscheidend ist, wie viel Kontext verarbeitet wird, wie viel Output entsteht und wie oft ein System dieselbe Aufgabe intern wiederholt.

Gerade die Anwendungsfälle, die für den produktiven Einsatz interessant sind, erzeugen deshalb Kostenunsicherheit: interne Wissenssuche, Dokumentenprüfung, Code-Analyse, Support-Vorverarbeitung, Recherche, Zusammenfassungen großer Datenbestände und mehrstufige Assistenzprozesse. Sie sind nicht teuer, weil KI grundsätzlich teuer wäre. Sie sind schwer kalkulierbar, weil ihr Verbrauch vom konkreten Ablauf abhängt.

Wenn Kosten an Tokens, Modellwahl und Nutzungstiefe hängen, ist eine monatliche Lizenzübersicht zu grob. Benötigt werden Budgets, Rollenrechte, Modellfreigaben, Protokolle, Warnschwellen und eine Zuordnung zu Teams oder Projekten. Diese Steuerung muss vor dem breiten Rollout festgelegt werden, nicht erst nach der ersten unerwartet hohen Rechnung.

GitHub sieht für Copilot Budgets auf mehreren Ebenen vor, etwa für Enterprise, Organisationen, Cost Center und einzelne Nutzer. Sind Credits ausgeschöpft, kann zusätzliche Nutzung berechnet oder der Zugriff bis zum nächsten Abrechnungszeitraum blockiert werden. Das hilft bei der Begrenzung, ersetzt aber keine fachliche Bewertung. Ein harter Stopp schützt das Budget, kann aber auch eine produktive Aufgabe mitten im Ablauf unterbrechen.

Ähnliche Steuerungsentscheidungen tauchen bei Claude auf. In bezahlten Claude-Plänen kann nach Erreichen der enthaltenen Nutzung auf Extra Usage zu Pay-as-you-go-Konditionen umgeschaltet werden. Bei Claude Code lässt sich die Nutzung von API-Credits bewusst ausschließen, damit das Werkzeug nur innerhalb des Plan-Kontingents arbeitet. Solche Optionen sind sinnvoll, zeigen aber auch: Kostenkontrolle entsteht nicht automatisch durch den Kauf eines Abos. Sie muss konfiguriert und organisatorisch verstanden werden.

In kleineren und mittleren Organisationen landet diese Aufgabe häufig nicht bei spezialisierten FinOps- oder Plattformteams, sondern bei IT-Leitung, Fachbereich und Geschäftsführung. Dann zählt Verständlichkeit. Wer KI freigibt, sollte wissen, welche KI-Modelle für welche Aufgaben erlaubt sind, welche Nutzergruppen agentische Funktionen verwenden dürfen und ab wann Zusatzverbrauch blockiert wird. Ohne diese Klärung wird die Abrechnung zu einem nachgelagerten Kontrollinstrument. Dafür ist sie zu spät.

Tokenbasierte Abrechnung klingt zunächst nach Einkauf und Controlling. Im KI-Betrieb berührt sie aber unmittelbar die Datenkontrolle. Ein langer Kontext ist nicht nur eine größere Recheneinheit. Er ist ein größeres Datenpaket. Darin können Quellcode, Kundendaten, Verträge, interne Richtlinien, Tickets, Protokolle oder technische Dokumentationen enthalten sein.

Wenn ein KI-Assistent passende Dokumente automatisch in den Prompt lädt, stellen sich zwei Fragen gleichzeitig: Was kostet diese Verarbeitung, und wohin fließen die Daten? Relevant sind Speicherort, Protokollierung, Zugriff auf Logs, Löschfristen, Rechtekonzepte und die Möglichkeit, nachzuvollziehen, welche Inhalte in welchem Zusammenhang verarbeitet wurden. Ein Hinweis auf „Enterprise-ready“ oder „DSGVO-konform“ beantwortet diese Punkte nicht. Belastbar wird eine solche Aussage erst, wenn die technische Umsetzung sichtbar ist.

Maßnahmen zur Kostenbegrenzung und Maßnahmen zur Vertraulichkeit liegen deshalb oft nahe beieinander. Weniger unnötiger Kontext senkt nicht nur den Verbrauch, sondern reduziert auch die Menge sensibler Informationen, die in KI-Aufrufe einfließt. Eine präzisere Dokumentenauswahl, begrenzte Chatverläufe, saubere Retrieval-Konfigurationen und rollenbasierte Zugriffe verbessern zugleich Kalkulierbarkeit und Datenminimierung.

Umgekehrt können schlecht konfigurierte Systeme doppelt problematisch werden. Sie hängen bei jeder Anfrage zu viele Dokumente an, erzeugen hohe Tokenverbrauch und verarbeiten mehr interne Informationen als fachlich nötig. Der Preis steckt dann tatsächlich im Kontext, aber der Kontext ist nicht nur eine Kostenposition. Er ist Teil der Sicherheits- und Datenschutzarchitektur.

Tokenbasierte Abrechnung macht sichtbar, dass KI-Nutzung nicht nur vom gewählten KI-Modell abhängt, sondern vom gesamten Nutzungsmuster. Je häufiger ein Unternehmen interne Dokumente analysiert, Wissensbestände durchsucht, Supportfälle vorbereitet oder Codebestände auswertet, desto weniger handelt es sich um gelegentliche Einzelanfragen. Es entstehen wiederkehrende Lastprofile, die dauerhaft geplant werden müssen.

Die FinOps Foundation behandelt solche KI-Workloads in ihrem Papier zur Kostenabschätzung von AI Workloads nicht als reine Abrechnungsposition, sondern als Planungsaufgabe über Entwicklung, Pilotierung und produktiven Betrieb hinweg. Genau dort wird lokal betriebene KI relevant. Nicht, weil sie KI kostenlos macht oder für jeden Anwendungsfall die bessere Antwort wäre. Ihr Vorteil liegt in einer anderen Betriebslogik: Kapazitäten, Datenflüsse, Zugriffe und technische Grenzen können stärker innerhalb der eigenen oder kontrollierten Infrastruktur geplant werden.

Die Kosten verschieben sich dabei von laufendem Einzelverbrauch zu Infrastruktur, Kapazität, Auslastung, Wartung, Monitoring und Verantwortlichkeit. Das ist kein kleiner Unterschied. Ein externes Verbrauchsmodell rechnet umfangreiche Verarbeitung nach Tokens, Credits oder Nutzungsklassen ab. Lokal betriebene KI verlangt dagegen eine vorgelagerte Entscheidung, welche Workloads regelmäßig genug auftreten, um Kapazitäten dafür bereitzustellen.

Diese Frage wird besonders relevant, wenn hohe Nutzung und vertrauliche Daten zusammenfallen. Lange Kontexte enthalten in Unternehmensanwendungen selten nur unkritische Texte. Häufig geht es um Vertragsentwürfe, Kundenvorgänge, technische Dokumentation, Tickets, Richtlinien oder Quellcode. Die Datenschutzkonferenz behandelt in ihrer Orientierungshilfe zu RAG-Systemen mit unternehmens- oder behördeneigenen Wissensquellen deshalb nicht nur Modellleistung und Antwortqualität, sondern auch Zweckbindung, Zugriff, Transparenz und Datenminimierung.

Lokal betriebene KI ist deshalb keine pauschale Antwort auf steigende oder schwer planbare Cloud-Kosten. Sie wird aber zu einer regulären Architekturfrage, wenn Unternehmen wiederkehrende KI-Nutzung mit sensiblen Informationen verbinden. Der mögliche Vorteil liegt dann nicht nur in einer anderen Kostenstruktur, sondern in mehr Kontrolle darüber, welche Daten verarbeitet werden, wer darauf zugreifen kann und welche technischen Grenzen ein System einhalten muss. Solche Anforderungen gehören nicht erst in den laufenden Betrieb, sondern müssen vor dem Rollout fachlich und technisch geklärt werden.

Viele Kostenprobleme entstehen, bevor die erste Rechnung kommt. Ein Chatbot, der kurze Fragen beantwortet, stellt andere Anforderungen als ein System, das bei jeder Anfrage interne Dokumente durchsucht. Ein Coding-Assistent mit einfachen Vervollständigungen ist anders zu bewerten als ein Agent, der Aufgaben über mehrere Dateien und Tests hinweg selbstständig bearbeitet. Eine Fachabteilung, die gelegentlich Texte zusammenfasst, erzeugt ein anderes Verbrauchsmuster als ein Support-Team, das täglich hunderte Vorgänge mit KI vorverarbeitet.

Vor einem Rollout sollte deshalb nicht nur der Tarifvergleich stehen. Sinnvoller ist eine technische Nutzungsbeschreibung: Welche Daten gelangen in den Kontext? Wie lang sind Prompts und Antworten realistisch? Werden Dokumente mehrfach verarbeitet? Gibt es Agentenschleifen? Welche Modelle werden für welche Aufgaben freigegeben? Welche Nutzung darf automatisch stattfinden, und wo sind Grenzen nötig?

Aus dieser Betrachtung folgt keine pauschale Architekturentscheidung. Manche Anwendungsfälle lassen sich mit einem gut konfigurierten SaaS- oder API-Modell ausreichend steuern, wenn Budgets, Logging, Modellfreigaben und Rechte sauber gesetzt sind. Andere sprechen für hybride Ansätze, bei denen vertrauliche oder häufige Aufgaben lokal laufen, während externe KI-Modelle für ausgewählte Fälle genutzt werden. Wieder andere Organisationen werden lokal betriebene KI bevorzugen, weil sie Datenverarbeitung, Zugriffe und Kapazitäten enger kontrollieren wollen.

Tragfähig wird KI erst, wenn Kostenmodell, Datenfluss und Betriebsmodell zusammenpassen. Wer nur Nutzerlizenzen einkauft, übersieht die technische Kostenlogik. Wer nur auf lokale Infrastruktur setzt, ohne Auslastung, Betrieb und Modellpflege realistisch zu bewerten, ersetzt variable API-Kosten durch andere Aufwände. Beides kann richtig sein. Beides kann scheitern, wenn der Kontext nicht verstanden wird.

Die Umstellung von unbegrenzter oder pauschal wirkender KI-Nutzung auf token-, credit- und limitbasierte Modelle ist kein Randthema der Anbieterabrechnung. Sie folgt daraus, dass KI-Systeme längere Kontexte, leistungsfähigere KI-Modelle und agentische Arbeitsweisen nutzen. Der sichtbare Monatspreis sagt dadurch weniger darüber aus, was produktive Nutzung tatsächlich kostet.

Für Unternehmen wird KI damit stärker zur Infrastrukturfrage. Wo Kontext verarbeitet wird, entstehen Kosten. Wo Kontext verarbeitet wird, fließen Daten. Beides braucht Transparenz: eingesetzte KI-Modelle, Tokens, Budgets, Rollen, Speicherorte, Protokolle und technische Grenzen.

Lokal betriebene KI ist in diesem Umfeld nicht automatisch die bessere Lösung. Sie wird aber wichtiger, wenn hohe Nutzung, vertrauliche Informationen und der Bedarf nach planbarer Kontrolle zusammenkommen. Die passende Architektur ergibt sich nicht aus einem Preismodell allein, sondern aus der nüchternen Frage, welche Daten mit welchem Aufwand unter wessen Kontrolle verarbeitet werden sollen.