KI-Agent Kosten: Was kostet es, einen KI-Agenten zu bauen und zu betreiben?

KI-Agent Kosten bestehen aus zwei Teilen: einmaligen Entwicklungskosten, die von Integrationen, schreibenden Aktionen und Evaluierungsarbeit bestimmt werden, und laufenden Betriebskosten, die von Modellaufrufen pro Aufgabe, menschlicher Prüfzeit und Wartung abhängen. Ein eng gefasster Agent für einen einzigen Workflow ist ein überschaubares Projekt; ein Agent, der in mehrere Geschäftssysteme schreibt, ist eine Plattformentscheidung.

Dieser Leitfaden erklärt die Treiber hinter beiden Zahlen, nennt beispielhafte Spannen mit offengelegten Annahmen und zeigt, wie Sie die Kosten pro Aufgabe messen, bevor Sie sich festlegen. Die Spannen sind Planungshilfen, keine Angebote. Ihr Workflow, Ihre Daten und Ihre Toleranz für Fehler verschieben sie stärker als jede Preisliste eines Anbieters.

Warum sich die Kosten eines KI-Agenten schwer schätzen lassen

Ein Chatbot antwortet einmal. Ein Agent plant, ruft ein Werkzeug auf, liest das Ergebnis und entscheidet, ob er weitermacht. Die Zahl der Modellaufrufe pro Aufgabe ist nicht fest, sie hängt von der Eingabe ab. Zwei Support-Tickets, die sich ähneln, können einen Durchlauf mit drei Schritten und einen mit zwölf Schritten auslösen, und der zweite kostet in der Verarbeitung ein Mehrfaches.

Die Entwicklungskosten sind aus einem anderen Grund schwer festzulegen. Die Demo ist der günstige Teil. Ein Prototyp, der ein Modell und eine API aufruft, lässt sich in wenigen Tagen zusammenstellen. Die teure Arbeit liegt an den Rändern: Systeme ohne Testumgebung, Datensätze, die sich widersprechen, Freigabeoberflächen, eng gefasste Berechtigungen, Evaluierung, Monitoring und der Wiederherstellungsweg, wenn ein Schreibvorgang nur halb gelingt. Nichts davon taucht in einer Demo auf, und all das entscheidet darüber, ob der Agent eingeschaltet bleiben kann.

Typische Fehler von Teams

Der häufigste Fehler ist, das Modell statt des Workflows zu bepreisen. Tokens sind der sichtbarste Posten, deshalb orientieren sich Budgets an ihnen. In vielen Workflows sind sie aber nicht der größte Kostenblock. Die Zeit, die eine Person mit der Prüfung von Entwürfen verbringt, die Engineering-Stunden für Integrationen und der monatliche Pflegeaufwand, wenn eine Modellversion abgekündigt wird, wiegen meist schwerer.

Weitere wiederkehrende Fehler:

• Den Prototyp für den Großteil der Entwicklung halten und dann feststellen, dass die Arbeit für den Produktivbetrieb der größere Anteil ist.
• Die Prüfzeit weglassen, obwohl jeder Freigabeschritt Modellausgaben in bezahlte menschliche Minuten verwandelt.
• Die Wartung vergessen. Modelle werden abgekündigt, Anbieter-APIs wechseln die Version, und jede Prompt-Änderung braucht einen Regressionstest.
• Ohne Obergrenze arbeiten. Ein Agent ohne Schrittlimit oder Budget pro Durchlauf kann an einem fehlschlagenden Werkzeug hängen bleiben und so lange Geld ausgeben, bis es jemand bemerkt.
• Angebote nur nach Tagessatz vergleichen, obwohl der eigentliche Unterschied darin liegt, ob Evaluierung, Monitoring und Übergabe enthalten sind.

Ein praktischer Weg, die Entwicklung zu schätzen

Schätzen Sie die Entwicklung vom Workflow aus. Schreiben Sie auf, aus welchen Systemen der Agent liest, in welche er schreibt, welche Entscheidungen er trifft und was der schlimmste realistische Fehler wäre. Diese Liste, nicht die Wahl des Modells, ist das, was ein Entwickler bepreisen kann.

Die Kostentreiber der Entwicklung

