Modellrisiko jenseits von Bias: Drift, Brittleness und Black Boxes

# Modellrisiko jenseits von Bias: Drift, Brittleness und Black Boxes

Eine Sozialbehörde auf Bezirksebene bringt Anfang 2024 ein KI-Modell in Betrieb, das markiert, welche SNAP-Anträge (Supplemental Nutrition Assistance Program) voraussichtlich anspruchsberechtigt sind und welche eine manuelle Prüfung brauchen. Genauigkeit zum Start: 94 %. Mitte 2025 fällt den Sachbearbeitern etwas auf: Das Modell lässt Anträge durch, die es markieren sollte, und markiert solche, die es nicht markieren sollte. Niemand hat das Modell verändert. Verändert hat sich alles drumherum: eine Anpassung der Einkommensgrenzen, eine verschobene Zusammensetzung der Antragsteller nach einer Fabrikschließung, ein neues Formular des Bundesstaats. Das Modell ist nicht schlechter geworden. Die Welt hat sich bewegt, und das Modell nicht mit.

Das ist kein Fairness-Versagen im klassischen Sinn (keine geschützte Gruppe wurde beim Design bewusst benachteiligt). Es ist eine andere, leisere Risikokategorie: Model Drift, neben Brittleness und Opazität eine der drei Fehlerarten, auf die jeder KI-Einsatz im öffentlichen Sektor jenseits von Bias-Audits prüfen muss.

Warum „jenseits von Bias“ zählt

Die meisten Diskussionen zur KI-Governance im öffentlichen Sektor landen sofort bei Bias und Fairness, und das aus gutem Grund: diskriminierende Ergebnisse bei Sozialleistungs-, Polizei- oder Recruiting-Modellen führen zu echter juristischer Exponierung, etwa unter dem Rahmen des US Civil Rights Act und dem AI Act der EU (Verordnung (EU) 2024/1689), die Systeme zur Anspruchsprüfung bei öffentlichen Leistungen als „Hochrisiko-KI-Systeme“ mit laufender Überwachungspflicht einordnet.

Ein Modell kann zum Start aber vollkommen fair sein und trotzdem katastrophal scheitern, aus Gründen, die nichts mit Bias zu tun haben. Die Regulierer holen hier auf: Der EU AI Act verlangt ausdrücklich, dass bei Hochrisikosystemen „Genauigkeit, Robustheit und Cybersicherheit“ über den gesamten Lebenszyklus überwacht werden, nicht nur beim Deployment. Das AI Risk Management Framework des NIST (ein freiwilliger US-Standard, veröffentlicht 2023) benennt es direkt: Risiko ist keine einmalige Zertifizierung, sondern eine kontinuierliche Managementaufgabe.

Die drei Risikokategorien jenseits von Bias

1. Drift: das Modell ist veraltet

Model Drift entsteht, wenn sich der statistische Zusammenhang zwischen Inputs und Ergebnissen nach dem Deployment verändert, sodass ein auf alten Mustern trainiertes Modell auf neuen Daten immer falschere Vorhersagen trifft.

Zwei Varianten sind für den öffentlichen Sektor relevant:

• Data Drift: Die Input-Population verändert sich. Beispiel: Der Bewerberpool eines Weiterbildungsprogramms für Arbeitskräfte verschiebt sich nach einer regionalen Entlassungswelle, das Modell sieht Einkommens- und Beschäftigungsmuster, auf die es nie trainiert wurde.
• Concept Drift: Die *Regel*, die Inputs mit der richtigen Antwort verbindet, ändert sich. Beispiel: Ein Bundesstaat erhöht die SNAP-Einkommensgrenze. Das Einkommen des Antragstellers hat sich nicht geändert, aber die Frage, ob dieses Einkommen zur Anspruchsberechtigung führt, schon. Das Modell weiß nichts davon, dass die Regel verschoben wurde.

Concept Drift ist im Behördenumfeld besonders gefährlich, weil sich Politik ständig ändert: Haushaltszyklen, Gesetzesänderungen, Gerichtsurteile, Notfall-Ausnahmen (wie die SNAP-Flexibilisierungen in der COVID-Zeit). Ein Modell, das zum Trainingszeitpunkt eingefroren wurde, wird mit jedem Beschluss eines Gesetzgebers stillschweigend obsolet.

