Model Drift: Wenn ein KI-System nicht mehr genau dem Business Case entspricht

Veröffentlicht: 10.04.2026

Artikelserie: Limiten der Delegation an KI-Systeme (Teil 3)

Die bisherigen Artikel dieser Serie haben zwei Grenzen der Delegation an KI-Systeme aufgezeigt: Der Verwaltungsrat kann den Delegationsgegenstand bei lernenden Systemen nicht vollständig kennen (Verantwortlichkeitslücke: Teil 1), und er kann die Ausführung nur indirekt überprüfen (Überwachungsparadoxie: Teil 2). Beide Artikel betrachteten das System zum Zeitpunkt seiner Inbetriebnahme.

Teil 3 dieser Artikelserie stellt eine andere Frage: Was passiert, wenn sich das System nach der Genehmigung verändert, ohne dass jemand eine bewusste Entscheidung dazu trifft?

Viele Verwaltungsräte diskutieren eine KI-Implementation wie ein Projekt, und dieses endet i. d. R. bei der Abnahme. Genehmigt. Implementiert. Erledigt. Das ist bei KI-Systemen ein Fehler, denn ein System kann sich «verändern», ohne dass jemand es ändert. Kein neuer Code. Kein neues Training. Keine Meldung. Und trotzdem: andere Resultate.

Ein Vergleich macht die Problematik greifbar: Ein Finanzanalyst, dessen Marktmodelle auf Daten aus einer Niedrigzinsphase beruhen, liefert in einer Hochzinsphase weiterhin professionell aussehende Analysen. Aber seine Grundannahmen stimmen nicht mehr. Der Unterschied zum KI-System: Beim Analysten kann der Verwaltungsrat nachfragen, und der Analyst kann seine Annahmen offenlegen. Beim KI-Modell fehlt diese Befragbarkeit, wie der vorangehende Artikel zur Überwachungsparadoxie gezeigt hat.

Was Model Drift in der Praxis bedeutet

Ein Modell wird mit einer bestimmten Datenbasis trainiert und mit einem Leistungsprofil genehmigt: Fehlerquote, Einsatzbereich, Annahmen über Daten und Prozess.

Im Betrieb verschiebt sich die Realität:

Bei Data Drift verändern sich die Eingaben: Kundenverhalten, Marktbedingungen, Betrugsmuster, Lieferketten oder regulatorische Anforderungen entwickeln sich weiter.
Bei Concept Drift kippt die Beziehung zwischen Eingabe und Ergebnis: Ein Indikator, der gestern zuverlässig war, verliert seine Aussagekraft.

Das Modell bleibt gleich. Die Welt entwickelt sich weiter. Damit verschiebt sich die Qualität der Entscheidungen, oft langsam, aber stetig.

Das Governance-relevante Signal ist in beiden Fällen dasselbe: Performance Drift, die Abweichung vom genehmigten Leistungsprofil. Dieser Begriff gehört in jedes VR-Reporting, sollten KI-Systeme im Betrieb eingesetzt werden. Er gibt dem Verwaltungsrat eine einzige, klare Kategorie, die er einfordern und überwachen kann, unabhängig davon, ob die Ursache Data Drift oder Concept Drift ist.

Warum das ein Governance-Problem ist

Delegation setzt voraus, dass der Delegationsgegenstand definiert und in der Wirkung hinreichend stabil ist. Wenn der Verwaltungsrat ein KI-System genehmigt, genehmigt er faktisch einen konkreten Use Case, eine konkrete Datengrundlage und ein konkretes Leistungsprofil.

Model Drift bedeutet: Dieses Leistungsprofil verändert sich ohne neue VR-Entscheidung. Das ist wie eine schleichende Delegation, nicht autorisiert und oft unbemerkt.

Der Rechtsrahmen zeigt die Richtung, aber er liefert keine Schwelle. Das Obligationenrecht operiert in der Praxis mit einem definierbaren Delegationsgegenstand. Art. 14 EU AI Act verlangt, dass Hochrisiko-Systeme «während der Dauer ihrer Verwendung» wirksam von natürlichen Personen beaufsichtigt werden können. Beide Normen adressieren Model Drift nicht ausdrücklich, aber beide implizieren, dass Aufsicht nicht mit der erstmaligen Genehmigung endet. Die Lücke: Kein bestehender Rechtsrahmen definiert, ab wann eine Abweichung vom genehmigten Leistungsprofil eine erneute Prüfung und Neugenehmigung auslöst. Diese Schwelle muss der Verwaltungsrat selbst festlegen und überwachen.

