Die häufigste Überraschung bei KI-Projekten ist keine technische. Sie steht auf der ersten Monatsrechnung nach dem Produktivstart und liegt regelmäßig um ein Vielfaches über der Hochrechnung aus dem Piloten. Bemerkenswert daran ist, dass die Nutzung meist exakt der Schätzung entspricht. Teurer geworden ist nicht das Verhalten der Anwender, sondern die Anwendung selbst.
Die Ursache ist unspektakulär und genau deshalb hartnäckig: Programmierfehler, die in klassischen Systemen belanglos wären, werden teuer, sobald ein KI-Modell die Arbeit ausführt. Eine Schleife, die zu oft läuft, kostet auf einem eigenen Server nichts außer Rechenzeit. Dieselbe Schleife gegen ein Sprachmodell kostet bei jedem Durchlauf Geld.
Selbst Konzerne mit ausgereiften Kostenprozessen bemerken solche Abweichungen erst Monate später. Für ein Unternehmen mit 30 Mitarbeitenden ist die Frage deshalb nicht, ob es passieren kann, sondern wann es auffällt.
Warum KI-Budgets anders reißen als IT-Budgets
Klassische Unternehmenssoftware hat ein einfaches Kostenmodell: Lizenz pro Arbeitsplatz, Server pro Monat, Wartung pro Jahr. Diese Beträge sind vor dem ersten Nutzungstag bekannt. Ein Softwarefehler kostet in diesem Modell Arbeitszeit und Nerven, aber keine zusätzlichen Rechnungspositionen.
KI-Anwendungen kehren das um. Bezahlt wird pro Verarbeitungseinheit, in der Regel pro Token, also pro Textbaustein in Ein- und Ausgabe. Damit verschiebt sich die Kostenlogik von der Anschaffung in den Betrieb. Jede Anfrage ist ein Kaufvorgang. Und jede fehlerhafte Anfrage ist ein Kaufvorgang ohne Gegenwert.
Der Pilot lügt, ohne es zu wollen
Im Piloten testen fünf Personen mit kurzen, wohlformulierten Eingaben. Die Hochrechnung auf 50 Personen wirkt sauber und ergibt einen Faktor zehn. Im Produktivbetrieb hängen Nutzer aber PDF-Dokumente an, führen lange Gespräche, deren Verlauf bei jeder Folgefrage komplett mitgeschickt wird, und die Anwendung greift zusätzlich auf eine Wissensdatenbank zu. Die Anzahl der Anfragen steigt um Faktor zehn, die Datenmenge pro Anfrage aber ebenfalls. Beides multipliziert sich.
Die Rechnung kommt später als der Fehler
Cloud-Abrechnung ist nachlaufend. Zwischen dem Deployment, das eine Wiederholungsschleife einbaut, und der Rechnung, die das sichtbar macht, liegen im schlechtesten Fall Wochen. In dieser Zeit arbeitet der Fehler weiter. Das ist der entscheidende Unterschied zu einem Ausfall: Ein abgestürzter Dienst meldet sich sofort, ein zu teurer Dienst funktioniert tadellos und schweigt. Das Problem ist deshalb nie der Preis pro Anfrage, sondern die fehlende Grenze.
Die fünf Kostentreiber, die niemand einplant
In der Praxis stammen Kostenabweichungen fast immer aus denselben fünf Quellen. Keine davon steht im ursprünglichen Angebot.
| Kostentreiber | Was ihn auslöst | Gegenmaßnahme |
|---|---|---|
| Kontextlänge | Gesprächsverlauf und angehängte Dokumente werden bei jeder Folgefrage erneut mitgeschickt | Verlauf nach n Schritten zusammenfassen, Dokumentabschnitte gezielt statt vollständig laden |
| Ausgabelänge | Ausgabe-Token kosten ein Vielfaches der Eingabe-Token, Modelle mit Zwischenschritten erzeugen zusätzlich unsichtbare Denk-Token | Harte Obergrenze für die Antwortlänge, knappe Ausgabeformate vorgeben |
| Wiederholungen | Zeitüberschreitungen und fehlgeschlagene Formatprüfungen lösen automatische Neuversuche aus | Maximal zwei Versuche, danach Fehler melden statt still weiterprobieren |
| Agentenschleifen | Ein Agent ruft Werkzeuge auf, bewertet das Ergebnis und startet erneut, ohne definiertes Abbruchkriterium | Iterationslimit und Kostenlimit pro Auftrag, beides technisch erzwungen |
| Testläufe | Jede Qualitätsmessung über den gesamten Testdatensatz erzeugt dieselben Kosten wie echter Betrieb | Kleinere Stichprobe für tägliche Läufe, vollständiger Durchlauf nur vor Releases |
Auffällig ist, dass vier von fünf Treibern nichts mit dem Preis des Modells zu tun haben. Sie sind Architekturentscheidungen. Wer die Kosten senken will, verhandelt nicht mit dem Anbieter, sondern räumt im eigenen System auf. Dasselbe Muster beschreiben wir im Artikel zum ROI von KI-Agenten: Der Engpass liegt selten in der Technologie.
Guardrails: Grenzen im System statt in der Richtlinie
Eine Betriebsvereinbarung, die zu sparsamem Umgang mit KI-Werkzeugen auffordert, hat noch nie eine Rechnung gesenkt. Wirksam sind nur Grenzen, die das System selbst durchsetzt. Diese sechs sollten stehen, bevor die erste produktive Anfrage läuft:
- Hartes Ausgabenlimit pro Projektschlüssel. Nicht pro Unternehmen, sondern pro Anwendung. Jedes seriöse Anbieterkonto kann das. Ein durchgebrannter Schlüssel legt dann eine Anwendung lahm und nicht das Budget.
- Tägliche statt monatliche Kostenwarnung. Eine Meldung bei 50 und bei 80 Prozent des Tagesbudgets, direkt in den Kanal, in dem das Team ohnehin arbeitet.
- Obergrenze für Ein- und Ausgabelänge pro Anfrage. Verhindert, dass ein versehentlich hochgeladenes 400-seitiges Handbuch zum Kostentreiber wird.
- Iterationslimit für Agenten. Jeder autonome Ablauf braucht ein Abbruchkriterium, das nicht vom Modell selbst bewertet wird.
- Zwischenspeicherung. Identische Anfragen und wiederkehrende Systemanweisungen müssen nicht jedes Mal neu bezahlt werden. Das ist oft die günstigste einzelne Maßnahme.
- Kostenzuordnung über Kennzeichnungen. Jede Anfrage bekommt eine Markierung für Team, Funktion und Anwendungsfall. Ohne diese Zuordnung sehen Sie nur eine Summe und wissen nicht, welches Feature sie verursacht hat.
Praxistipp: Bauen Sie das Ausgabenlimit vor dem ersten Feature ein, nicht nach dem ersten Vorfall. Der Aufwand liegt bei wenigen Stunden, solange die Anwendung klein ist. Nachträglich in ein gewachsenes System eingezogen, wird daraus ein Refactoring quer durch alle Aufrufpfade. Wir setzen das bei jeder KI-Integration vor der ersten produktiven Anfrage auf.
Rechenbeispiel: der Faktor, den der Pilot verschweigt
Ein Beispiel ohne Preisangaben, weil die Modellpreise sich ändern, das Verhältnis aber stabil bleibt. Angenommen, 20 Mitarbeitende nutzen einen internen KI-Assistenten mit je 15 Anfragen pro Arbeitstag. Das ergibt bei 20 Arbeitstagen rund 6.000 Anfragen im Monat.
- Pilotannahme: 4.000 Token pro Anfrage. Kurze Frage, kurze Antwort, kein Verlauf.
- Mit Gesprächsverlauf: ab dem fünften Austausch typischerweise 12.000 Token, weil die gesamte bisherige Unterhaltung erneut übertragen wird. Faktor 3.
- Mit Dokumentenzugriff: drei Abschnitte aus der Wissensdatenbank ergeben rund 25.000 Token. Faktor 6 gegenüber der Pilotannahme.
- Mit zwei Neuversuchen bei Formatfehlern: in den betroffenen Fällen erneut Faktor 3 obendrauf.
Niemand tippt in diesem Szenario mehr als geplant. Die Nutzung ist exakt so, wie sie im Piloten geschätzt wurde. Trotzdem liegt die Rechnung um ein Vielfaches über der Hochrechnung, und zwar allein durch Architekturentscheidungen, die zwischen Pilot und Betrieb getroffen wurden.
Deshalb ist die brauchbare Kennzahl nicht die Monatssumme, sondern die Kosten pro Geschäftsvorfall: pro beantwortetem Ticket, pro geprüfter Rechnung, pro erstelltem Angebot. Diese Zahl lässt sich direkt gegen die eingesparte Arbeitszeit stellen, und sie schlägt sofort aus, wenn eine Änderung am Prompt teuer geworden ist. Die Monatssumme fällt erst auf, wenn der Schaden schon entstanden ist. Wer diese Rechnung vor dem Projektstart aufmacht, findet die Systematik im Artikel zum Software-Budget für KMU.
Kostenkontrolle organisatorisch verankern
Technische Grenzen greifen nur, wenn jemand die Zahlen ansieht. Vier organisatorische Punkte, die in der Praxis den Unterschied machen:
1. Ein Name, keine Abteilung
"Die IT achtet auf die Kosten" bedeutet in der Praxis, dass niemand darauf achtet. Das KI-Budget braucht eine benannte Person mit der Befugnis, ein Feature abzuschalten. In kleineren Unternehmen ist das die Geschäftsführung oder eine technische Leitung auf Zeit, wie sie unser Interim CTO übernimmt.
2. Kosten im selben Termin wie Features
Der Kostenbericht gehört in dieselbe wöchentliche Runde, in der über den Entwicklungsfortschritt gesprochen wird. Getrennte Termine führen dazu, dass die Kostenfrage erst zur Budgetplanung auftaucht.
3. Abbruchkriterium vor dem Start
Legen Sie vor Projektbeginn fest, bei welchem Verhältnis von Kosten zu Nutzen Sie aussteigen. Wer das erst im laufenden Projekt diskutiert, diskutiert mit versunkenen Kosten im Rücken und entscheidet dann selten sachlich. Wie oft das schiefgeht, zeigt der Artikel warum KI-Projekte scheitern.
4. Vertragsklauseln prüfen
Drei Punkte gehören in jeden Vertrag mit einem KI-Anbieter: Wie werden Preisänderungen angekündigt? Können Sie Ihre Daten und Konfigurationen exportieren? Ist ein Modellwechsel technisch möglich, ohne die halbe Anwendung neu zu bauen? Der dritte Punkt ist der teuerste, wenn er fehlt.
Merksatz für die Praxis: Wer nicht weiß, was ein einzelner Geschäftsvorfall in seiner KI-Anwendung kostet, betreibt sie nicht, sondern hofft. Diese eine Zahl zu ermitteln, dauert selten länger als einen Tag, und sie beendet die meisten Diskussionen über KI-Rentabilität schneller als jede Präsentation.
Fazit: Grenzen zuerst, Funktionen danach
KI-Kosten entgleisen nicht, weil Modelle teuer sind. Sie entgleisen, weil ein Kostenmodell mit variablen Stückkosten auf Entwicklungspraktiken trifft, die für fixe Lizenzkosten gedacht waren. Ein Neuversuch bei Fehlern war jahrzehntelang eine gute Idee. Gegen ein Sprachmodell ist er ein Rechnungsposten.
Der praktische nächste Schritt ist klein: Nehmen Sie Ihre bestehende oder geplante KI-Anwendung, ermitteln Sie die Kosten für einen einzelnen Geschäftsvorfall und setzen Sie ein hartes Ausgabenlimit auf den Projektschlüssel. Diese zwei Maßnahmen kosten einen Tag Arbeit und verhindern den Großteil der Abweichungen, die sonst erst mit der Rechnung sichtbar werden. Alles Weitere lässt sich danach in Ruhe optimieren.