# KI-Agenten Wartung: Modellwechsel, Regressionen und was ein Wartungsvertrag abdecken muss > Warum ein KI-Agent Wartung braucht, auch wenn niemand den Code anfasst: Modellabkündigungen, Vorsysteme, die Formate ändern, veraltete Wissensquellen, neue Angriffsmuster. Wie Regressionen erkannt werden, wie eine Modellmigration abläuft und welche zehn Punkte in einem Wartungsvertrag stehen müssen. URL: https://www.twigbit.ai/de/blog/ki-agenten-wartung Published: 2026-09-10T00:00:00.000Z Author: Moritz Morgenroth (Co-Founder & Geschäftsführer) Tags: KI-Agenten, Wartung, Evals --- Klassische Software verändert sich nur, wenn jemand sie ändert. Ein KI-Agent verändert sich, wenn sich irgendetwas um ihn herum ändert, und das passiert ständig: Der Modellanbieter kündigt die Version ab, auf der der Agent gebaut wurde. Das ERP bekommt ein Update und benennt ein Feld um. Die Kollegin aus dem Vertrieb aktualisiert die Preisliste, die der Agent als Kontext lädt. Ein Angreifer findet eine neue Formulierung, die den Agenten dazu bringt, seine Anweisungen zu vergessen. Nichts davon ist ein Fehler im Agenten, und alles davon ist ein Wartungsfall. Dieser Leitfaden ist der zweite Teil nach [KI-Agenten betreiben](/blog/ki-agenten-betreiben). Dort geht es um den laufenden Betrieb: Freigaben, Protokolle, Reviews. Hier geht es um die Arbeit, die den Agenten über Monate und Jahre funktionsfähig hält, und um den Vertrag, der sie regelt. Wer einen Agenten erst noch entwickeln lassen will, beginnt unter [KI-Agenten entwickeln lassen](/ki-agenten). ## Warum ein Agent Wartung braucht, auch wenn niemand ihn anfasst Vier Quellen von Veränderung wirken auf jeden Agenten im Betrieb, und keine davon liegt in eurer Hand. **Modelle werden abgekündigt und verändert.** Modellanbieter führen neue Versionen ein und nehmen alte nach einer Frist vom Netz; die [Abkündigungsliste von OpenAI](https://platform.openai.com/docs/deprecations) ist ein Beispiel dafür, wie regelmäßig das passiert. Jede Abkündigung ist eine erzwungene Migration, und ein neues Modell verhält sich nie exakt wie das alte. Es formuliert anders, hält Formatvorgaben anders ein, urteilt in Grenzfällen anders. Ein Agent, der auf einer abgekündigten Version steht, hat ein Ablaufdatum. **Vorsysteme ändern Formate.** Der Agent liest aus CRM, ERP, Ticketsystem und Postfach. Ein Update benennt ein Feld um, ein Lieferant ändert das Layout seiner Auftragsbestätigung, eine API liefert ein neues Pflichtfeld. Der Agent bekommt keinen Fehler, er bekommt andere Daten, und er verarbeitet sie mit demselben Selbstbewusstsein wie zuvor. **Wissensquellen veralten.** Ein Agent, der aus Dokumenten antwortet, ist so aktuell wie diese Dokumente. Eine Preisliste vom letzten Quartal, eine Produktbeschreibung mit dem alten Funktionsumfang, eine Vorlage mit der Unterschrift einer Person, die das Unternehmen verlassen hat: Der Agent findet das alles und benutzt es. Wie das Retrieval technisch funktioniert, steht unter [Retrieval-Augmented Generation](/glossary/retrieval-augmented-generation); dass es Pflege braucht, steht in keinem Handbuch und in jedem Vorfallbericht. **Angriffsmuster ändern sich.** Prompt Injection, also Anweisungen in Fremdtext, die der Agent als seine eigenen liest, ist die meistgenannte Schwachstelle in der [OWASP Top 10 für LLM-Anwendungen](https://owasp.org/www-project-top-10-for-large-language-model-applications/). Die Muster entwickeln sich weiter, und was der Agent beim Go-live abgewehrt hat, sagt wenig über das nächste Jahr. ## Die vier Arten von Wartung Die Softwaretechnik unterscheidet seit Jahrzehnten vier Kategorien von Wartung, und alle vier gelten für Agenten, mit jeweils eigenem Gesicht. - **Korrektiv:** Ein Fehler wird behoben, den der Agent im Betrieb gezeigt hat. Bei Agenten heißt das fast immer: ein neuer Fall in der Eval-Suite, eine Anpassung an Prompt, Kontext oder Regeln, ein Lauf der Suite, ein Rollout. - **Adaptiv:** Die Umgebung hat sich geändert, der Agent folgt. Modellwechsel, ein umbenanntes Feld im ERP, eine neue API-Version, eine neue Anforderung aus dem Datenschutz. - **Perfektiv:** Der Agent wird besser oder günstiger, ohne dass etwas kaputt war. Ein kleineres Modell für die Klassifikation, ein präziserer Kontext, ein Aktionstyp, der nach ausreichenden Fehlerraten autonom wird. - **Präventiv:** Arbeit gegen künftige Ausfälle. Abkündigungslisten prüfen, Rechte auditieren, die Eval-Suite um die Korrekturen des Monats erweitern, Wissensquellen auf Aktualität prüfen. Ein Wartungsvertrag, der nur die erste Kategorie abdeckt, deckt den kleinsten Teil der Arbeit ab. Die meiste Zeit geht in adaptiv und präventiv, also in Veränderungen, die kein Fehler ausgelöst hat. ## Regressionen erkennen: die Eval-Suite als Regressionstest Eine Regression ist ein Fall, den der Agent konnte und plötzlich nicht mehr kann. Bei deterministischer Software fällt sie im Test auf. Bei einem Agenten fällt sie nur auf, wenn es einen Test gibt, der den Fall enthält, und das ist die Eval-Suite: einige hundert historische Vorgänge mit bekannt korrektem Ergebnis, sortiert nach Fehlerklassen, mit Schwellenwerten pro Klasse. Drei Regeln machen aus der Suite einen Regressionstest. Sie läuft bei jeder Änderung, an Prompt, Modell, Kontext, Regeln oder Vorsystem, und eine Änderung geht erst live, wenn sie besteht. Sie wächst mit den Korrekturen aus dem Betrieb: Jeder Fall, den ein Mensch im Freigabemodus korrigiert hat, ist ein Kandidat, und die Fälle des Monats werden im Review übernommen. Und sie misst pro Fehlerklasse, nicht nur im Durchschnitt. Ein Modell, das insgesamt besser abschneidet, aber bei Reklamationen mit Fristsetzung schlechter wird, ist für einen Support-Agenten eine Regression, auch wenn die Gesamtzahl steigt. Für Aufgaben, deren Ergebnis sich nicht mechanisch prüfen lässt, etwa den Ton einer Antwort, kommt ein zweites Modell als Bewerter zum Einsatz. Es ist nur so gut wie seine Kalibrierung: Seine Urteile werden regelmäßig gegen menschliche Urteile abgeglichen, und wo sie auseinanderlaufen, wird der Bewerter angepasst, nicht der Mensch überstimmt. Die Engineering-Disziplin dahinter steht in [KI, die in der Produktion überlebt](/blog/shipping-ai-that-survives-production). ## Eine Modellmigration in fünf Schritten Der Modellwechsel ist der häufigste und der gefährlichste Wartungsfall, weil er alles auf einmal ändert. So läuft er bei uns: 1. **Kandidat gegen die Eval-Suite.** Das neue Modell läuft über die gesamte Suite, mit unverändertem Prompt. Das Ergebnis pro Fehlerklasse zeigt, wo es besser und wo es schlechter ist als das alte. 2. **Prompt und Kontext anpassen.** Neue Modelle halten Formatvorgaben anders ein und brauchen häufig andere Anweisungen für dieselben Grenzfälle. Angepasst wird, bis die Suite in jeder Klasse mindestens das alte Niveau erreicht. 3. **Kosten und Latenz messen.** Ein Modell, das besser antwortet, aber doppelt so lange braucht oder das Monatsbudget sprengt, ist kein Kandidat für die Klassifikation und vielleicht einer für die Antwortentwürfe. 4. **Schattenbetrieb.** Das neue Modell läuft einige Tage parallel auf echten Vorgängen, ohne dass seine Ergebnisse verwendet werden. Die Abweichungen zum alten Modell werden gesichtet. 5. **Rollout mit Rollback.** Umschalten, mit der alten Kombination aus Modell, Prompt und Konfiguration eine Konfigurationsänderung entfernt. In der ersten Woche nach dem Wechsel geht die Stichprobe zur menschlichen Kontrolle nach oben. Wer diese fünf Schritte einmal von Hand gemacht hat, versteht, warum die Eval-Suite das wertvollste Artefakt des ganzen Systems ist. Ohne sie ist ein Modellwechsel ein Blindflug, mit ihr eine Routine von ein bis zwei Tagen. ## Kontext pflegen Der Kontext eines Agenten, also die Dokumente, Datensätze, Vorlagen und Regeln, die er lädt, ist Teil der Software und wird wie Software versioniert. Jede Änderung an einer Preisliste, einer Vorlage oder einer Wissensbasis, die der Agent nutzt, ist eine Änderung am Agenten, und sie löst denselben Eval-Lauf aus wie eine Änderung am Prompt. Praktisch heißt das: Der Agent liest Kontext aus einem Repository oder einer Quelle mit Versionsstand, nicht aus dem Laufwerk, auf dem jeder alles ändern kann. Quellen bekommen ein Ablaufdatum, nach dem sie im Review auftauchen. Und die Frage „Welche Version der Preisliste hat der Agent gestern benutzt?“ ist in einer Minute beantwortet, weil sie im Protokoll jedes Laufs steht. ## Sicherheits-Wartung Drei Routinen gehören in jeden Wartungsplan. Die Eval-Suite enthält eine eigene Klasse mit Prompt-Injection-Fällen, also präparierten E-Mails und Dokumenten, auf die der Agent nicht reagieren darf, und diese Klasse wächst mit den bekannten Mustern. Die Rechte des Agenten werden quartalsweise geprüft: Braucht er noch jeden Zugriff, den er hat, und hat sich sein Nutzer im Identitätssystem Rechte angesammelt, die niemand vergeben wollte? Und die Liste der Subprozessoren, also der Modellanbieter und Dienste, über die Daten laufen, wird bei jeder Änderung aktualisiert und der Datenschutzbeauftragten mitgeteilt, wie es Art. 28 DSGVO verlangt. ## Was ein Wartungsvertrag enthalten muss Ein Wartungsvertrag für einen KI-Agenten ist ein Softwarewartungsvertrag mit vier Ergänzungen: Evals, Modelle, Kontext und die Rollenaufteilung nach [EU AI Act](/glossary/eu-ai-act). Die zehn Punkte, die drinstehen müssen: 1. **Leistungsumfang** nach den vier Wartungsarten, ausdrücklich einschließlich adaptiver und präventiver Wartung. 2. **Eval-Pflicht:** Keine Änderung an Prompt, Modell, Kontext oder Regeln geht live, ohne dass die Eval-Suite bestanden ist, und die Suite wird monatlich um die Korrekturen aus dem Betrieb erweitert. 3. **Modellmigrationen** sind enthalten, inklusive Schattenbetrieb und Rollback, unabhängig davon, ob der Anbieter sie erzwingt oder der Betreiber sie wünscht. 4. **Monitoring und Alarme** mit definierten Schwellen für Fehlerraten, Kosten und Ausfälle. 5. **Reaktionszeiten** pro Schweregrad, mit benannten Personen auf beiden Seiten. Ein Agent, der falsche Zusagen an Kunden verschickt, ist ein anderer Fall als ein Agent, der eine Stunde lang nicht klassifiziert. 6. **Kostenbericht** monatlich, mit Tokens und Aufrufen pro Agent, neben der vereinbarten Kennzahl. 7. **Änderungsbudget:** Ein festes Kontingent für perfektive Änderungen pro Monat, damit „kleine Verbesserungen“ nicht in Einzelangeboten enden. 8. **Rollenaufteilung:** Der Betreiber hält Identität, Berechtigungen, Daten und Freigaben; der Lieferant verantwortet Code, Evals, Migrationen und Regressionen. Die Einstufung nach AI Act ist Anlage. 9. **Dokumentation:** Datenflüsse, Subprozessoren mit Region, Rechte des Agenten, Eval-Berichte, alles auf dem aktuellen Stand und für den Betreiber lesbar. 10. **Exit und Handover:** Code, Prompts, Evals, Kontext und Dokumentation liegen im Repository des Betreibers; bei Kündigung gibt es einen Übergabetermin mit definierten Inhalten, kein Migrationsprojekt. Wer diese zehn Punkte in einem Angebot vermisst, hat kein Wartungsangebot, sondern eine Hotline. ## Was Wartung kostet Bei twigbit beginnt Betrieb und Wartung eines Agenten bei 2.400 € pro Monat. Darin stecken die vier Wartungsarten, die Eval-Pflicht, Modellmigrationen, Monitoring, der Kostenbericht und das monatliche Review. Was den Preis nach oben bewegt, sind die Zahl der Integrationen, das Volumen und der Kontrollbedarf, also wie viele Aktionstypen freigabepflichtig bleiben und wie groß die Stichprobe ist. Die Alternative, den Betrieb selbst zu übernehmen, kostet ein bis zwei Engineering-Tage im Monat und mehr in Monaten mit Modellwechsel; sie ist im Vertrag als Handover vorgesehen, falls ihr sie später wählt. ## Checkliste für den Einkauf - Enthält das Angebot adaptive und präventive Wartung, oder nur Fehlerbehebung? - Gibt es eine Eval-Suite, wem gehört sie, und läuft sie vor jeder Änderung? - Sind Modellmigrationen enthalten, mit Schattenbetrieb und Rollback? - Wer hält Identität, Rechte, Daten und Freigaben? Steht die Einstufung nach AI Act als Anlage im Vertrag? - Gibt es Reaktionszeiten pro Schweregrad mit benannten Personen? - Kommt monatlich ein Kostenbericht neben der Kennzahl? - Liegt der Code im eigenen Repository, und ist der Exit als Übergabetermin geregelt? - Wie wird die Liste der Subprozessoren gepflegt und mitgeteilt? - Wird die Eval-Suite um die Korrekturen aus dem Betrieb erweitert, und wer entscheidet das? - Gibt es ein Änderungsbudget, oder wird jede Verbesserung einzeln angeboten?