Modelldrift: Erkennung, Überwachung und KI-Verordnung

Modelldrift beschreibt den Moment, in dem ein validiertes KI-Modell unbemerkt aufhört, das Modell zu sein, das Sie validiert haben. Niemand hat Code geändert, kein Release wurde ausgerollt, und trotzdem liefern die Vorhersagen andere Ergebnisse, weil sich die Wirklichkeit darunter verschoben hat. Die meisten Ratgeber behandeln Modelldrift als technisches Ärgernis, das ein Retraining-Job schon beheben wird. Aus Sicht von EU AI Act, DSGVO-Richtigkeitsgrundsatz und Bankenaufsicht ist das zu kurz gedacht: Hier kann ein System, das seine Konformitätsbewertung bestanden hat, die erklärte Genauigkeit verfehlen, ohne dass irgendjemand diese Veränderung freigegeben hätte.

Auf einen Blick

• Modelldrift ist der Leistungsverlust eines Modells nach dem Deployment, ausgelöst durch veränderte Eingabedaten (Datendrift) oder durch einen veränderten Zusammenhang zwischen Eingaben und Ergebnissen (Konzeptdrift).
• Art. 15 Abs. 1 KI-Verordnung verlangt von Hochrisiko-Systemen eine gleichbleibende Leistung über den gesamten Lebenszyklus, Abs. 3 verpflichtet zur Angabe der Genauigkeitswerte. Unentdeckte Modelldrift macht diese Angabe falsch.
• Art. 72 schreibt Anbietern von Hochrisiko-Systemen ein Post-Market-Monitoring vor. Der Digital Omnibus ersetzt den Durchführungsrechtsakt durch Leitlinien der Kommission mit Vorlage bis zum 2. September 2027.
• Ein Retraining innerhalb eines bei der Erstbewertung dokumentierten Änderungsrahmens ist keine wesentliche Änderung (Art. 43 Abs. 4). Außerhalb dieses Rahmens kann es eine sein.
• Bei LLMs kommt die Drift oft vom Anbieter. Versionen festschreiben und Änderungsmitteilungen vertraglich sichern sind deshalb Kontrollen gegen Modelldrift.

Was ist Modelldrift?

Modelldrift, im Englischen Model Drift oder auch Model Decay genannt, bezeichnet den schleichenden oder abrupten Verlust an Vorhersagequalität, sobald ein Machine-Learning-Modell mit Live-Daten arbeitet. IBM beschreibt das Phänomen ähnlich: Das Modell wurde auf eine Momentaufnahme der Realität angepasst, und die Realität ist weitergezogen. Hinter dem Begriff stehen drei unterschiedliche Mechanismen, und jeder verlangt eine andere Reaktion.

• Datendrift (Covariate Shift). Die statistische Verteilung der Eingaben verändert sich. Ein Betrugsmodell, das auf Kartenzahlungen am Terminal trainiert wurde, sieht plötzlich überwiegend Wallet-Zahlungen. Die Regeln zwischen Eingabe und Ergebnis mögen noch gelten, doch das Modell arbeitet nun in Bereichen, die es im Training kaum gesehen hat.
• Konzeptdrift. Der Zusammenhang zwischen Eingaben und Zielgröße verschiebt sich. Dasselbe Einkommens- und Schuldenprofil, das in stabilen Zeiten ein geringes Kreditrisiko signalisierte, bedeutet in einer Inflationsphase ein höheres Risiko. Die Eingaben wirken vertraut, ihre Bedeutung hat sich geändert.
• Label-Drift (Prior Probability Shift). Die Basisrate des Ergebnisses ändert sich. Verdoppelt sich die Betrugsquote, schlägt ein auf die alte Quote kalibriertes Modell zu selten Alarm, auch wenn sonst alles gleich bleibt.

Modelldrift kann plötzlich auftreten (Pandemie, neue Regulierung, Produkteinführung), allmählich (demografischer Wandel), saisonal (Einzelhandelsnachfrage) oder wiederkehrend. Hinzu kommt ein Klassiker aus der Praxis: Änderungen in vorgelagerten Pipelines, etwa ein umbenanntes Feld oder eine Umstellung von Euro auf Cent, erzeugen dieselben Symptome wie echte Drift, sind aber schlicht Datenqualitätsfehler. Beides sauber auseinanderzuhalten ist der erste Schritt jeder Reaktion.

