Warum KI-Ergebnisse unbemerkt schlechter werden – und was hilft

Ihre KI ist keine normale Software

Wenn ein Buchhaltungsprogramm zweimal dieselbe Rechnung verarbeitet, kommt zweimal dasselbe heraus. Diese Selbstverständlichkeit — gleiche Eingabe, gleiches Ergebnis — ist die Grundlage, auf der wir Software vertrauen, testen und abnehmen. Genau diese Selbstverständlichkeit gilt für KI-Agenten nicht.

Ein KI-Agent auf Basis eines großen Sprachmodells (LLM) ist ein statistisches System. Es erzeugt Antworten, indem es Schritt für Schritt das jeweils wahrscheinlichste nächste Element wählt — und dieser Prozess ist an mehreren Stellen wandelbar. Das Problem für den Betrieb ist nicht, dass die KI Fehler macht. Das Problem ist, dass sich ihr Verhalten verändert, ohne dass jemand etwas tut — und dass diese Veränderung unsichtbar bleibt, bis sie beim Kunden ankommt.

Drei Begriffe sollten wir dabei auseinanderhalten, auch wenn sie im Alltag oft in einen Topf geworfen werden:

• Nicht-Determinismus ist die Streuung zwischen identischen Läufen: gleiche Konfiguration, gleiche Eingabe, trotzdem eine andere Ausgabe.
• Konfigurationsänderung ist ein bewusster oder unbemerkter Eingriff ins System: ein Modellwechsel, eine Prompt-Änderung, ein neues Werkzeug.
• Drift ist die Verschiebung des Verhaltens über die Zeit — etwa weil der Anbieter das Modell aktualisiert oder sich die Eingabedaten verändern.

Für Entscheider fassen wir diese Effekte unter dem Stichwort stille Verhaltensänderung zusammen. Sie haben aber unterschiedliche Ursachen — und verlangen unterschiedliche Gegenmaßnahmen. Drei davon stehen im Zentrum dieses Whitepapers (Abbildung 1): Zwei liegen außerhalb Ihrer Kontrolle, eine im eigenen Haus.

Dieses Whitepaper zeigt anhand belastbarer Studien, wie real und wie groß diese Effekte sind, warum sie ohne systematisches Testen unbemerkt bleiben — und mit welchen fünf konkreten Bausteinen Sie sie in den Griff bekommen. Es geht nicht um Panik, sondern um Betriebssicherheit.

Nicht-Determinismus: gleiche Frage, andere Antwort

Der überraschendste Befund zuerst: Ein Sprachmodell liefert selbst dann unterschiedliche Antworten, wenn man den Zufall ausschaltet. Technisch stellt man den „Zufall“ über den Parameter temperature ein; bei temperature = 0 soll das Modell immer die wahrscheinlichste Antwort wählen — theoretisch reproduzierbar. In der Praxis ist es das nicht. In einem dokumentierten Experiment ließ das Thinking Machines Lab ein großes Modell (Qwen3-235B) denselben Prompt 1.000-mal bei temperature = 0 vervollständigen, mit je rund 1.000 Token — und erhielt 80 verschiedene Antworten. Es ist ein kontrolliertes Einzelexperiment mit einer einzigen Frage: Es belegt das Phänomen eindrücklich, ist aber keine allgemeine Fehlerquote des Produktivbetriebs.

Die Ursache liegt tief in der Technik (Abbildung 2): Rechenzentren verarbeiten viele Anfragen gleichzeitig in wechselnd großen „Stapeln“ (Batches). Die interne Rechenreihenfolge hängt von der Stapelgröße ab, die mit der Serverauslastung schwankt. Weil Gleitkomma-Arithmetik nicht assoziativ ist — die Reihenfolge der Summanden verändert das letzte Bit —, führt eine andere Auslastung zu einer minimal anderen Rechnung und am Ende zu einem anderen Token, also zu einer anderen Antwort.^[2] Technisch ist dieser Effekt beherrschbar: Dieselbe Quelle zeigt, dass sich mit einer angepassten, auslastungsunabhängigen Rechenführung nahezu reproduzierbare Ausgaben erzielen lassen. Dieser Hebel liegt allerdings beim Betreiber der Infrastruktur, nicht bei Ihnen als Anwender.^[2] Eine begleitende Untersuchung beziffert die Streuung: Unter 16-Bit-Genauigkeit (BF16) schwankt die Trefferquote eines Reasoning-Modells (DeepSeek-R1-Distill-Qwen-7B) allein durch Batchgröße, GPU-Typ und GPU-Anzahl um bis zu rund 9 Prozentpunkte; dieselben Konfigurationsunterschiede verändern die Antwortlänge um bis zu 9.000 Token, was unmittelbar auf Kosten und Antwortzeiten durchschlägt. Unter höherer Präzision (FP32) verschwindet die Streuung nahezu.^[3] Beides sind Werte aus einem kontrollierten Benchmark-Aufbau mit begrenzter Aufgabenzahl, nicht die zu erwartende Tagesschwankung Ihres Agenten.

