Niemand kontrolliert die KI-Rechnung

In AI-Kreisen macht eine Geschichte die Runde. Ein Unternehmen soll bei Anthropic in einem Monat eine Rechnung über 500 Millionen Dollar aufgehäuft haben. Die Schuld trug Claude Code, der agentengesteuerte Coding-Assistent, der ohne Ausgabenlimits lief. Ob die Endsumme später verhandelt wurde oder die Geschichte beim Erzählen ausgeschmückt wurde, ist irrelevant. Der Punkt ist: Es ist völlig plausibel. Und genau das ist das Problem.

Die meisten Teams, die KI gerade einsetzen, tun das schnell. Das ist nicht falsch. Geschwindigkeit ist wichtig. Aber Geschwindigkeit ohne Kostenmodell ist einfach eine Methode, um im großen Maßstab Geld zu verlieren. Und die Agenturen und Produktteams, mit denen ich spreche, beobachten in den meisten Fällen den Output und ignorieren die Rechnung.

Der Teil, für den niemand budgetiert hat

Wenn ein Unternehmen ein SaaS-Tool einsetzt, weiß jemand in der Finanzabteilung, was es pro Nutzer kostet. Die Zahl steht in einem Vertrag. Er erneuert sich jährlich. Es gibt eine Zeile in der Tabelle.

KI-API-Nutzung funktioniert anders. Sie ist verbrauchsorientiert, sie wächst mit der Aktivität und wird kompliziert, wenn man Agenten daran anschließt. Ein Agent, der eine Schleife ausführt, es erneut versucht oder parallel läuft, schickt dir keine Warnung. Er läuft einfach. Claude, GPT-4o, Gemini, alle berechnen nach Token. Ein Coding-Agent, der sich durch eine große Codebasis arbeitet, kann Token schneller verbrauchen als jeder menschliche Ingenieur, der dieselben Dateien liest.

Die Mathematik ist nicht kompliziert. Kompliziert ist, dass die meisten Deployments stattfinden, bevor jemand die Mathematik gemacht hat. Ein Entwickler shipt ein Feature. Das Feature funktioniert. Das Feature skaliert. Die Rechnung kommt vier Wochen später an und niemand erkennt die Summe.

Das ist kein Technologieproblem. Das ist eine Governance-Lücke.

Wo Agenturen zuerst falsch liegen

Im Agentur-Kontext ist das Risiko spezifisch. Ihr deployt oft im Auftrag von Clients oder baut interne KI-Capability auf, um schneller mehr Clients zu bedienen. Beide Situationen schaffen dasselbe strukturelle Problem: Die Person, die die Deployment-Entscheidung getroffen hat, ist nicht die Person, die die Rechnung sieht.

Ich habe drei Fehlermuster beobachtet, die sich wiederholen.

Das erste ist der Prototype, der produktiv wurde. Jemand baut schnell ein KI-Feature für einen Client. Die Demo funktioniert, der Client möchte, dass sie live bleibt, und der Prototype geht in Production, ohne jegliches Scaffolding eines produktiven Systems. Keine Ausgabenlimits. Kein Monitoring. Keine Alerting. Nur ein Live-API-Key und Optimismus.

Das zweite ist der Agent, den niemand gezügelt hat. Agentische Workflows sind wirklich nützlich. Sie sind auch wirklich teuer, wenn etwas schiefgeht. Eine Schleife, die zehnmal pro Task ein LLM aufruft, laufend über ein paar hundert Tasks pro Tag, produziert eine Rechnung, die nichts mit der Kostenschätzung aus der Woche zu tun hat, in der der Agent geplant wurde.

Das dritte ist der gemeinsame Key. Ein API-Key, der über mehrere Projekte, mehrere Clients, mehrere Umgebungen hinweg verwendet wird. Wenn die Rechnung ankommt, kann dir niemand sagen, welches Projekt welche Kosten erzeugt hat. Du kannst nicht schneiden, was du nicht sehen kannst.

Die Kontrollen sind nicht exotisch

Keiner der Fixes hier erfordert ein dediziertes Platform-Team oder einen sechsstelligen Observability-Vertrag. Sie erfordern Disziplin und jemanden, dessen Job es ist, sich zu kümmern.

Ausgabenlimits existieren auf jeder großen KI-Plattform. Anthropic, OpenAI und Google bieten alle harte Caps und sanfte Alerts auf Account-Ebene an. Setz sie vor dem Deployment, nicht nach der ersten Rechnung. Wenn dein Billing-Threshold für einen Prototype "no limit" sein muss, ist dieser Prototype nicht bereit zum Deployment.