Modelldrift, Datendrift und Konzeptdrift im Vergleich

<table header-row=“true“> <tr> <td>Begriff</td> <td>Was sich ändert</td> <td>Typisches Signal</td> <td>Erste Reaktion</td> </tr> <tr> <td>Datendrift</td> <td>Verteilung der Eingaben</td> <td>PSI oder KS-Test auf Merkmalen</td> <td>Pipeline prüfen, dann Auswirkung bewerten</td> </tr> <tr> <td>Konzeptdrift</td> <td>Zusammenhang Eingabe und Ergebnis</td> <td>Genauigkeitsverlust auf gelabelten Fällen</td> <td>Neu validieren, meist neu trainieren</td> </tr> <tr> <td>Label-Drift</td> <td>Basisrate des Ergebnisses</td> <td>Abweichung zwischen prognostizierten und tatsächlichen Quoten</td> <td>Schwellenwerte neu kalibrieren</td> </tr> <tr> <td>Modelldrift</td> <td>Gesamtleistung (die Wirkung)</td> <td>Jedes der obigen Signale</td> <td>Ursache klären, bevor gehandelt wird</td> </tr> </table> Kurz gesagt: Datendrift und Konzeptdrift sind Ursachen, Modelldrift ist die messbare Wirkung auf die Leistung.

Warum Modelldrift ein Compliance-Thema ist und nicht nur ein MLOps-Problem

Die gängigen Erklärungen zur Modelldrift enden bei Dashboards und Retraining-Zyklen. Damit geht an der Frage vorbei, die eine Aufsichtsbehörde oder ein Prüfer tatsächlich stellt. Die lautet nicht „Haben Sie neu trainiert?“, sondern: Woher wussten Sie es, was haben Sie entschieden, und wo ist das dokumentiert? Drei rechtliche Anker machen aus Modelldrift ein Compliance-Ereignis. Die erklärte Genauigkeit. Nach Art. 15 KI-Verordnung müssen Hochrisiko-KI-Systeme ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen und in dieser Hinsicht während ihres gesamten Lebenszyklus beständig funktionieren. Absatz 3 verlangt, dass Genauigkeitsgrade und die zugehörigen Metriken in der Betriebsanleitung angegeben werden. Wer bei der Konformitätsbewertung 94 Prozent Recall erklärt hat und wegen Modelldrift heute bei 86 Prozent liegt, vertreibt ein Produkt, das seine eigene Dokumentation nicht mehr erfüllt. Für Systeme, die nach dem Inverkehrbringen weiterlernen, fordert derselbe Artikel zudem den Umgang mit Rückkopplungsschleifen, in denen verzerrte Ausgaben zu den Trainingsdaten von morgen werden. Der Richtigkeitsgrundsatz im Datenschutz. Trifft oder stützt ein Modell Entscheidungen über Personen, sind verschlechterte Vorhersagen unrichtige personenbezogene Daten im Sinne von Art. 5 Abs. 1 lit. d DSGVO. Der Europäische Datenschutzbeauftragte (EDSB) hat das in seinen Leitlinien zum Risikomanagement von KI-Systemen vom November 2025 ausdrücklich gemacht: Ungenaue Ausgaben durch Datendrift und nachlassende Qualität personenbezogener Eingabedaten stehen dort als benanntes Risiko. Das Beispiel ist ein Kreditscoring-Modell, trainiert in einer stabilen Wirtschaftslage und eingesetzt in einer Krise mit sprunghaft steigender Inflation und Arbeitslosigkeit. Empfohlen werden vier Maßnahmen: Drifterkennung, Überwachung der Datenqualität, Retraining nach festem Plan oder bei erkannter Drift sowie Feedbackkanäle für Nutzer. Die Leitlinien richten sich formal an EU-Institutionen, sind aber auch für Unternehmen ein nützlicher Maßstab, zumal der BfDI und die Landesdatenschutzbehörden denselben Grundsatz anwenden. Fairness, die verfällt. Ein Modell kann seine Gesamtgenauigkeit halten, während die Fehlerquote für eine Untergruppe steigt, weil sich nur deren Daten verschoben haben. Ein Monitoring, das ausschließlich globale Kennzahlen verfolgt, übersieht das. Fairness-Metriken gehören deshalb in denselben Überwachungsplan, wie in unserem Beitrag zu KI-Bias beschrieben.