Der Hebel an der Rechenführung liegt beim Anbieter. Ohnmächtig sind Sie deshalb nicht: Der wirksamste Anwenderhebel ist, den Ausgaberaum eng zu halten. Die Streuung wächst mit der Länge und Freiheit der Antwort. Dieselbe Untersuchung, die bei Codegenerierung Spannen von 11 bis über 27 Prozentpunkten misst, findet bei Aufgaben mit festem Antwortraum höchstens 0,7 Punkte.^[4] Praktisch heißt das: Wo eine Entscheidung gefragt ist, lassen Sie das Modell klassifizieren statt frei formulieren; wo Daten gebraucht werden, fordern Sie ein festes Ausgabeformat (etwa ein JSON-Schema) statt Fließtext; und Sie begrenzen die Antwortlänge, statt sie laufen zu lassen. Zusätzlich bieten manche Anbieter einen seed-Parameter samt Kennung der bedienenden Konfiguration an, mit dem Läufe reproduzierbarer werden. Das ist ausdrücklich eine Bemühungszusage und keine Garantie, hilft aber beim Nachstellen von Fehlern. An besonders folgenreichen Stellen schließlich lohnt es, dieselbe Anfrage mehrfach zu stellen und nur ein übereinstimmendes Ergebnis zu verwenden. Weichen die Läufe voneinander ab, ist genau das das Signal, einen Menschen einzuschalten.

Modell-Updates: wenn der Anbieter still austauscht

Die zweite Ursache ist die gefährlichste, weil sie außerhalb Ihres Hauses liegt. Nutzen Sie in Ihrer Anwendung einen allgemeinen Modellnamen (einen Alias wie gpt-4o), kann der Anbieter dahinter jederzeit eine neue Version einhängen — ohne dass sich an Ihrem Code eine Zeile ändert. OpenAI benennt das Gegenmittel selbst: „Snapshots let you lock in a specific version of the model so that performance and behavior remain consistent.“^[5] Das ist zugleich die gute Nachricht: Von den drei Ursachen ist diese die einzige, die Sie mit einer einzigen Konfigurationszeile vollständig aus dem Weg räumen können.

Dass solche Updates das Verhalten spürbar verändern, ist dokumentiert. Forscher aus Stanford und Berkeley verglichen zwei GPT-4-Versionen im Abstand von nur drei Monaten (Abbildung 3). Der Fall ist von 2023 und bis heute das am saubersten dokumentierte öffentliche Beispiel; seither haben die Anbieter versionierte Snapshots zum Standard gemacht. Genau deshalb ist er lehrreich: Er zeigt, was passiert, wenn man sie nicht nutzt.

Anbieter steuern mit festen Regeln: OpenAI kündigt die Abschaltung allgemein verfügbarer Modelle „at least 6 months“ im Voraus an, bei Vorschau-Modellen nur „such as 2 weeks“.^[8] Anthropic sagt „at least 60 days notice before model retirement“ zu und führt jedes Modell durch vier Stufen — Active, Legacy, Deprecated, Retired — bis gilt: „Requests to retired models will fail.“^[9] Modelle, auf denen Ihr Betrieb läuft, werden also planmäßig abgekündigt und irgendwann abgeschaltet (Abbildung 4).

Prompt-Drift: die hausgemachte Variante

