In den Anwender-Communities rund um Enterprise-KI-Plattformen hat sich in den letzten Wochen etwas verschoben. Die Diskussionen drehen sich nicht mehr primär um Modell-Vergleiche oder neue Features. Sie drehen sich um Token-Budgets: Welche Regel kostet mich bei jedem Prompt Kontext? Wie lade ich Wissen nur dann, wenn es relevant ist? Wann lohnt sich eine Abfrage überhaupt?

Der Hintergrund: Praktisch alle Plattformen rechnen die Nutzung in Tokens ab, der Verrechnungseinheit für alles, was ein Sprachmodell liest und schreibt. Jedes Dokument im Kontext, jede Systemregel, jede Workflow-Iteration verbraucht Budget. Solange dein Unternehmen in der Pilotphase war, ist das kaum aufgefallen. Jetzt, wo Agenten und Automatisierungen produktiv laufen, wird der Verbrauch zur monatlichen Kennzahl.

Das Bemerkenswerte daran: Die erfahrensten Nutzer empfinden das nicht als Ärgernis, sondern als sinnvolle Disziplin. In einer Diskussion fiel der Begriff der Benzinpreis-Taktik: Der Preis reguliert den Verbrauch, und wer bewusst fährt, kommt weiter. Genau diese Haltung trennt gerade die reifen KI-Organisationen von denen, die noch Lizenzen zählen. Aus unserer täglichen Arbeit mit KI-Rollouts im Mittelstand sehen wir drei Patterns, an denen sich das konkret festmachen lässt.

Der System-Prompt ist kein Gratis-Speicher

Das erste Pattern betrifft eine Stelle, an die viele Admins zuletzt denken: die unternehmensweite Beschreibung, die dem Modell bei jeder Anfrage mitgegeben wird. Fast jede Plattform bietet so ein Feld an, oft mit großzügigem Zeichenlimit. Es wirkt wie der natürliche Ort für alles, was immer gelten soll: Schreibstil, Sprachregeln, Compliance-Hinweise, Firmenkontext.

Ein reales Beispiel aus der Community: Ein Unternehmen muss gendergerechte Sprache in allen KI-Antworten durchsetzen, workspace-weit, als Vorgabe des Diversity Managements. Das vollständige Regelwerk umfasst rund 8.000 Zeichen, inklusive Schreibkonventionen und bevorzugtem Vokabular. In die zentrale Unternehmensbeschreibung kopiert wäre das Problem scheinbar gelöst.

Nur: Diese 8.000 Zeichen werden dann mit jedem einzelnen Prompt jedes Mitarbeiters mitgeschickt. Bei tausenden Anfragen pro Woche summiert sich das zu einem spürbaren Anteil des Token-Budgets, und es füllt das Kontextfenster, bevor die eigentliche Aufgabe überhaupt beginnt. Die Faustregel dahinter: Alles, was bei jedem Prompt mitgesendet wird, kostet bei jedem Prompt. Die Alternative, die erfahrene Admins wählen, sind modulare Regelpakete (auf den meisten Plattformen Skills genannt), die nur dann geladen werden, wenn sie greifen sollen. Das ist konfigurativ anspruchsvoller, aber es ist der Unterschied zwischen einer Regel, die immer bezahlt wird, und einer Regel, die nur bei Bedarf Kontext kostet.

Kontext nach Relevanz laden, nicht nach Ordner

Das zweite Pattern folgt derselben Logik auf der Wissensebene. Viele Teams legen ihre Dokumentation in Ordnerstrukturen ab und verbinden diese mit ihrem KI-Workspace. Komfortabel, aber die meisten Systeme lesen dann den gesamten Ordner in den Kontext, egal ob die Frage ein Dokument betrifft oder alle vierzig.

Power-User fordern deshalb zunehmend relevanzbasiertes Laden: Das System prüft zuerst, welche Datei für die konkrete Anfrage gebraucht wird, und lädt nur diese. Als Vorbild dient das Routing-Muster moderner Agent-Systeme, die über kompakte Indexdateien entscheiden, welcher Kontext wann gezogen wird. Für wissensintensive Setups, etwa Knowledge-Agenten mit gepflegten Kontextbeständen, macht das den Unterschied zwischen einem System, das bei jeder Frage das halbe Firmenwiki einliest, und einem, das gezielt zwei Seiten holt.