Was die Vorschriften zur Modelldrift verlangen

Keine Verordnung definiert Modelldrift als Rechtsbegriff, doch mehrere verlangen genau das, was ein sauberes Drift-Management liefert. Die Tabelle ordnet die wichtigsten Regelwerke ein. <table header-row=“true“> <tr> <td>Regelwerk</td> <td>Vorschrift</td> <td>Bedeutung für Drift</td> </tr> <tr> <td>KI-Verordnung</td> <td>Art. 15 Abs. 1 und 3</td> <td>Beständige Leistung über den Lebenszyklus, erklärte Genauigkeitsmetriken</td> </tr> <tr> <td>KI-Verordnung</td> <td>Art. 9 Abs. 2 lit. c</td> <td>Risikomanagement bewertet Risiken aus den Daten des Post-Market-Monitorings</td> </tr> <tr> <td>KI-Verordnung</td> <td>Art. 12</td> <td>Automatische Protokollierung als Grundlage der Überwachung nach dem Deployment</td> </tr> <tr> <td>KI-Verordnung</td> <td>Art. 26 Abs. 5</td> <td>Betreiber überwachen den Betrieb und informieren den Anbieter über Risiken</td> </tr> <tr> <td>KI-Verordnung</td> <td>Art. 72</td> <td>Anbieter betreiben ein dokumentiertes System und einen Plan zur Beobachtung nach dem Inverkehrbringen</td> </tr> <tr> <td>KI-Verordnung</td> <td>Art. 73</td> <td>Meldung schwerwiegender Vorfälle binnen 15 Tagen, in Sonderfällen 10 oder 2 Tage</td> </tr> <tr> <td>NIST AI RMF</td> <td>MEASURE 2.4, MANAGE 4.1</td> <td>Produktionsverhalten wird gegen Testergebnisse vor dem Deployment überwacht</td> </tr> <tr> <td>ISO/IEC 42001</td> <td>Abschnitt 9.1, Annex-A-Maßnahme zu Betrieb und Überwachung</td> <td>Überwachung, Messung und Bewertung der Leistung von KI-Systemen</td> </tr> <tr> <td>US-Bankenaufsicht</td> <td>SR 26-2 (April 2026)</td> <td>Risikobasiertes Modellrisikomanagement, ersetzt SR 11-7</td> </tr> </table> Beobachtung nach dem Inverkehrbringen gemäß Art. 72. Anbieter von Hochrisiko-Systemen müssen ein System zur Beobachtung nach dem Inverkehrbringen einrichten und dokumentieren, das über die gesamte Lebensdauer aktiv und systematisch Leistungsdaten erhebt und auswertet (Art. 72). Der Plan ist Teil der technischen Dokumentation nach Anhang IV. Ursprünglich sollte die Kommission bis zum 2. Februar 2026 einen Durchführungsrechtsakt mit Vorlage erlassen. Die Verordnung (EU) 2026/1744, der Digital Omnibus zur KI, hat das durch Leitlinien der Kommission samt Vorlage ersetzt, fällig bis zum 2. September 2027. Die Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III gelten nun ab dem 2. Dezember 2027, für eingebettete Systeme nach Anhang I ab dem 2. August 2028. Die Vorlage kommt also wenige Monate vor den ersten Anwendungsfällen. Abwarten ist trotzdem keine gute Idee: Die Bausteine eines belastbaren Plans sind heute schon klar. NIST AI RMF. MEASURE 2.4 sieht vor, dass Funktion und Verhalten des KI-Systems in der Produktion überwacht werden, und das NIST-Playbook nennt Drift ausdrücklich als Grund. Teams sollen Produktionsmetriken mit Testergebnissen vor dem Deployment vergleichen und Alarme auslösen, wenn sich Eingabe- oder Vorhersageverteilungen verschieben. Die vollständige Zuordnung der Funktionen finden Sie in unserem Leitfaden zum NIST AI Risk Management Framework. Bankenaufsicht: EZB-Leitfaden und eine Lücke in den USA. Für Institute im Euroraum ist der EZB-Leitfaden zu internen Modellen der naheliegende Bezugspunkt. Die Überarbeitung vom Juli 2025 enthält erstmals einen Abschnitt zu Machine Learning mit Erwartungen an Erklärbarkeit, an das Verhältnis von Leistung und Komplexität sowie an die Validierung. Wer ML-basierte Risikomodelle betreibt, wird Modelldrift gegenüber der Aufsicht, national auch gegenüber der BaFin, künftig als Validierungsfrage erklären müssen. In den USA hat die Federal Reserve am 17. April 2026 SR 26-2 veröffentlicht, das SR 11-7 aus dem Jahr 2011 und SR 21-8 ablöst, begleitet vom OCC Bulletin 2026-13. Die neue Fassung ist kürzer und stärker risikobasiert, und eine Fußnote nimmt generative und agentische KI-Modelle vom Anwendungsbereich aus, bis eine angekündigte Konsultation abgeschlossen ist. Ausgerechnet die Modelle, die am stärksten anbieterseitiger Drift ausgesetzt sind, fallen damit aus der Modellrisiko-Guidance heraus. Mehr zum Übergang lesen Sie in unserem Beitrag zum Modellrisikomanagement.

