Was KI-Agent-Wartung nach dem Launch wirklich kostet

Einen KI-Agenten zu bauen kostet in der Regel weniger als ihn am Laufen zu halten. Kalkulieren Sie 15 bis 25 Prozent Ihrer ursprünglichen Buildkosten pro Jahr für Wartung ein – und rechnen Sie damit, dass die größten Posten nicht die Dinge sind, die laut abstürzen, sondern die, die still versagen.

Die meisten Gründer planen ein KI-Agenten-Projekt wie ein normales Feature: fester Buildpreis, Lieferdatum, fertig. Dann bricht drei Monate nach dem Launch leise etwas, niemand bemerkt es zwei Wochen lang, und das „abgeschlossene" Projekt braucht plötzlich einen weiteren Sprint. Das ist kein Planungsfehler – es ist ein grundlegender Kategorieunterschied. Traditionelle Software scheitert laut: ein Null-Pointer, ein 500-Fehler, ein fehlgeschlagener Test. KI-Agenten scheitern still, weil das Modell nicht weiß, dass es falsch liegt. Es liefert einfach eine selbstsichere, plausible, falsche Antwort – und macht weiter.

Warum KI-Agenten mehr Wartung kosten als typische Software

Stille Fehler sind die eigentliche Gefahr

Wir betreiben eine eigene Outreach-Engine, die die Website jedes Prospects mit einer selbst gehosteten Firecrawl-Instanz und einem lokalen LLM scrapt, Fakten extrahiert und in einem einzigen Aufruf eine maßgeschneiderte E-Mail pro Unternehmen verfasst. Der Fehler, den wir am häufigsten erlebt haben, war nicht das halluzinierende LLM – er kam von außen: Eine Prospect-Website hatte ihre Startseite neu gestaltet, der Scraper lieferte trotzdem noch einen 200er-Status, und der Agent schrieb weiter E-Mails, die auf eine Leistung verwiesen, die das Unternehmen still und leise Monate zuvor eingestellt hatte. Nichts stürzte ab. Kein Alert. Die Ausgabequalität wurde einfach schlechter.

Das ist das Muster, auf das Sie sich vorbereiten müssen. Die Eingaben Ihres KI-Agenten – gescrapte Seiten, Drittanbieter-APIs, CRM-Datensätze, PDFs – ändern sich, ohne Sie zu informieren. Und der Agent hat keine eingebaute Möglichkeit zu erkennen, dass der Boden unter ihm nachgegeben hat.

Modell- und API-Fluktuation

Der Modellanbieter hinter Ihrem Agenten wird Versionen abkündigen, Rate Limits anpassen oder das Verhalten in Updates ändern, die Sie nicht angefordert haben. Ein Prompt, der sorgfältig auf die Eigenheiten eines bestimmten Modells abgestimmt wurde, kann sich gegen seinen Nachfolger anders verhalten – selbst wenn das Interface identisch aussieht. Wir haben das an unserem eigenen lokalen LLM erlebt: Ein neuerer Patch-Release derselben Modellfamilie produzierte kompaktere, weniger repetitive Zusammenfassungen von gescrapten Seiteninhalten – begann aber gleichzeitig, genau jene spezifischen Leistungsbezeichnungen wegzulassen, von denen unser Personalisierungsschritt abhängt. Deshalb haben wir unsere Extraktions-Prompts gegen eine Reihe vergangener Scrapes neu ausgeführt und die Ergebnisse Zeile für Zeile verglichen, bevor wir der neuen Version in der Produktion vertraut haben. Das ist keine Hypothese, sondern ein planbares Ereignis: Jedes Foundation-Modell hat einen Abkündigungszeitplan, und „einfach den Modell-String tauschen" unterschätzt den Retestaufwand, den verantwortungsvolle Teams tatsächlich betreiben.

Daten- und Workflow-Drift

Geschäftsregeln ändern sich. Preismodelle ändern sich. Der Support-Agent, der auf Ihrer Rückgaberichtlinie trainiert wurde, benötigt ein Update an dem Tag, an dem sich diese Richtlinie ändert – nicht irgendwann, wenn jemand daran denkt, die Entwicklung zu informieren. Klassische Software altert langsam durch Vernachlässigung; Agentenlogik verschlechtert sich in dem Moment, in dem das Unternehmen sich verändert und niemand sie neu synchronisiert.

Was ein realistisches Wartungsbudget tatsächlich abdeckt