Die dritte Ursache sitzt im eigenen Team. Ein Prompt ist die Anweisung, mit der Sie das Modell steuern. Man könnte annehmen, dass kleine, bedeutungsgleiche Änderungen — ein zusätzlicher Doppelpunkt, ein anderes Trennzeichen, eine Leerzeile — folgenlos bleiben. Das Gegenteil ist belegt.

Eine auf der Konferenz ICLR 2024 vorgestellte Studie variierte an Beispiel-Aufgaben (Few-Shot-Klassifikation) ausschließlich solche trivialen Formatierungsdetails — ohne den Sinn zu ändern. Ergebnis: Bei einzelnen Modellen (etwa LLaMA-2-13B) unterschieden sich die Trefferquoten auf derselben Aufgabe um bis zu 76 Prozentpunkte; im Mittel über mehr als 50 Aufgaben lag der Unterschied bei rund 10 Punkten. In etwa 14 % der Fälle kehrte sich allein durch das Format sogar die Rangfolge zweier Modelle um.^[10] Die 76 Punkte sind der Extremwert, nicht der Alltag — aber schon der Durchschnitt genügt: Wenn ein Mitarbeiter einen Prompt „nur kurz aufräumt“, kann er die Qualität des Agenten unbemerkt verändern, nach oben oder nach unten.

Warum es niemand merkt

Alle drei Ursachen haben eine gefährliche Eigenschaft gemeinsam: Sie erzeugen keinen Absturz, keine Fehlermeldung, keinen roten Alarm. Der Agent antwortet weiterhin flüssig und selbstbewusst — nur eben etwas anders, etwas schlechter. Ohne systematische Messung bleibt eine stille Verhaltensänderung unsichtbar.

Verschärfend verdeckt die übliche Prüfpraxis die Streuung: Wer einen Agenten nur einmal je Testfall prüft, sieht die Schwankung zwischen den Läufen gar nicht. Eine erstmals 2024 veröffentlichte und 2025 begutachtet publizierte Untersuchung maß, wie stark die Ergebnisse je nach Aufgabentyp schwanken. Am größten war die Streuung bei Aufgaben mit langer, generierter Ausgabe — Codegenerierung (Spanne zwischen bestem und schlechtestem Lauf von 11 bis über 27 Prozentpunkten) und mathematisches Schließen (bis zu rund 13 Punkte). Bei Multiple-Choice mit festem Antwortraum war sie dagegen winzig (höchstens 0,7 Punkte); offene Instruktionsaufgaben lagen mit rund 2 bis 9 Punkten dazwischen (Abbildung 5).^[4] Die Lehre: Ein einzelner Testlauf verdeckt genau diese Streuung — am stärksten bei Aufgaben mit langer, frei generierter Ausgabe. Prüfen Sie jeden Testfall mehrfach und betrachten Sie die Spanne, nicht den Einzelwert.

Hinweis zur Einordnung: Der Gartner-Wert ist eine Prognose, keine gemessene Ausfallrate. Gartner nennt vier Gründe für das Scheitern: schlechte Datenqualität, unzureichende Risikokontrollen, steigende Kosten und unklaren Geschäftswert.^[1]

Der Support-Agent, der leise falsch wurde

Illustratives Modellbeispiel — kein realer Einzelfall, aber in jeder Größenordnung realistisch.

Ausgangslage. Ein Softwareanbieter betreibt einen KI-Agenten im First-Level-Support — Rückgabefristen, Vertragsdetails, Konfigurationsfragen. Der Agent nutzt den bequemen allgemeinen Modellnamen, nicht eine feste Version. Bei der Abnahme vor sechs Monaten bestand er 96 % der Testfälle. Seither wurde er nicht angefasst — „läuft ja“.

Der stille Bruch. Der Anbieter hängt hinter dem Modellnamen eine neue Version ein. Von außen ändert sich nichts Sichtbares. Doch der Agent zitiert in Zweifelsfällen eine veraltete Kulanzregel. Kein Fehler springt heraus; die Antworten klingen weiterhin kompetent. Über drei Wochen steigen die Eskalationen langsam an — dann beschwert sich ein Großkunde über eine falsch zugesagte Frist. Die eigentlich teure Frage stellt sich erst danach: Wie viele weitere Kunden haben in diesen drei Wochen dieselbe falsche Zusage erhalten, und werden sie sich darauf berufen? Ohne Protokoll lässt sich das nicht einmal beantworten.