Floridi (2021) nennt als Bedingung menschlicher Kontrolle eine «Meta-Autonomie»: Delegation muss übersteuerbar bleiben, also «deciding to decide again». Das ist mehr als ein Zitat. Es ist eine Governance-Anforderung: Der Verwaltungsrat braucht Mechanismen, die ihn rechtzeitig darauf aufmerksam machen, dass es etwas zu entscheiden gibt. Ohne solche Mechanismen wird die Rücknahmehoheit zur Fiktion.

Warum Drift meist unsichtbar bleibt

Model Drift ist weder ein Ausfall noch ein Systemfehler. Das System liefert weiter Resultate. Professionell. Plausibel. Und genau das ist die Gefahr.

Ein Mensch kann befragt werden: «Auf welcher Annahme basiert das?» Ein Modell ist oft nicht in diesem Sinn befragbar, und die Qualitätsverschiebung zeigt sich nur, wenn man sie systematisch misst.

Bei lernenden Systemen hat Matthias (2004) die Verantwortungslücke beschrieben, die entsteht, wenn das Systemverhalten nicht mehr vorhersagbar ist. Model Drift erzeugt ein verwandtes Problem bei statischen Modellen: Die Vorhersagbarkeit erodiert nicht durch Lernen. Sie erodiert durch eine sich verändernde Umgebung. Das System ist oft nicht hinreichend überprüfbar, und es verändert sich still. Der Verwaltungsrat kann weder zuverlässig sehen, was das System tut, noch erkennen, dass es sich in seiner Wirkung verschiebt.

Was der Verwaltungsrat konkret festlegen muss

Nicht jedes KI-System braucht dieselbe Governance-Tiefe. Entscheidend ist aus Verwaltungsratssicht die Materialität: Einfluss auf geschäftskritische Entscheide/Prozesse, potenzieller Schaden (rechtlich, finanziell, Reputation) und Skalierung. Entsprechend sind die folgenden Massnahmen proportional auszugestalten, eng geführt bei materialitätskritischen Anwendungen, schlanker bei weniger kritischen.

Genehmigung als bedingten Auftrag gestalten: Bei KI-Implementationen gehören auf Stufe Verwaltungsrat Bedingungen, die eine Neubewertung auslösen: Schwellen für Performance Drift (Abweichung zentraler Performance-Metriken wie Fehlerquoten, Recall/Precision, False Positives/Negatives), Indikatoren in den Eingabedaten, wesentliche Änderungen im Prozessumfeld oder im relevanten Rechts- und Regulierungsrahmen sowie neue Nutzergruppen oder Risikoklassen. Die Genehmigung ist damit kein einmaliger Akt, sondern ein Auftrag mit Grenzen und Triggern.
Stufengerechtes Monitoring als Governance-Pflicht verankern: Nicht «wir überwachen», sondern: welche Kennzahlen, welche Frequenz, welche Schwellen, wer eskaliert. Für materialitätskritische Systeme gehört dazu ein kurzes Standard-Reporting (Trend, Abweichung, Massnahme, Entscheidungsbedarf). Entscheidend ist zudem ein klarer Owner für das Drift-Monitoring. Ohne Owner bleibt Monitoring eine technische Übung ohne Governance-Wirkung.
Periodische Revalidierung einführen: Neben laufendem Monitoring braucht es regelmässige Revalidierung, ob System, Use Case, Datengrundlage und Leistungsprofil weiterhin dem genehmigten Rahmen entsprechen. Die Frequenz ist risikobasiert festzulegen. Wo wesentliche Abweichungen vorliegen, braucht es eine dokumentierte Neubewertung und, falls nötig, Neugenehmigung.
Rücknahme der Delegation operationalisieren: Läuft ein System ausserhalb des genehmigten Leistungsprofils oder kippt die Risikolage, braucht es einen definierten Prozess für abgestufte Eingriffe: Einschränkung des Use Case, Umstellung auf verstärkte menschliche Kontrolle oder Deaktivierung mit Rollback. Klare Entscheidungskompetenzen und Reaktionszeiten sind Teil davon, sonst bleibt die Rücknahme nur auf dem Papier möglich.

Erfolgreiche Implementierung ist kein Endpunkt

Die Sorgfaltspflicht endet bei KI nicht mit der Genehmigung und Implementierung des KI-Systems. Sie beginnt dort. Wer ein System genehmigt, aber nicht überprüft, ob es noch dem genehmigten Leistungsprofil entspricht, verliert die Kontrolle, ohne es zu merken.

Referenzen

Floridi, L. (2021). Ethics, Governance, and Policies in Artificial Intelligence. Springer.
Matthias, A. (2004). The Responsibility Gap: Ascribing Responsibility for the Actions of Learning Automata. Ethics and Information Technology, 6, 175–183.
Art. 716a, 716b, 717, 754 OR (Schweizerisches Obligationenrecht).
Art. 14 EU AI Act (Verordnung (EU) 2024/1689).