• Monitoring und Alerting: Irgendetwas muss erkennen, wenn die Ausgabequalität sinkt – nicht erst, wenn der Prozess abstürzt. Das ist üblicherweise der am stärksten unterschätzte Posten.
• Datenquellen-Health-Checks: Regelmäßige Validierung, dass Scraper, APIs und Integrationen noch das zurückliefern, was Sie erwarten – strukturell, nicht nur irgendetwas.
• Modellversionsverwaltung: Testen gegen neue Modell-Releases, bevor Sie dazu gezwungen werden, und Aufrechterhaltung eines Rollback-Pfads.
• Prompt- und Logik-Updates: Ein etablierter Prozess, um Geschäftsänderungen (Preise, Richtlinien, neue Produkte) in die Anweisungen des Agenten zurückzuspielen.
• Fallback- und Eskalationslogik: Ein definierter Weg für den Fall, dass die Konfidenz niedrig ist – damit der Agent an einen Menschen übergibt, statt zu raten.
• On-Call-Verantwortung: Eine verantwortliche Person, wenn der Agent um 2 Uhr nachts Probleme macht – auch wenn die Lösung bis zum Morgen warten kann.

Nichts davon ist exotisch. Es ist dieselbe Disziplin, die Sie auf jedes Produktionssystem mit externen Abhängigkeiten anwenden würden – nur angewandt auf ein System, dessen Fehlermodus „selbstsicher falsch" lautet statt „ausgefallen."

Eine Faustregel für die Budgetplanung

Für einen mittelkomplexen Agenten (einen WhatsApp-Sales-Assistenten, einen internen Support-Bot, eine Datenanreicherungs-Pipeline) planen Sie 15 bis 25 Prozent der initialen Buildkosten pro Jahr für laufende Wartung ein – aufgeteilt ungefähr zwischen Monitoring/Infrastruktur und Prompt-/Logikpflege. Unsere eigene Outreach-Engine bewegt sich komfortabel in diesem Rahmen: Die wiederkehrenden Kosten bestehen hauptsächlich aus den Stunden, die wir nach einer Website-Neugestaltung für die Überprüfung von Scraper-Ausgaben und nach einem Modellwechsel für die erneute Validierung von Extraktions-Prompts aufwenden – nicht für neue Infrastrukturausgaben. Bei Agenten, die Zahlungen, Gesundheitsdaten oder Compliance-sensible Entscheidungen berühren, sollte das Budget höher angesetzt werden, weil der Preis eines stillen Fehlers nicht „eine ärgerliche E-Mail" ist, sondern ein echtes Haftungsrisiko. Wenn Sie mit einem Anbieter verhandeln, lohnt es sich genau hier, konkrete Zusagen im Vertrag zu verankern, statt sie vorauszusetzen – lesen Sie dazu unsere Analyse, was Sie bei Evals als Bestandteil eines KI-Anbietervertrags einfordern sollten.

Build vs. Buy verändert die Kostenstruktur – nicht ob Kosten entstehen

Die Entscheidung für eine No-Code-Agentenplattform statt eines Custom-Builds beseitigt Wartungsaufwand nicht, sie verlagert ihn. Der Anbieter übernimmt Infrastruktur und Modell-Upgrades, aber Ihre Prompts, Datenanbindungen und Geschäftslogik bleiben Ihre Verantwortung – und zusätzlich sind Sie nun den Preisänderungen und Roadmap-Entscheidungen des Anbieters ausgesetzt. Diesen Trade-off haben wir ausführlicher in Custom AI Agent vs. Chatbot-Plattform aufgeschlüsselt. Rechnen Sie in jedem Fall so, wie Sie jede laufende Infrastrukturausgabe bewerten würden – gemeinsam mit den Modellkosten; unser Leitfaden zur LLM-Kostenoptimierung behandelt die Token-Kosten-Seite dieser Rechnung und ergänzt direkt die hier behandelte Wartungsseite.

Wenn Sie einen KI-Agenten planen und das vorliegende Angebot kein Monitoring, keine Modell-Updates und keine Wartungspauschale erwähnt, fragen Sie warum. Entweder wurde es still eingepreist (selten) – oder es wurde gar nicht eingepreist (häufig, und später teuer).

Überlegen Sie noch, ob ein Agent diesen Pflegeaufwand überhaupt rechtfertigt, oder ob ein einfacherer Workflow ausreicht? Lesenswert als Vorbereitung: KI-Agenten vs. Workflows – bevor Sie sich auf beides festlegen. Wenn Sie eine zweite Meinung dazu wünschen, wie ein realistischer Wartungsplan für Ihren konkreten Anwendungsfall aussehen sollte, sprechen Sie uns an.