Drift oder wesentliche Änderung? Die Entscheidung über das Retraining

Retraining ist die übliche Antwort auf Modelldrift, und genau hier entsteht eine Rechtsfrage, die technische Ratgeber meist auslassen. Nach Art. 3 Nr. 23 ist eine wesentliche Änderung eine Veränderung nach dem Inverkehrbringen, die in der ursprünglichen Konformitätsbewertung nicht vorgesehen oder geplant war und die Konformität berührt oder die Zweckbestimmung ändert. Eine wesentliche Änderung zieht eine neue Konformitätsbewertung nach sich. Art. 43 Abs. 4 öffnet einen Weg. Bei weiterlernenden Systemen gelten Änderungen an System und Leistung, die der Anbieter bei der ursprünglichen Konformitätsbewertung festgelegt und in der technischen Dokumentation beschrieben hat, nicht als wesentliche Änderung. Die praktische Folge: Der Rahmen für das Retraining muss vor dem Launch schriftlich stehen, nicht erst nach dem ersten Alarm improvisiert werden. Ein belastbarer Retraining-Rahmen legt fest:

1. Was sich ändern darf. Zum Beispiel die Modellgewichte durch Retraining auf demselben Merkmalsset und denselben Datenquellen. Keine neuen Merkmale, keine neue Modellfamilie.
2. Welche Daten verwendet werden dürfen. Quellen, Zeitfenster, Qualitätsprüfungen und die Repräsentativitätsprüfungen nach Art. 10.
3. Die Abnahmekriterien. Mindestwerte für Genauigkeit, Kalibrierung und Fairness in Untergruppen, die ein neu trainiertes Modell vor der Freigabe erreichen muss, verknüpft mit den nach Art. 15 Abs. 3 erklärten Metriken.
4. Die Validierungsmethode. Hold-out-Design, Vergleich mit dem Live-Modell, Freigaberollen.
5. Die Grenze. Welche Änderungen außerhalb des Rahmens liegen und eine Prüfung auf wesentliche Änderung auslösen.

Die Logik entspricht der Leitlinie der US-amerikanischen FDA zu Predetermined Change Control Plans für KI-gestützte Medizinprodukte, finalisiert im Dezember 2024: geplante Änderungen, Methode zu deren Entwicklung und Validierung sowie Folgenabschätzung werden vorab beschrieben. Medizintechnik-Teams, die beiden Regimen unterliegen, können ein einziges Change-Control-Design für beide nutzen.

Wie man Modelldrift erkennt

Die Erkennung hat zwei Ebenen, und ein reifes Programm betreibt beide. Leistungsüberwachung auf Basis tatsächlicher Ergebnisse. Sobald Ergebnisse vorliegen (ein Kredit fällt aus oder nicht, ein Schadenfall erweist sich als Betrug oder nicht), werden Vorhersagen mit der Realität verglichen: Genauigkeit, Recall, Kalibrierung und Fehlerquoten je Untergruppe, jeweils gegen die erklärte Baseline. Nur so lässt sich Modelldrift direkt messen. Die Schwäche ist die Verzögerung, denn Kreditausfälle zeigen sich oft erst nach Monaten. Verteilungsüberwachung als Frühwarnsystem. Weil Labels verspätet eintreffen, beobachten Teams Eingaben und Ausgaben auf Veränderungen:

