Kostengrenze für KI im Gateway statt Überraschung auf der Monatsrechnung

Eine Kostengrenze für KI gehört nicht in die Tabelle der Buchhaltung, sondern an die Stelle, an der eine Anwendung das Sprachmodell aufruft. Anwendungen, die im Betrieb Sprachmodelle nutzen, rufen sie bei uns über ein eigenes Gateway auf, und die Grenze greift dort, bevor eine Rechnung entsteht. Warum das beim Wechsel vom Pilot in den Betrieb zählt.

Warum im Pilot niemand nach den Kosten fragt

Ein Pilot ist klein gebaut, und das ist richtig so. Eine Handvoll Leute probiert eine Anwendung aus, das Modell wird selten aufgerufen, abgerechnet wird über ein Konto, das jemand aus der IT mit der Firmenkarte angelegt hat. Die Beträge liegen unter jeder Schwelle, bei der jemand nachfragt. Im Abschlussbericht steht, dass es funktioniert – nicht aber, was ein einzelner Vorgang kostet.

Im Betrieb verschiebt sich das an drei Stellen zugleich. Derselbe Aufruf läuft jetzt für jedes eingehende Dokument, jede Kundenanfrage, jeden nächtlichen Durchlauf. Mehrere Abteilungen haben inzwischen eigene Zugänge bei eigenen Anbietern, jede mit eigener Abrechnung. Und ein einziger Fehler – etwa ein Job, der einen gescheiterten Aufruf ohne Ende wiederholt – vervielfacht die Aufrufe über Nacht, ohne dass es jemand sieht. Die Frage der Geschäftsführung lautet dann nicht mehr, ob das funktioniert, sondern was ein Vorgang kostet und wer es bemerkt hätte, wenn es plötzlich ein Vielfaches ist.

Kostengrenze für KI: warum sie im Gateway sitzt

Eine Grenze lässt sich an drei Stellen setzen. Die erste ist das Konto beim Anbieter: ein Budget, das greift, sobald es erreicht ist. Das ist besser als nichts, aber grob – eine Zahl für alle Anwendungen, und ist sie erreicht, stehen alle gleichzeitig still, auch die sparsamen. Die zweite ist die Anwendung selbst: Jede zählt ihre Aufrufe und hört bei einem Wert auf. Das hält genau so lange, bis die nächste Anwendung entsteht und jemand die Zählung vergisst.

Die dritte Stelle liegt zwischen Anwendungen und Anbietern, und dort sitzt die Grenze bei uns: ein eigenes Gateway mit harter Kostengrenze. Ist sie erreicht, geht der Aufruf nicht mehr hinaus. Im Alltag hat das drei Folgen:

• Eine Stelle statt vieler. Die Grenze wird einmal gebaut und gilt für jede Anwendung, die über das Gateway geht – auch für die, die erst im nächsten Jahr dazukommt.
• Die Grenze kommt vor der Rechnung. Ein fehlerhafter Nachtlauf endet an der Grenze und nicht als Posten auf der Abrechnung des Folgemonats.
• Verbrauch lässt sich zuordnen. Weil die Aufrufe einer Anwendung immer denselben Weg nehmen, lässt sich der Verbrauch ihr zuordnen, statt eine Sammelrechnung im Nachhinein aufzuteilen.

In Kundenprojekten übertragen wir dieses Muster auf die Systeme des Auftraggebers. Wie das in gewachsene Anwendungen eingebaut wird, beschreibt die Seite KI-Integration in bestehende Systeme.

Was sich beim Übergang vom Pilot in den Betrieb ändert

Das Gateway ist kein Projektziel für sich. Es ist der Ort, an dem vier Fragen eine Antwort bekommen, die im Pilot offenbleiben durften.

1. Welche Grenze für welchen Vorgang? Eine Monatszahl für das ganze Haus sagt wenig. Aussagekräftiger ist eine Grenze je Anwendung oder je Vorgang, abgeleitet aus dem, was dieser Vorgang heute von Hand kostet. Wie sich Token-Kosten überhaupt zusammensetzen, erklärt das Lexikon.
2. Was wird festgehalten? Welche Anwendung wann welches Modell aufgerufen hat, mit welchem Ergebnis und mit welchen Daten. Welche Angaben dazu gehören und welche Daten beim Anbieter ankommen, halten wir im Angebot fest.
3. Wer erfährt es, wenn die Grenze näher rückt? Eine Grenze, die erst beim Erreichen auffällt, hat den Vorgang schon angehalten. Die Warnung muss vorher kommen, und zwar bei einer zuständigen Person.
4. Was passiert beim Erreichen? Der Vorgang pausiert, ein Mensch übernimmt, oder die Anwendung weicht auf einen einfacheren Weg ohne Modell aus. Welche Variante gilt, ist eine fachliche Entscheidung und keine technische.

Dazu kommt ein Nebeneffekt: Wer später das Modell oder den Anbieter wechselt, ändert das Gateway und nicht jede einzelne Anwendung.

Was eine Kostengrenze für KI nicht leistet

Eine harte Grenze verhindert Überraschungen auf der Rechnung, aber keine Verschwendung unterhalb der Grenze. Eine Anwendung, die das Modell für jedes Dokument zweimal aufruft, obwohl einmal genügt, bleibt sauber im Rahmen und kostet trotzdem das Doppelte. Die Grenze ist eine Sicherung, keine Optimierung; ob ein Aufruf nötig war, zeigt erst der Blick in die Aufzeichnung.

Die zweite Einschränkung wiegt schwerer. Eine zu knapp gesetzte Grenze hält einen Vorgang an, der eigentlich funktioniert. Wer nachts einen Stapel Eingangsrechnungen verarbeiten lässt und morgens feststellt, dass ein Teil liegen geblieben ist, weil die Grenze gegriffen hat, hat ein Betriebsproblem und kein Kostenproblem. Eine Grenze sollte deshalb nicht aus dem Bauch gesetzt werden, sondern erst, wenn der tatsächliche Verbrauch des Vorgangs eine Weile sichtbar war.

Die dritte betrifft den Umfang. Das Gateway sieht nur, was Anwendungen aufrufen. Wer im Browser einen Chatdienst mit eigenem Konto nutzt, geht daran vorbei. Dafür braucht es eine Regel im Unternehmen und keine Technik – ein Gateway ersetzt keine KI-Richtlinie.

In Kundenprojekten beginnen wir darum nicht mit dem Gateway, sondern mit einer Bestandsliste: welche Anwendungen heute Sprachmodelle aufrufen, über welche Konten und mit welchen Daten. Steht diese Liste, lässt sich festlegen, welche Grenze für welchen Vorgang gilt, wer die Warnung bekommt und was beim Erreichen geschieht. Genau diese Punkte stehen anschließend als Abnahmekriterien im Angebot.