Die teure Suche. Die Fehlersuche dauert Tage, denn der erste Reflex lautet: „Wir haben doch nichts geändert.“ Genau das stimmt — geändert hat der Anbieter. Ohne Protokoll der Modellversion lässt sich der Zeitpunkt des Bruchs nicht einmal eingrenzen.

Fünf Bausteine, die ineinandergreifen

Die gute Nachricht: Man muss das Rad nicht neu erfinden. Die klassische Softwareentwicklung beherrscht den Umgang mit Änderungsrisiken seit Jahrzehnten — über Versionskontrolle, automatische Tests, Monitoring und klare Zuständigkeiten. Diese Disziplin lässt sich auf KI übertragen. Fünf Bausteine greifen ineinander (Abbildung 7): Zwei verhindern unkontrollierte Änderungen, zwei erkennen Qualitätsabfälle, einer fängt die folgenreichen Fälle ab.

1. 1
   Feste Modellversion (Pinning).

   Referenzieren Sie nie den allgemeinen Modellnamen, sondern immer eine konkrete, datierte Version. Damit schließen Sie den größten Teil des Anbieter-Risikos aus: Die Modellgewichte bleiben fest. Eine Restunsicherheit bleibt — Anbieter selbst weisen darauf hin, dass sich die Serving-Infrastruktur (Anfrage-Router, Sicherheitsfilter, Sampling-Logik) auch bei fester Modell-ID ändern und dann geringfügige Verhaltensunterschiede verursachen kann.^[11] Pinning ersetzt das Testen also nicht; es macht einen Modellwechsel zur bewussten, getesteten Entscheidung.^[5] Verfolgen Sie zugleich die Abkündigungsfristen (mind. 6 Monate bzw. 60 Tage).^[8][9]

   Wichtig: Pinning verschiebt den Modellwechsel, es erspart ihn nicht. Jede gepinnte Version wird irgendwann abgeschaltet, und zwar nach dem Kalender des Anbieters. Behandeln Sie den Wechsel deshalb als geplante Übung statt als Notfall (Abbildung 8): Das Kandidatenmodell läuft zuerst gegen dieselbe Eval-Suite, danach im Schattenbetrieb an einem Teil des echten Verkehrs mit; umgeschaltet wird erst bei gleichwertigem oder besserem Ergebnis, und die alte Version bleibt als Rückfallebene aktiv, solange der Anbieter sie noch bedient. Diese Übung ist der Grund, warum sich eine Eval-Suite auch dann bezahlt macht, wenn nie ein stiller Bruch eintritt.

   Wer die Anbieterabhängigkeit ganz ausschließen will, kann ein offenes Modell selbst betreiben; dann liegen die Gewichte dauerhaft bei Ihnen und niemand tauscht sie aus. Der Preis ist, dass Betrieb, Absicherung und Aktualisierung vollständig in Ihr Haus wandern. Für die meisten Mittelständler ist das der teurere Weg, für einzelne mit hohen Souveränitätsanforderungen der richtige.

2. 2
   Versionierung von Prompts und Konfiguration.

   Behandeln Sie Prompts wie Quellcode. Jede Änderung an einem Prompt — und ebenso an Parametern, Werkzeugen oder Geschäftsregeln — gehört in eine Versionskontrolle, mit Freigabeprozess, Änderungsprotokoll und Rollback auf die letzte funktionierende Fassung. Das ist die direkte Antwort auf die hausgemachte Prompt-Drift aus dem Abschnitt „Prompt-Drift: die hausgemachte Variante“: Wird ein Prompt „nur kurz aufgeräumt“, bleibt nachvollziehbar, wer wann was geändert hat — und der Effekt wird vor der Freigabe getestet, nicht beim Kunden entdeckt. Beziehen Sie dabei ausdrücklich die Schichten mit ein, die dieses Whitepaper sonst nur streift: Auch ein aktualisiertes Preisblatt in der Wissensbasis, eine geänderte Geschäftsregel oder eine neue Version eines angebundenen Werkzeugs verschiebt das Verhalten des Agenten. Diese Änderungen liegen vollständig in Ihrem Haus und sind damit die am leichtesten kontrollierbare Driftquelle überhaupt.