Einfacher Drift-Check (illustrativ, kein echter Datensatz):

# Compare feature distributions: training data vs. last 90 days
from scipy.stats import ks_2samp

stat, p_value = ks_2samp(training_income, recent_income)
if p_value < 0.05:
    print("Significant distribution shift detected: flag for review")

Das ist ein Kolmogorov-Smirnov-Test, eine gängige statistische Prüfung, ob zwei Stichproben aus unterschiedlichen Verteilungen stammen. ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → sagt Ihnen nicht, *warum* sich etwas verschoben hat, aber ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → sagt Ihnen, *wann* Sie hinschauen müssen.

2. Brittleness: das Modell bricht bei Randfällen, die es nie gesehen hat

Brittleness ist das Versagen eines Modells, über die engen Bedingungen seiner Trainingsdaten hinaus zu generalisieren. Es funktioniert im Durchschnitt gut, zerbricht aber bei Inputs, die leicht unüblich, adversarial oder einfach selten sind.

Beispiel: Ein Modell zur Betrugserkennung bei Arbeitslosenversicherung, das überwiegend auf typischen W-2-Lohnempfängern trainiert wurde, kann bei Gig-Workern, Saisonfischern oder Menschen mit informellem Bareinkommen völlig danebenliegen, nicht wegen Bias, sondern weil diese Muster in den Trainingsdaten statistisch unterrepräsentiert sind. In der Kontroverse um die Betrugserkennung bei Arbeitslosengeld in Michigan (2013 bis 2015) markierte ein System namens MiDAS Zehntausende Anträge als betrügerisch, mit später festgestellten extrem hohen Fehlerquoten; ein Faktor war ein System, das schlecht auf die reale Vielfalt der Fälle kalibriert war und falsche Betrugsfeststellungen erzeugte, die Sanktionen auslösten, bevor die menschliche Prüfung die Fehler entdeckte.

Wegen Brittleness ist Stresstesting (ein Modell vor dem Deployment bewusst mit unüblichen, Randfall- oder adversarialen Inputs zu füttern) genauso wichtig wie Genauigkeitstests auf einem saubereren Holdout-Set.

3. Black Boxes: niemand kann die Entscheidung erklären

Opazität (das „Black Box“-Problem) liegt vor, wenn die interne Logik eines Modells für die Menschen, die auf sein Ergebnis reagieren, es anfechten oder auditieren müssen, nicht interpretierbar ist.

Das ist nicht nur eine technische Unannehmlichkeit. Im öffentlichen Sektor ist es eine rechtliche und verfassungsrechtliche Frage. Das US-Verwaltungsrecht verlangt von Behörden grundsätzlich, Antragstellern eine Begründung für ablehnende Entscheidungen zu geben (eine Frage des Due Process). Die Hochrisiko-Bestimmungen des EU AI Act verlangen Dokumentation und menschliche Aufsicht in einem Umfang, der eine substanzielle Prüfung erlaubt. Ein Modell, das „abgelehnt“ ausgibt, ohne nachvollziehbare Begründung, erfüllt diesen Standard unabhängig von seiner Genauigkeit nicht.

Komplexe Modelle (Deep Neural Networks, Ensemble-Methoden wie Gradient-Boosted Trees) sind tendenziell genauer, aber weniger interpretierbar als einfachere (logistische Regression, Entscheidungsbäume). Behörden wägen ständig Genauigkeit gegen Erklärbarkeit ab und müssen diesen Trade-off zunehmend explizit dokumentieren, etwa unter den Transparenzanforderungen aus Artikel 13 des EU AI Act.

Tools wie SHAP (SHapley Additive exPlanations) versuchen anzunähern, warum ein Black-Box-Modell eine bestimmte Vorhersage getroffen hat, aber eine Annäherung ist nicht dasselbe wie die Grundwahrheit, und Behörden sollten diese Tools als Hilfsmittel für die Prüfung behandeln, nicht als Beweis für Fairness oder Korrektheit.