• Berührte Systeme: Jede Integration braucht Authentifizierung, Fehlerbehandlung und Tests. Ein System ohne API oder ohne Sandbox verursacht Mehraufwand oder erzwingt einen ausdrücklichen manuellen Schritt.
• Lesen oder Schreiben: Einen reinen Lese-Assistenten abzusichern ist weit günstiger als einen Agenten, der Datensätze ändert, Nachrichten verschickt oder Geld bewegt.
• Freigabe-Erlebnis: Eine prüfende Person muss die vorgeschlagene Änderung, die Belege dafür und eine Möglichkeit zur Bearbeitung vor der Freigabe sehen.
• Datenaufbereitung: Retrieval über unordentliche Dokumente erzeugt selbstbewusst falsche Antworten. Den Ausschnitt der Daten zu bereinigen, von dem ein Workflow abhängt, ist oft nötig.
• Evaluierungsdatensatz: echte historische Fälle mit bekanntem richtigem Ergebnis plus gezielt schwierige Eingaben, damit sich die Qualität vor dem Launch und nach jeder Änderung messen lässt.
• Beobachtbarkeit und Limits: Logs pro Durchlauf, Kostenerfassung, Alarme und Obergrenzen.
• Ausführungsmodell: Ein kurzer Agent nach dem Anfrage-Antwort-Muster kann innerhalb eines Web-Requests laufen; lange Durchläufe brauchen eine Warteschlange, einen Worker und Checkpoints.

Beispielhafte Spannen für die Entwicklung

Die folgenden Spannen setzen ein kleines, erfahrenes Team voraus, bestehende Systeme mit nutzbaren APIs, eine Produktivumgebung und einen Auftraggeber, der echte historische Beispiele für die Evaluierung liefern kann. Nicht enthalten sind Softwarelizenzen, eine breite Datenbereinigung über den Ausschnitt des Workflows hinaus und Compliance-Arbeit, die eine rechtliche Prüfung erfordert. Es sind Größenordnungen für ein Budgetgespräch, keine Preise.

• Reiner Lese-Assistent über Ihre eigenen Dokumente oder ein System, mit Quellenangaben und Evaluierungsdatensatz: grob 8.000 bis 25.000 US-Dollar.
• Agent für einen einzelnen Workflow, der Aktionen als Entwurf in einem System vorbereitet, mit Freigabeschritt, Audit-Log und Monitoring: grob 20.000 bis 60.000 US-Dollar.
• Agent über mehrere Systeme mit mehreren schreibenden Integrationen, dauerhafter Ausführung, Berechtigungen pro Werkzeug und einer gemeinsamen Werkzeugschicht: oft 60.000 bis 150.000 US-Dollar oder mehr, meist in Etappen geliefert.

Wenn Sie in Euro budgetieren, rechnen Sie mit dem aktuellen Wechselkurs um und behandeln Sie das Ergebnis ebenso nur als Orientierung, nicht als Angebot.

Ein Festpreis setzt einen abgegrenzten Workflow, Beispieldaten und eine schriftliche Definition eines richtigen Ergebnisses voraus. Ohne diese ist jede Zahl eine Vermutung, die als Preis verkleidet ist.

So schätzen Sie die Betriebskosten pro Aufgabe

Betriebskosten lassen sich am besten pro Aufgabe betrachten und dann mit dem Volumen multiplizieren. Nutzen Sie ein einfaches Modell: Kosten pro Aufgabe gleich Modellkosten plus Werkzeug- und API-Gebühren plus Infrastruktur plus menschliche Prüfzeit plus ein Anteil an der monatlichen Wartung.

Hier ein durchgerechnetes Beispiel mit Platzhalterpreisen; prüfen Sie die aktuelle Preisliste Ihres Anbieters, bevor Sie echte Zahlen verwenden. Angenommen, ein Modell kostet 1 US-Dollar pro Million Eingabe-Tokens und 5 US-Dollar pro Million Ausgabe-Tokens. Eine typische Aufgabe umfasst acht Modellaufrufe, die jeweils etwa 6.000 Eingabe-Tokens senden und etwa 500 Ausgabe-Tokens erhalten. Das sind 48.000 Eingabe-Tokens, also etwa 0,048 US-Dollar, und 4.000 Ausgabe-Tokens, also 0,02 US-Dollar, zusammen rund 0,07 US-Dollar pro Aufgabe. Bei 20.000 Aufgaben im Monat liegen die Modellkosten bei rund 1.360 US-Dollar.