3. 3
   Eval-Suite: automatische Tests für KI.

   Eine Eval ist eine Sammlung realer Beispielfälle mit hinterlegter Soll-Antwort: ein Regressionstest für die KI, der Qualitätsabfälle in Zahlen sichtbar macht, bevor Kunden sie spüren. Fertige Werkzeugsammlungen dafür sind frei verfügbar, und die großen Anbieter haben Eval-Funktionen inzwischen in ihre Plattformen eingebaut.^[12]

   Prüfen Sie so, wie Sie betreiben. Eine Eval, die mit anderen Parametern, anderem Kontext oder anderen Werkzeugen läuft als die Produktion, misst ein anderes System — gleiche Temperature, gleicher Kontextaufbau, gleiche Werkzeuganbindung sind Pflicht. Bei Freitext, für den es keine eindeutige Soll-Antwort gibt, kann ein zweites, starkes Modell als „LLM-as-a-Judge“ bewerten. Zur oft zitierten Übereinstimmung von über 80 % mit menschlichen Bewertern gehört die Einordnung: Sie wurde bei paarweisen Präferenzurteilen zwischen zwei Antworten gemessen, und menschliche Bewerter sind untereinander etwa gleich häufig einig.^[13] Für die Prüfung, ob eine Auskunft sachlich richtig ist, ist der Wert nicht belegt. Deshalb gilt: Der Prüfer muss zuerst gegen eigene menschliche Bewertungen kalibriert werden, sonst messen Sie an den blinden Flecken eines zweiten Modells. Und er ist selbst ein Sprachmodell und unterliegt denselben drei Ursachen. Pinnen Sie auch das Judge-Modell und versionieren Sie den Judge-Prompt, sonst driftet Ihr Messgerät unbemerkt mit.

4. 4
   Monitoring in Produktion.

   Tests vor dem Start fangen bekannte Fälle ab; das Monitoring die unbekannten. Verfolgen Sie Eskalationsquote, Antwortlängen, Nutzerbewertungen und Stichproben — so wird ein schleichender Abfall zum Frühwarnsignal statt zur Kundenbeschwerde. Nehmen Sie dabei zwei Signalquellen mit, die häufig übersehen werden: Änderungen an der Wissensbasis und an angebundenen Werkzeugen gehören ins selbe Dashboard wie das Modell. Und Ihre Support-Mitarbeiter sind der billigste Driftsensor im Haus — im Beispiel oben stiegen ihre Eskalationen drei Wochen lang an, bevor jemand reagierte. Ein zweiminütiges wöchentliches „Fällt euch etwas auf?“ ersetzt kein Monitoring, findet aber manches früher.

5. 5
   Menschliche Kontrolle an den kritischen Stellen.

   Nicht jede Entscheidung muss geprüft werden — aber die folgenreichen. Wo eine Fehlantwort rechtlich, finanziell oder für die Kundenbeziehung teuer ist, gehört ein Mensch in die Schleife. In regulierten Anwendungen ist das Pflicht.

Werkzeuge allein genügen nicht — sie brauchen einen Rahmen. Vier Festlegungen entscheiden darüber, ob die fünf Bausteine im Alltag tragen:

• Zuständigkeit. Legen Sie fest, wem die Eval-Suite gehört, wer eine Modell- oder Prompt-Freigabe erteilt und wer auf einen Alarm reagiert. Ohne benannte Verantwortung verwaist jede Testdisziplin nach wenigen Wochen.
• Schwellenwerte und Reaktion. Definieren Sie vorab konkrete Grenzwerte und die zugehörige Reaktion: Ab welchem Qualitätsabfall wird eskaliert, ab welchem gestoppt oder zurückgerollt? Ein Alarm ohne hinterlegte Reaktion ist nur ein weiteres Dashboard.
• Protokollierung. Halten Sie zu jeder Antwort fest, was sie erzeugt hat: Modell-ID, Prompt-Version, Parameter, Wissensstand und Werkzeug-Versionen. Erst dieses Protokoll macht einen stillen Bruch nachträglich auffindbar.
• Risikoklassen. Stufen Sie den Aufwand nach Wirkung ab (Abbildung 9). Ein Agent für interne Textentwürfe braucht weniger Kontrolle als einer, der verbindliche Kundenzusagen macht oder Zahlungen auslöst. Nicht jede Anwendung braucht das volle Programm — aber jede die bewusste Einstufung.