• Der Population Stability Index (PSI) vergleicht gebinnte Verteilungen zwischen einem Referenzfenster und einem Live-Fenster. Als verbreitete Faustregel gilt ein Wert unter 0,1 als stabil, 0,1 bis 0,25 als moderate Verschiebung und über 0,25 als deutliche Verschiebung. Das sind Konventionen, keine Rechtsnormen, und jeder übernommene Schwellenwert sollte im Überwachungsplan begründet sein.
• Der Kolmogorow-Smirnow-Test für stetige Merkmale und der Chi-Quadrat-Test für kategoriale Merkmale.
• Wasserstein-Distanz und Jensen-Shannon-Divergenz, wenn das Ausmaß einer Verschiebung aussagekräftiger ist als ein p-Wert.
• Vorhersagedrift: die Verteilung der Scores oder Klassen, die das Modell ausgibt. Sie bewegt sich, bevor Labels irgendetwas bestätigen.

Zwei Vorbehalte. Erstens markieren statistische Tests bei großen Datenmengen auch triviale Verschiebungen als signifikant, deshalb braucht es zusätzlich Schwellen für die Effektstärke. Zweitens ist Datendrift ohne Leistungsverlust häufig. Ein Alarm sollte eine Untersuchung eröffnen, kein automatisches Retraining auslösen. Wie Benchmarks diese Baseline speisen, zeigt unser Beitrag zum KI-Benchmark.

Modelldrift bei LLMs und Modellen von Drittanbietern

Große Sprachmodelle driften auf eine Weise, für die klassische MLOps-Werkzeuge nicht gebaut wurden: Die Veränderung passiert häufig beim Anbieter. In einer vielzitierten Studie verglichen Chen, Zaharia und Zou die Versionen von GPT-4 aus März und Juni 2023. Die Trefferquote bei der Unterscheidung von Primzahlen und zusammengesetzten Zahlen fiel von 84 auf 51 Prozent, und auch das Befolgen von Anweisungen ließ nach. Gleicher Produktname, drei Monate Abstand. Für Betreiber ist LLM-Modelldrift damit ebenso ein Drittparteienrisiko wie ein technisches. Die passenden Kontrollen:

• Modellversionen festschreiben, wo der Anbieter datierte Snapshots anbietet, und bewegliche Aliase für Hochrisiko-Einsätze als nicht freigegeben behandeln.
• Ein festes Evaluationsset ausführen (Referenz-Prompts mit erwartetem Verhalten, Verweigerungstests, Formatprüfungen), bei jedem Versionswechsel und turnusmäßig, und die Ergebnisse aufbewahren.
• Änderungsmitteilungen vertraglich vereinbaren: Vorankündigung von Updates und Abkündigungen, Zugang zu Release Notes. Die nötigen Klauseln listet unser Leitfaden zur Lieferanten-Due-Diligence für KI.
• Auch die Eingaben überwachen. Nutzerverhalten ändert sich, und bei Retrieval-Augmented-Generation verändern sich die abgerufenen Dokumentbestände. Beides verschiebt Ausgaben ohne jedes Anbieter-Update.

Ein Überwachungsplan für Modelldrift, den Prüfer akzeptieren

Unabhängig davon, wie die Vorlage der Kommission am Ende aussieht: Ein Plan, der die folgenden Punkte beantwortet, besteht vor Art. 72, ISO/IEC 42001 und NIST gleichermaßen.