Getrennte Keys pro Projekt, pro Client, pro Umgebung. Das klingt offensichtlich. Es wird nicht konsistent gemacht. Ein Key pro Deployment bedeutet ein Kostensignal pro Deployment. Das ist die minimale Einheit der Sichtbarkeit, die du brauchst, um überhaupt etwas zu steuern.

Token-Nutzung in dein Scoping einbinden. Wenn du die Kosten eines KI-Features schätzt, arbeite rückwärts von der Token-Anzahl. Wie viele Calls pro User-Session? Wie viele Sessions pro Tag? Was ist die durchschnittliche Prompt-Länge? Was berechnet das Modell pro Million Input- und Output-Tokens? Das sind keine harten Zahlen zu finden. Die Provider veröffentlichen ihre Preise. Die Arbeit ist, die Multiplikation vor dem Ship zu machen, nicht danach.

Logg, was läuft. Wenn du eine Orchestration-Schicht wie LangChain, LlamaIndex oder ein Custom-Setup verwendest, stell sicher, dass Token-Zählungen und Latenz auf Call-Ebene erfasst werden. Aggregiere sie täglich. Ein Cost-Graph, der am Dienstag nach oben springt, sagt dir, dass etwas am Dienstag passiert ist. Ohne den Graph erfährst du es, wenn Anthropic es tut.

Wer trägt dafür Verantwortung

Die ehrliche Antwort ist. Im Moment oft niemand. KI-Deployment hat die organisatorischen Strukturen überholt, die es normalerweise regeln würden. In den meisten Agenturen gibt es keine KI-Ops-Funktion. Es gibt einen Entwickler, der von LLMs begeistert ist, und einen Client, der von den Ergebnissen begeistert ist. So fängt man gut an. So läuft es nicht gut.

Die Rolle, die es formell oder informell geben muss, ist jemand, der zwei Fragen stellt, bevor etwas live geht. Erstens: Wie viel kostet das bei zehnfacher erwarteter Last? Zweitens: Was triggert einen Alert oder einen Hard Stop, wenn diese Last erreicht wird?

Diese zwei Fragen erfordern keine Neueinstellung. Sie erfordern eine Entscheidung darüber, wer verantwortlich ist. In einer kleinen Agentur könnte das der Technical Lead sein. In einer größeren vielleicht ein Delivery Manager oder ein Principal Engineer. Der Titel spielt keine Rolle. Die Verantwortlichkeit spielt eine Rolle.

Es gibt einen breiteren Punkt hier darüber, wie KI-Arbeiten verkauft und geliefert werden. Wenn du ein Festhonorar für ein Projekt mit LLM-Calls quotierst, trägst du das Margin-Risiko jedes Tokens, das läuft. Dieses Risiko muss modelliert, gedeckelt und entweder in das Engagement eingepreist oder mit transparenter Usage-Berichterstattung an den Client durchgereicht werden. Keine der beiden Optionen ist kompliziert. Beide erfordern, dass das Gespräch vor der Unterzeichnung des Vertrags stattfindet.

Die Value-Frage

Ich möchte klarstellen, dass all dies kein Argument gegen schnelle KI-Bewegungen ist. Die Teams, die interessante Arbeit gerade leisten, sind diejenigen, die shipped, gelernt und iteriert haben. Vorsicht um ihrer selbst willen ist einfach nur langsames Scheitern.

Aber Kosten-Disziplin ist nicht Vorsicht. Das ist die Sache, die dir ermöglicht, weiter zu shippen. Ein Team, das sein KI-Budget im ersten Monat in einem unkontrollierten Prototype verbraucht, kann im dritten Monat keine Experimente durchführen. Ein Client, der eine unerwartete Rechnung erhält, kommt nicht für das nächste Engagement zurück.

Die 500-Millionen-Dollar-Geschichte, real oder ausgeschmückt, ist nützlich, weil sie extrem genug ist, um den Punkt deutlich zu machen. Du musst nicht irgendwie in die Nähe dieser Zahl kommen, damit ungoverned KI-Spend echten Schaden an einem Projekt, einer Client-Beziehung oder den Finanzen eines Studios anrichtet.

Die Tools, um es zu verhindern, sind schon in den Dashboards deiner Provider. Die Disziplin, sie zu nutzen, ist eine Entscheidung. Treffe sie vor dem Deployment.