Nun kommt die Prüfung hinzu. Wenn eine Person zwei Minuten braucht, um einen Entwurf freizugeben, ergeben 20.000 Aufgaben etwa 667 Stunden Prüfzeit im Monat. In diesem Beispiel ist die Zeit der prüfenden Person ein weit größerer Posten als die Tokens. Deshalb ist die Gestaltung der Freigabe, die wir im Beitrag zu Human-in-the-Loop-Agenten behandeln, ebenso eine Kostenentscheidung wie eine Sicherheitsentscheidung.

Wartungs- und Änderungskosten

Planen Sie wiederkehrende Arbeit ein, auch wenn nichts kaputt ist. Modellversionen werden abgekündigt, und ihre Nachfolger verhalten sich anders. Angebundene Systeme ändern ihre APIs. Im echten Betrieb tauchen neue Randfälle auf und werden zu neuen Evaluierungsfällen. Jede Änderung an Prompt oder Modell braucht vor dem Release einen Regressionstest. Teams decken das meist mit einer monatlichen Support-Vereinbarung oder einem festgelegten Anteil der Zeit eines internen Engineers ab.

Technische Entscheidungen, die die Rechnung verändern

Mehrere Engineering-Entscheidungen wirken sich direkt auf die Betriebskosten aus:

• Schrittlimits: Begrenzen Sie die Zahl der Denkschritte pro Durchlauf, damit ein verwirrter Agent anhält, statt in einer Schleife zu laufen.
• Budgets pro Durchlauf: Stoppen oder eskalieren Sie, wenn der Token-Verbrauch für eine Aufgabe einen Schwellenwert überschreitet.
• Ausgaben formen: Kürzen Sie große Werkzeugergebnisse oder fassen Sie sie zusammen, bevor sie zurück in den Kontext des Modells gehen.
• Modell-Routing: Nutzen Sie ein kleineres Modell für Klassifizierung und Extraktion und reservieren Sie das größere Modell für Planung oder Entwürfe.
• Begrenzte Wiederholungen: Wiederholen Sie nur bei Fehlern, die beim erneuten Versuch gelingen können, und mit Backoff. Jede Wiederholung ist ein weiterer bezahlter Aufruf.
• Nutzungsprotokoll: Erfassen Sie den Token-Verbrauch pro Schritt, damit die Kosten pro Aufgabe aus Daten stammen und nicht aus Schätzungen.
• Caching: Verwenden Sie abgerufenen Kontext und stabile Systemanweisungen wieder, wo der Anbieter das unterstützt.

Abwägungen

Ein günstigeres Modell kann die Gesamtkosten erhöhen, wenn es mehr Schritte, mehr Wiederholungen oder mehr menschliche Korrektur braucht. Messen Sie die ganze Aufgabe, nicht den Preis pro Token.

Freigabeschritte kosten Prüfzeit, senken aber die erwarteten Kosten eines Vorfalls. Behalten Sie sie dort, wo ein Fehler teuer ist, und entfernen Sie sie dort, wo Belege zeigen, dass der Agent zuverlässig arbeitet.

Dauerhafte Ausführung, ein Protokoll der Werkzeugaufrufe und Evaluierung von Anfang an einzubauen, verteuert die anfängliche Entwicklung. Sie nachzurüsten, wenn ein Agent bereits produktiv läuft, kostet meist mehr, weil sich die Abkürzungen des Prototyps durch den Code gezogen haben. Der gestufte Ansatz aus unserem Beitrag zur Migration bestehender Systeme auf Agenten hält die erste Etappe klein und bewahrt trotzdem diese Struktur.

Erfahrungen aus der Arbeit von ImadDhin

Die folgenden Beobachtungen stammen aus dem Code des Agent-Arbeitsbereichs in diesem Portal. Es sind Notizen auf Implementierungs- und Code-Ebene, keine Kundenergebnisse und keine Kostenzahlen aus dem Produktivbetrieb.