1. Umfang und Verantwortung. Welche Modellversionen, welche Anwendungsfälle, und eine namentlich benannte verantwortliche Person für Entscheidungen zur Modelldrift. Verknüpfen Sie jedes Modell mit seinem Eintrag in Ihrem KI-Inventar und -Register.
2. Metriken und Baselines. Die in der Betriebsanleitung erklärten Genauigkeitsmetriken, Fairness-Metriken für Untergruppen und die Verteilungsmetriken zur Frühwarnung, jeweils mit Ausgangswert und dem Datensatz, aus dem er stammt.
3. Datenquellen. Wo Produktionseingaben, Vorhersagen und Ergebnisse protokolliert werden (die Protokolle nach Art. 12 sind die natürliche Quelle) und wie Rückmeldungen der Betreiber den Anbieter erreichen.
4. Takt. Wie oft jede Metrik berechnet und geprüft wird, und von wem. Risikoreichere und schneller wandelnde Domänen bekommen kürzere Zyklen.
5. Schwellenwerte und Eskalation. Warn- und Handlungsstufen je Metrik und wer auf welcher Stufe informiert wird.
6. Reaktionsverfahren. Die Schritte vom Alarm bis zur Entscheidung, einschließlich der Prüfung auf wesentliche Änderung und auf einen meldepflichtigen Vorfall.
7. Aufzeichnungen. Jeder Alarm, jede Untersuchung, jede Entscheidung, jeder Retraining-Lauf und jedes Validierungsergebnis, aufbewahrt zusammen mit der technischen Dokumentation. Ein Prüfer muss nachvollziehen können, warum das heute produktive Modell genau dieses Modell ist.

An den Aufzeichnungen sparen die meisten Teams am stärksten. Ein Dashboard, das erst rot und dann wieder grün wurde, beweist nichts, solange niemand zeigen kann, was dazwischen entschieden wurde. Den größeren Zusammenhang beschreibt unser Beitrag zum Compliance-Monitoring von KI-Systemen.

Auf Modelldrift reagieren: ein Vorgehen in fünf Schritten

1. Ursache eingrenzen. Zuerst Pipeline-Fehler ausschließen: Schemaänderungen, fehlerhafte Joins, geänderte Einheiten, fehlende Werte. Ein erstaunlich großer Teil der Drift-Alarme sind Datenqualitätsfehler.
2. Auswirkung bewerten. Liegt die Leistung auf gelabelten Ergebnissen unter den Abnahmekriterien? Für welche Untergruppen? Welche Entscheidungen hat das Modell beeinflusst, seit die Verschiebung begann?
3. Eindämmen. Je nach Schwere die Quote menschlicher Prüfungen erhöhen, Entscheidungsschwellen verschärfen, auf eine Vorversion zurückfallen oder automatisierte Entscheidungen aussetzen. Die Maßnahmen zur menschlichen Aufsicht nach Art. 14 sollten diese Schalter bereits definieren.
4. Korrigieren. Innerhalb des dokumentierten Rahmens neu trainieren oder rekalibrieren, gegen die Abnahmekriterien validieren und über den regulären Freigabeweg ausrollen. Liegt die Korrektur außerhalb des Rahmens, beginnt vor dem Release eine Prüfung auf wesentliche Änderung.
5. Melden und lernen. Hat die Modelldrift zu einem Ereignis geführt, das die Definition eines schwerwiegenden Vorfalls nach Art. 3 Nr. 49 erfüllt, läuft die Frist nach Art. 73: 15 Tage als Regel, 10 Tage bei einem Todesfall und 2 Tage bei einem weitverbreiteten Verstoß oder einer schweren Störung kritischer Infrastruktur. Das Verfahren erläutert unser Leitfaden zur KI-Vorfallmeldung. In jedem Fall fließt die Erkenntnis in das KI-Risikomanagement zurück, wie es Art. 9 Abs. 2 lit. c verlangt.

Häufige Fragen