„Definieren Sie Schwellenwerte“ ist schnell gesagt und leicht falsch gemacht. Wer die Grenze zu eng setzt, bekommt jede Woche Fehlalarm und schaltet die Suite nach einem Monat ab; wer sie zu weit setzt, merkt echte Drift nicht. Drei Faustregeln, zusammengefasst in Abbildung 10:

• Wie viele Fälle. Rund 50 reale Fälle sind ein tragfähiger Anfang. Nehmen Sie die häufigen und die teuren Fälle, nicht die exotischen: Was selten vorkommt und wenig kostet, gehört nicht in die erste Ausbaustufe.
• Wie oft. Jeden Fall drei- bis fünfmal laufen lassen und nicht den Einzelwert, sondern Median und Spanne festhalten. Ein einzelner Lauf verwechselt Streuung mit Drift — genau der Fehler aus dem Abschnitt „Warum es niemand merkt“.
• Ab wann Alarm. Leiten Sie die Grenze aus Ihrer eigenen Streuung ab, statt eine Wunschzahl zu setzen: Lassen Sie die Suite zwei Wochen im stabilen Betrieb laufen, notieren Sie das beobachtete untere Band, und schlagen Sie Alarm, wenn der Median es in zwei aufeinanderfolgenden Läufen unterschreitet. Die zweite Bedingung entkoppelt den Alarm von einzelnen Ausreißern.

Warum das nötig ist, zeigt das Support-Beispiel weiter oben: Ein Abfall von 96 % auf 71 % ist mit 50 Fällen sofort sichtbar. Ein Abfall von 96 % auf 88 % ist es nicht — bei einem einzigen Lauf je Fall verschwindet er im Rauschen. Genau die kleineren, schleichenden Abfälle sind aber die, die lange unentdeckt bleiben.

Ein Wort zum Aufwand, ehrlich kalkuliert: Ein Modell-Pin und ein erstes Test-Gerüst sind in wenigen Tagen eingerichtet und decken bereits einen großen Teil des Risikos ab. Eine wirklich belastbare Eval-Suite jedoch — eine repräsentative, sorgfältig bewertete Sammlung von Testfällen mit tragfähigen Schwellenwerten — entsteht nicht über Nacht; sie wächst mit dem Betrieb. Und wenn Sie dafür echte Kundenfälle verwenden, gelten die Regeln der DSGVO: Zweckbindung, Datenminimierung, wo möglich Anonymisierung. Eine Testsammlung mit echten Kundendaten ist eine Verarbeitung personenbezogener Daten — behandeln Sie sie entsprechend.

• Woche 1. Modell auf eine feste, datierte Version pinnen und die Protokollierung einschalten (Modell-ID, Prompt-Version, Parameter). Das stoppt sofort die stillen Anbieter-Updates und macht künftige Brüche überhaupt erst auffindbar.
• Monat 1. Ein erstes Eval-Gerüst aus rund 50 realen Fällen aufbauen, nächtlich laufen lassen und die Prompts unter Versionskontrolle stellen.
• Quartal 1. Die Eval-Suite zu einer belastbaren, bewerteten Sammlung ausbauen, Monitoring und Schwellenwerte scharfschalten und Zuständigkeiten sowie Risikoklassen verbindlich festlegen. Und: den ersten Modellwechsel einmal proben, solange kein Zeitdruck besteht — dann ist der Ablauf eingespielt, wenn der Anbieter Ihre Version abkündigt.

Zwei Wege daneben verdienen eine ehrliche Erwähnung, weil sie für manche Häuser der schnellere sind. Kaufen statt bauen: Etliche Plattformen bringen Versionierung, Evals und Monitoring bereits mit; wer keine eigene Testdisziplin aufbauen will, verlagert damit einen Teil der Arbeit — nicht aber die Verantwortung für die Testfälle und die Schwellenwerte, denn die kennt nur Ihr Haus. Weniger Agent: Oft genügt es, das Sprachmodell auf eine eng umrissene Stelle in einem ansonsten deterministischen Ablauf zu beschränken, statt einen frei antwortenden Agenten abzusichern. Das ist keine Kapitulation, sondern häufig die wirtschaftlichere Architektur.