• Kostenrisiko ist eine Produktentscheidung. Der kostenlose Chat ist serverseitig pro Besucher begrenzt, und Recherchewerkzeuge, die eine kostenpflichtige externe API aufrufen, antworten mit einer Zahlungsaufforderung, solange der Besucher nicht die Premium-Stufe hat. Die teuren Funktionen werden abgesichert, bevor sie aufgerufen werden, nicht erst, wenn die Rechnung kommt.
• Zähler brauchen die richtige Konsistenz. Ein Nutzungslimit ist nur so stark wie die Art, wie sein Zähler aktualisiert wird. Ein Zähler nach dem Muster Lesen-dann-Schreiben lässt gleichzeitige Anfragen am Limit vorbeirutschen, ein häufiger Befund bei der Prüfung KI-gebauter Produkte. Für ein kleines kostenloses Kontingent mag das vertretbar sein; alles, was mit Abrechnung oder Guthaben verbunden ist, sollte ein atomares Inkrement oder eine Transaktion nutzen.
• Durchläufe sind an mehreren Stellen begrenzt. Die Workflow-Laufzeit begrenzt einen Durchlauf auf eine feste Zahl von Graph-Schritten, lehnt gespeicherte Checkpoints oberhalb eines Größenbudgets ab und kürzt Werkzeugausgaben, bevor sie an das Modell zurückgehen. Jedes Limit stoppt eine andere Art des Ausuferns.
• Die Nutzung wird pro Schritt erfasst. Jeder Denkschritt schreibt die Nutzungsmetadaten des Modells in das Ereignisprotokoll des Durchlaufs. Dadurch werden die Kosten pro Aufgabe zu etwas, das sich aus Datensätzen berechnen lässt.
• Wiederholungen sind Ausgaben. Der Recherche-Wrapper unternimmt höchstens drei Versuche, beachtet bei Ratenlimits den Retry-After-Header des Anbieters, wartet bei Timeouts und Serverfehlern mit Backoff und wiederholt niemals Anfragen, die an fehlerhaften Eingaben oder an der Authentifizierung scheitern.

Häufige Fehler, auf die Sie testen sollten

Testen Sie vor dem Launch das Kostenverhalten so gezielt wie die Antworten:

• Senden Sie eine ungewöhnlich lange oder bewusst manipulative Eingabe und prüfen Sie, dass der Token-Verbrauch pro Durchlauf unter der Obergrenze bleibt.
• Lassen Sie ein Werkzeug wiederholt fehlschlagen und prüfen Sie, dass der Agent anhält oder eskaliert, statt in einer Schleife zu laufen.
• Schicken Sie gleichzeitige Anfragen gegen jedes Nutzungslimit und prüfen Sie, dass es dort hält, wo es halten muss.
• Simulieren Sie einen Ausfall des Anbieters und prüfen Sie, was der Ausweichpfad kostet und wie er sich verhält.
• Brechen Sie einen Durchlauf mittendrin ab und prüfen Sie, dass keine weiteren Kosten entstehen.
• Stellen Sie sicher, dass Sie die Kosten pro Aufgabe für jeden Workflow ausweisen können, nicht nur die monatliche Rechnungssumme.

Wann eine einfachere Lösung besser ist

Wenn eine Aufgabe immer denselben Schritten folgt, ist ein deterministischer Workflow mit einem einzigen Modellaufruf für Klassifizierung oder Entwurf günstiger in Entwicklung und Betrieb und leichter zu testen als ein Agent. Bei geringem Volumen ist eine Person mit einer guten Vorlage womöglich die günstigste Option überhaupt.

Ein Agent verdient seine Kosten, wenn die Eingaben so stark variieren, dass der Weg von Fall zu Fall entschieden werden muss, und wenn das Volumen hoch genug ist, damit sich die Entwicklung amortisiert. Wenn Sie unsicher sind, auf welcher Seite dieser Linie ein Workflow liegt, ist der AI Readiness Scan ein günstiger Weg, das vor einer Entwicklungsentscheidung herauszufinden.

Ein Kostenmodell für Ihren eigenen Workflow

Eine brauchbare Schätzung beginnt beim Workflow, bei den Systemen, die er berührt, und beim schlimmsten realistischen Fehler, und trennt dann die Entwicklungskosten von den Kosten pro Aufgabe. Wenn Sie dieses Modell für Ihren tatsächlichen Prozess aufbauen möchten, sehen Sie sich unsere Entwicklung von KI-Agenten an, oder bringen Sie den Workflow und seine aktuellen Volumina in ein 30-minütiges Gespräch mit.