Guardrails vor dem Deployment

Eine praktische Checkliste vor dem Deployment für KI im öffentlichen Sektor, auf Basis des NIST AI RMF und der Hochrisiko-Pflichten des EU AI Act:

• Baseline-Monitoring-Plan: Legen Sie fest, welche Metriken nach dem Start verfolgt werden (Genauigkeit, False-Positive-/False-Negative-Raten nach Subgruppe, Input-Verteilungen) und in welchem Rhythmus, und zwar vor dem Go-live, nicht nach den ersten Beschwerden.
• Drift-Trigger an Politikkalender gekoppelt: Ändern sich die Anspruchsregeln, ist das ein automatischer Auslöser für Retraining oder Revalidierung, keine „irgendwann mal“-Aufgabe.
• Stresstest-Set: Bauen Sie ein absichtlich schräges Testset (Randfälle, seltene Haushaltstypen, unübliche Einkommensmuster), getrennt vom üblichen Genauigkeits-Holdout.
• Mindestniveau an Erklärbarkeit: Entscheiden Sie vor dem Deployment, welches Erklärungsniveau ein Sachbearbeiter oder Antragsteller braucht, und prüfen Sie, ob das gewählte Modell das liefern kann.
• Human-in-the-loop bei ablehnenden Entscheidungen: Hochriskante Feststellungen (Leistungsablehnung, Betrugsmarkierungen, Empfehlungen zur Strafzumessung) sollten in die menschliche Prüfung geroutet werden, nicht automatisch vollzogen. Das ist Risikokontrolle und unter dem EU AI Act häufig auch rechtliche Pflicht.
• Versionskontrolle und Audit Trail: Protokollieren Sie, welche Modellversion welche Entscheidung getroffen hat, damit ein driftbedingter Fehler in sechs Monaten auf den Zeitpunkt zurückverfolgt werden kann, an dem sich das Verhalten tatsächlich geändert hat.

Ein durchgerechnetes Beispiel

Nehmen wir an, das obige SNAP-Anspruchsmodell wurde zum Start mit 94 % Genauigkeit validiert (Schätzung, illustrativ). 18 Monate später zieht ein internes Audit eine Stichprobe von 500 aktuellen Entscheidungen und stellt fest, dass die Genauigkeit auf 81 % gefallen ist (illustrativ). Das sind 13 Prozentpunkte weniger. Bearbeitet die Behörde etwa 10.000 Anträge pro Jahr, bedeutet diese Lücke, dass jetzt über 1.000 zusätzliche Anträge pro Jahr ein falsches Anspruchssignal erhalten, bevor ein Mensch eingreift. Das sind die konkreten Kosten eines ausgelassenen Drift-Checks: keine Hypothese, sondern eine Zahl in Fallzahlgröße an jährlich betroffenen Menschen.

Kernpunkte

• Bias-Audits erkennen diskriminierendes Design; sie erkennen nicht Drift, Brittleness oder Opazität, die eigene, gleich ernste Risikokategorien sind.
• Drift (Data oder Concept) bedeutet, dass ein Modell stillschweigend veraltet, wenn sich Populationen oder Politikregeln ändern; Concept Drift ist im Behördenumfeld wegen häufiger gesetzlicher und regulatorischer Änderungen besonders verbreitet.
• Brittleness bedeutet, dass gute Durchschnittsgenauigkeit katastrophales Versagen bei Randfällen oder unterrepräsentierten Gruppen verdeckt; Stresstesting vor dem Deployment ist die Gegenmaßnahme.
• Opazität erzeugt juristische Exponierung (Due Process, Transparenzregeln des EU AI Act), unabhängig davon, ob das Modell genau ist; Behörden brauchen einen Erklärbarkeitsstandard, der vor dem Start festgelegt wird, nicht nach einer Beschwerde nachgerüstet.
• Behandeln Sie Modellrisiko als laufende Lebenszyklus-Pflicht (gemäß NIST AI RMF und den Hochrisikoregeln des EU AI Act), nicht als einmalige Zertifizierung: Monitoring-Pläne, Drift-Trigger und Audit Trails sind so wichtig wie die erste Validierung.