Die laufenden Kosten fallen dagegen kaum ins Gewicht: Ein nächtlicher Eval-Lauf über rund 50 Fälle kostet an API-Gebühren Cent- bis Euro-Beträge. Rechnen Sie den Vergleich einmal für Ihr Haus durch — die Personentage der Fehlersuche zu Ihrem internen Satz, dazu der Jahresdeckungsbeitrag des Kunden, der bei einer falschen Zusage abspringen könnte. Meist steht die Zahl auf der Schadensseite bereits nach einem einzigen Vorfall über dem Aufwand beider Ausbaustufen zusammen.

Stabilität ist nicht nur guter Stil

Bevor es um Aufsichtsrecht geht, lohnt der Blick auf die Ebene, die Ihr Haus zuerst trifft: die Haftung. Was ein driftender Agent gegenüber Kunden auslöst, entscheidet sich nicht am AI Act, sondern an Leistungsbeschreibung, Gewährleistung und Zusicherung. Sagt Ihr Agent eine Frist verbindlich zu, die nicht gilt, wie im Support-Beispiel weiter oben, dann ist das eine falsche Auskunft Ihres Unternehmens und nicht die eines Werkzeugs. Dass eine Maschine sie erzeugt hat, entlastet nicht. Im Streitfall zählt, was zugesagt wurde und was Sie belegen können — und genau dafür ist die Protokollierung aus dem Lösungsteil (Modell-ID, Prompt-Version, Parameter, Wissensstand) das einzige belastbare Beweismittel. Wer nicht protokolliert, kann im Zweifel nicht einmal zeigen, wie lange der Fehler bestand und wie viele Zusagen davon betroffen waren.

Hinzu kommt eine Änderung, die viele noch nicht auf dem Schirm haben: Die neue EU-Produkthaftungsrichtlinie (EU) 2024/2853 erfasst Software und KI-Systeme ausdrücklich als Produkte. Der Kreis der Haftenden wird erweitert, Datenverlust gilt künftig als ersatzfähiger Schaden, und Geschädigte erhalten Beweiserleichterungen.^[14] Die Mitgliedstaaten müssen sie bis zum 9. Dezember 2026 umsetzen; in Deutschland liegt seit September 2025 ein Referentenentwurf für ein neu gefasstes Produkthaftungsgesetz vor, das Gesetzgebungsverfahren läuft noch.^[15] Für Anbieter, die KI-gestützte Funktionen in ein Produkt einbauen, ist das die praktisch relevantere Neuerung als die Hochrisiko-Pflichten des AI Act. Für einen reinen Auskunfts-Agenten bleibt dagegen die vertragliche Ebene der entscheidende Hebel.

Wer KI in sensiblen Feldern einsetzt, muss die Stabilität nicht nur wollen, sondern nachweisen. Der EU AI Act — die Verordnung (EU) 2024/1689 — verlangt für Hochrisiko-Systeme ausdrücklich, dass sie „achieve an appropriate level of accuracy, robustness and cybersecurity, and that they perform consistently in those respects throughout their lifecycle“ (Artikel 15)^[16] — die regulatorische Formulierung genau des Drift-Problems. Ergänzend fordert Artikel 14 wirksame menschliche Aufsicht über den gesamten Nutzungszeitraum.^[16] Wichtig für die Einordnung: Diese Pflichten treffen nur Systeme, die der AI Act ausdrücklich als hochriskant einstuft — etwa nach Anhang III (unter anderem Kreditwürdigkeit, Personalauswahl, kritische Infrastruktur) oder als Sicherheitsbauteil regulierter Produkte nach Anhang I. Die meisten Kundenservice- und Vertriebs-Agenten fallen nicht darunter; für sie ist Stabilität kein Gebot aus Artikel 15, sondern eine Frage von Qualität, Vertragstreue und Haftung. Der Maßstab, den der AI Act für Hochrisiko-KI setzt, bleibt für sie dennoch ein brauchbarer Orientierungspunkt.