Wenn du gerade eine Wissensarchitektur für KI aufbaust, denk diese Frage von Anfang an mit: Nicht "Was geben wir dem Modell alles mit?", sondern "Was braucht das Modell für genau diese Aufgabe?". Das ist keine Kostenkosmetik. Kleinerer, präziserer Kontext liefert auch bessere Antworten, weil das Modell weniger Irrelevantes gewichten muss.

Push statt Pull: die teuerste Abfrage ist die überflüssige

Das dritte Pattern zeigt sich am deutlichsten bei Systemanbindungen. Der Klassiker: Ein Unternehmen will sein ERP an die KI anschließen, damit Mitarbeiter Fragen an die Daten stellen können. Klingt nach dem naheliegenden Use Case, und technisch ist es über Schnittstellen wie MCP inzwischen gut machbar.

In der Praxis berichten ERP-erfahrene Anwender von einem wiederkehrenden Muster: Nutzer ziehen ohne Einschränkung zwei Jahre Produktionsdaten in den Kontext, um eine Frage zu beantworten, die ein Dashboard in einer Sekunde geklärt hätte. Die ehrliche Analyse dahinter: Die meisten "Verbindet unsere KI mit dem ERP"-Anfragen bedeuten eigentlich "Ich will Fragen stellen, die meine Reports nicht abdecken". Dafür reicht oft ein sauberer, regelmäßiger Export in eine Lesedatenbank, deutlich sicherer als ein Live-Zugriff auf die Produktion und um Größenordnungen günstiger.

Der größere Hebel liegt aber in der Umkehrung des Musters. Statt dass die KI teuer im System nachfragt (Pull), meldet das System relevante Zustandsänderungen und stößt damit eine Automatisierung an (Push): Lagerbestand unterschreitet den Schwellwert, ein Workflow startet, die Bestellung wird vorbereitet. Das verbraucht nur dann Tokens, wenn tatsächlich etwas passiert. Und es erledigt echte Arbeit, statt Fragen zu beantworten, die niemand hätte stellen müssen.

Was das für deinen Rollout heißt

Was hier entsteht, ist im Kern FinOps für KI: dieselbe Reifung, die Cloud-Kosten vor zehn Jahren durchlaufen haben. Erst war Rechenleistung scheinbar grenzenlos, dann kamen die Rechnungen, dann entstanden Kostenbewusstsein und Architektur-Reviews. Bei KI passiert das gerade im Zeitraffer, und die Plattformen ziehen nach: Kosten-Sichtbarkeit pro Agent und Use Case gehört zu den meistgeforderten und zuletzt auch gelieferten Governance-Funktionen.

Vier Handlungsfelder ergeben sich daraus:

1. Kostentransparenz einfordern. Wenn deine Plattform Token-Verbrauch pro Agent, Team oder Use Case ausweisen kann, aktiviere das und schau monatlich drauf. Ohne Messung keine Steuerung.

2. Den Always-on-Kontext auditieren. Prüfe, was bei jedem Prompt mitgesendet wird: Unternehmensbeschreibung, Systemregeln, Standard-Anhänge. Alles, was nicht immer gebraucht wird, gehört in bedarfsgeladene Module.

3. Wissensarchitektur auf Relevanz umstellen. Statt ganze Ordner anzubinden, kuratiere kompakte, gezielt ladbare Wissensbausteine. Weniger Kontext pro Anfrage heißt geringere Kosten und bessere Antworten.

4. Automatisierungen event-getrieben denken. Bevor du ein Quellsystem für KI-Abfragen öffnest, stell die Gegenfrage: Welche Zustandsänderung in diesem System sollte von sich aus eine Aktion auslösen? Meistens ist das der wertvollere und günstigere Use Case.

Take

Token-Disziplin erzwingt gute Architektur. Wer sich fragt, ob eine Regel wirklich bei jedem Prompt mitlaufen muss, baut sauberere Governance. Wer Kontext nach Relevanz lädt, bekommt präzisere Antworten. Wer Push statt Pull denkt, baut Automatisierungen, die Arbeit erledigen statt Daten spazieren zu führen. Die Kostenfrage ist der Anlass, die Qualitätsverbesserung ist der Effekt.

Token-Limits verschwinden nicht. Die Modelle werden günstiger, aber die Ambitionen wachsen schneller als die Preise fallen. Wer Token-Ökonomie jetzt als Kompetenz aufbaut, hat in zwölf Monaten nicht nur niedrigere Rechnungen, sondern die robusteren KI-Systeme.

Enablement-Gespräch buchen (30 Min mit Sarah)