Was ist Modelldrift, einfach erklärt? Modelldrift bedeutet, dass ein Machine-Learning-Modell nach dem Deployment schlechter wird, weil sich die Daten, die es sieht, oder deren Bedeutung seit dem Training verändert haben. Das Modell selbst ist unverändert, die Welt um es herum hat sich bewegt. Sichtbar wird das an sinkender Genauigkeit, schlecht kalibrierten Scores oder wachsenden Fehlern für bestimmte Gruppen. Modelldrift ist in fast jedem Produktivsystem zu erwarten, weshalb sie überwacht und nicht einfach ausgeschlossen werden muss. Worin unterscheiden sich Datendrift und Modelldrift? Datendrift ist eine Veränderung in der Verteilung der Eingaben. Modelldrift ist der daraus resultierende Leistungsverlust. Datendrift kann ohne Modelldrift auftreten, wenn das Modell gut auf die neuen Eingaben generalisiert. Umgekehrt kann Modelldrift ohne sichtbare Datendrift entstehen, nämlich wenn Konzeptdrift den Zusammenhang zwischen Eingaben und Ergebnissen verändert. Überwachen Sie beides: Datendrift als Frühwarnung, die Leistung als Bestätigung. Was bedeutet Modelldrift bei LLMs? Gemeint ist eine Veränderung im Verhalten eines Sprachmodells über die Zeit. Sie kann daher rühren, dass der Anbieter hinter demselben Namen ein anderes Modell ausliefert, dass sich Prompts, Nutzerverhalten oder abgerufene Dokumente ändern, oder dass nachtrainiert wurde. Forschung zu GPT-4 hat große Leistungssprünge zwischen zwei Versionen im Abstand von drei Monaten gezeigt. Schreiben Sie Versionen fest, lassen Sie bei jedem Wechsel ein festes Evaluationsset laufen und sichern Sie sich vertraglich Vorankündigungen. Ist ein Retraining eine wesentliche Änderung nach der KI-Verordnung? Nicht, wenn es vorab festgelegt war. Nach Art. 43 Abs. 4 sind Änderungen, die der Anbieter bei der ursprünglichen Konformitätsbewertung geplant und in der technischen Dokumentation beschrieben hat, keine wesentlichen Änderungen. Ein Retraining, das Merkmale, Datenquellen oder die Zweckbestimmung verändert oder die dokumentierten Abnahmekriterien verfehlt, kann dagegen eine sein und erfordert dann eine neue Konformitätsbewertung. Wie oft sollte man auf Modelldrift prüfen? Eine gesetzlich festgelegte Frequenz gibt es nicht. Den Takt bestimmen das Risiko und die Geschwindigkeit, mit der sich die Domäne verändert: tägliche oder kontinuierliche Verteilungsprüfungen bei Entscheidungen in hohem Volumen, wöchentliche oder monatliche Leistungsreviews dort, wo Labels eintreffen, und mindestens jährlich eine formale Überprüfung. Halten Sie die Begründung im Plan zur Beobachtung nach dem Inverkehrbringen fest, denn genau diese Begründung wird eine Prüfstelle hinterfragen. Ist Modelldrift ein schwerwiegender Vorfall nach Art. 73? Für sich genommen nicht. Meldepflichtig wird Modelldrift, wenn sie direkt oder indirekt zu einem Ereignis im Sinne von Art. 3 Nr. 49 führt: Tod oder schwere Gesundheitsschäden, schwere und unumkehrbare Störung kritischer Infrastruktur, Verstoß gegen Pflichten zum Schutz der Grundrechte oder schwere Schäden an Eigentum oder Umwelt. Ein driftendes Kredit- oder Recruiting-Modell, das in großem Umfang diskriminierende Ergebnisse liefert, kann die Grundrechtsvariante erfüllen.

Fazit

Modelldrift kommt mit Sicherheit. Offen ist nur, ob Sie belegen können, dass Sie damit umgegangen sind. Die technische Seite ist mit vorhandenen Werkzeugen gut abgedeckt: Verteilungstests, Leistungstracking, Retraining-Pipelines. Angreifbar sind die meisten Organisationen auf der Governance-Seite, denn KI-Verordnung, DSGVO und Bankenaufsicht stellen im Kern dieselbe Frage: Hat das Modell weiterhin getan, was Sie zugesagt haben, und können Sie das zeigen? Die Antwort beruht auf drei Artefakten, die vor dem Launch vorliegen müssen: erklärte Metriken mit Baselines, ein Überwachungsplan mit Schwellenwerten und Verantwortlichen sowie ein Retraining-Rahmen, der Routinekorrekturen aus dem Bereich der wesentlichen Änderung heraushält. Danach zählen die Aufzeichnungen. AI Sigil verknüpft jedes Modell in Ihrem Register mit seinem Überwachungsplan, seinen Entscheidungen zur Modelldrift und den zugehörigen Nachweisen, sodass die Antwort an einen Prüfer ein Bericht ist und keine Rekonstruktion.