Nicht-Hochrisiko heißt aber nicht AI-Act-frei — das wird regelmäßig verwechselt. Artikel 50 verpflichtet Anbieter, KI-Systeme, die unmittelbar mit natürlichen Personen interagieren, so zu gestalten, dass die betroffene Person erkennt, dass sie mit einer KI spricht, sofern das nicht ohnehin offensichtlich ist. Das trifft den typischen Kundenservice-Agenten unabhängig von seiner Risikoklasse, und die Pflicht gilt ab dem 2. August 2026. Anders als die Hochrisiko-Pflichten wurde sie nicht verschoben.^[16] Ergänzend verlangt Artikel 4 von Anbietern und Betreibern, die KI-Kompetenz der eigenen Leute zu fördern; der Digital Omnibus hat diese Pflicht abgeschwächt, aber nicht abgeschafft.^[17] Wer also glaubt, der AI Act betreffe seinen Support-Agenten gar nicht, liegt falsch — nur eben an einer anderen Stelle, als meist vermutet wird.

Zum Zeitplan: Die KI-Verordnung ist seit dem 1. August 2024 in Kraft und wird schrittweise wirksam. Die Änderungsverordnung (EU) 2026/1744, der „Digital Omnibus on AI“, wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und ist am 27. Juli 2026 in Kraft getreten.^[17] Sie verschiebt die zentralen Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III auf den 2. Dezember 2027 und für in regulierte Produkte eingebettete Hochrisiko-KI nach Anhang I auf den 2. August 2028. Die Transparenzpflichten aus Artikel 50 bleiben davon unberührt; lediglich die Kennzeichnung synthetischer Inhalte durch Systeme, die bereits vor dem 2. August 2026 auf dem Markt waren, greift später (2. Dezember 2026). Die inhaltlichen Anforderungen an Robustheit und Aufsicht bleiben unverändert — der Aufschub verschafft Zeit, er nimmt keine Pflicht weg (Abbildung 11).

Hinzu kommt die DSGVO — hier lohnt eine genaue Einordnung. Artikel 22 greift eng: nur bei Entscheidungen, die ausschließlich automatisiert ergehen und rechtlich oder ähnlich erheblich wirken (etwa eine automatische Kreditablehnung), kann sich der Betroffene ihnen widersetzen.^[18] Ein Support-Agent mit einem Menschen in der Schleife fällt in der Regel nicht darunter. Der breiter relevante Datenschutz-Hebel liegt woanders und wurde oben bereits benannt: Sobald Sie echte Kundenfälle in Evals und Monitoring verarbeiten, ist das eine Verarbeitung personenbezogener Daten mit allen DSGVO-Pflichten. Ein Agent, dessen Verhalten unkontrolliert driftet und den niemand wirksam überwacht, bleibt damit vor allem ein Qualitäts- und Haftungsrisiko; dort, wo Artikel 22 oder der AI Act greifen, kommt ein Governance-Risiko hinzu. Die fünf Bausteine sind zugleich die Bausteine der Nachweisbarkeit.

Fazit

KI-Agenten sind mächtige Werkzeuge — aber ihr Verhalten ist nicht fest, sondern beweglich. Es schwankt von Lauf zu Lauf (Nicht-Determinismus), verschiebt sich bei Anbieter-Updates und kippt bei Prompt-Änderungen. Keine dieser Bewegungen macht Lärm. Der belastbare Kern ist dabei nicht, dass jeder KI-Agent ein Betriebsrisiko wäre: Die Studienzahlen dieses Papiers belegen die Mechanismen, keine allgemeine Ausfallrate. Das Risiko konzentriert sich auf ungepinnte, ungetestete Agenten an folgenreichen Stellen — genau dort setzt die Test- und Kontrolldisziplin an. Das ist kein Grund, auf KI zu verzichten — es ist ein Grund, sie professionell zu betreiben: feste Versionen, versionierte Prompts, automatische Tests, Monitoring und menschliche Kontrolle, getragen von klaren Zuständigkeiten und Schwellenwerten. Unternehmen, die diese fünf Bausteine früh einziehen, holen aus KI verlässlich Wert — während andere den Umweg über die Kundenbeschwerde nehmen.

Quellen