Post-Market-Risikofeedback für Hochrisiko-KI: Vom Schadenssignal zur kontrollierten Änderung

Kernaussage: Post-Market-Monitoring scheitert in der Praxis nicht an fehlenden Dashboards, sondern daran, dass niemand den Weg vom Schadenssignal zur validierten, umkehrbaren Änderung definiert hat. Eine Latenzkurve sagt Ihnen nicht, ob eine Modellregression, ein neu aufgebauter Retrieval-Index, eine Prompt-Änderung, eine Richtlinienanpassung oder ein überlasteter Prüfer das Ergebnis verursacht hat. Bauen Sie die Schleife als technisches System: mit Signaltaxonomie, benanntem Triage-Verantwortlichen, Zuordnung zu einem konkreten Release-Artefakt und einem Freigabekriterium, das vor dem Ausrollen der Korrektur erfüllt sein muss.

Der EU AI Act verankert diese Pflicht in Artikel 72: Anbieter müssen ein dokumentiertes Post-Market-Monitoring-System einrichten, das Leistungsdaten über die gesamte Lebensdauer „aktiv und systematisch“ erhebt und auswertet — auf Basis eines Monitoring-Plans, der Teil der technischen Dokumentation nach Anhang IV ist. Betreiber tragen nach Artikel 26 Absatz 5 die betriebliche Pflicht, den Betrieb zu überwachen und den Anbieter zu informieren. Artikel 73 setzt anschließend harte Meldefristen, sobald ein schwerwiegender Vorfall festgestellt ist. Keine dieser Vorschriften beschreibt, wie die Maschinerie zu bauen ist. Genau dieses Engineering-Problem behandelt dieser Beitrag.

Was sich am Zeitplan geändert hat — und warum das keine Atempause ist

Die Verordnung (EU) 2026/1744, der Digital Omnibus on AI, wurde am 8. Juli 2026 verabschiedet und am 24. Juli 2026 im Amtsblatt veröffentlicht. Sie ändert Artikel 113 des AI Act: Kapitel III Abschnitte 1 bis 3 — die zentralen Hochrisiko-Pflichten — gelten nun ab dem 2. Dezember 2027 für eigenständige Systeme nach Anhang III und ab dem 2. August 2028 für KI in regulierten Produkten nach Anhang I. Dieselbe Verordnung ersetzt Artikel 72 Absatz 3: Statt eines verbindlichen Durchführungsrechtsakts mit Pflichtvorlage bis zum 2. Februar 2026 muss die Kommission nun bis zum 2. September 2027 eine Leitlinie einschließlich Vorlage zum Post-Market-Monitoring-Plan verabschieden.

Daraus folgen zwei Dinge. Erstens: Die materielle Pflicht, ein Monitoring-System zu betreiben und zu dokumentieren, hat sich nicht geändert — verschoben wurden lediglich der Anwendungszeitpunkt und die Formatvorgabe. Zweitens, und für die technische Planung wichtiger: Die Verschiebung verlegt die Frist hinter den Zeitpunkt, zu dem die meisten Organisationen die betreffenden Systeme bereits produktiv betreiben. Sie können die Rückkopplungsschleife nicht rückwirkend über zwei Jahre Produktivverkehr entwerfen, der nie instrumentiert wurde. Die Signalerfassung ist der Teil mit der langen Vorlaufzeit.

Rechtsfrage für die Rechtsberatung: ob Ihr konkretes System ein Hochrisiko-KI-System nach Anhang I oder Anhang III ist, ob Sie als Anbieter oder Betreiber handeln, welcher Anwendungszeitpunkt für Sie gilt und ob sektorale Post-Market-Rahmenwerke (Medizinprodukte, Maschinen, Finanzdienstleistungen) Teile der Pflicht bereits abdecken. Das sind Einstufungs- und Rollenfragen, die von Produkt, Verträgen und Branche abhängen. Lassen Sie sie von qualifizierten Jurist:innen klären.

Technische Empfehlung: Bauen Sie die geschlossene Rückkopplungsschleife unabhängig von der Einstufung jetzt. Jede der folgenden Maßnahmen ist belastbares Betriebs-Engineering, das Vorfallkosten senkt — und jede braucht Monate, um sauber instrumentiert zu werden.

Warum Betriebs-Dashboards kein Risiko-Feedback-System sind

Ein typischer Observability-Stack erfasst Latenzperzentile, Tokenkosten, Fehlerraten und vielleicht ein Daumen-hoch/Daumen-runter-Signal. Das sind Systemgesundheitsmetriken. Ein Risikosignal unterscheidet sich davon in drei Punkten:

• Es betrifft das Ergebnis, nicht den Durchsatz. „Die Extraktion war nach 240 ms erfolgreich“ und „die extrahierte Gegenpartei war falsch und eine Zahlung wurde freigegeben“ liegen in unterschiedlichen Beobachtungsebenen. Gesundheitsmetriken tragen das fachliche Ergebnis selten mit.
• Es kommt außerhalb des Systems an. Schadenssignale entstehen bei Beschwerdestellen, im Betriebsrat, in Eskalationen von Führungskräften, in nachgelagerten Korrekturtickets, bei der Revision und im Kundenservice — nicht in Ihrem Inference-Gateway. Wenn Ihre Schleife nur Telemetrie aufnimmt, sind Sie für die schwerwiegendste Signalklasse strukturell blind.
• Es braucht Zuordnung, nicht Korrelation. Eine steigende Übersteuerungsquote ist erst handlungsleitend, wenn Sie wissen, ob sich im selben Zeitfenster die Modellversion, der Retrieval-Index, der System-Prompt, ein vorgelagertes Datenschema, eine Richtlinie oder die Prüferbesetzung geändert hat. Ohne eine Release-Kennung an jeder Entscheidung wird aus Zuordnung eine Diskussion.

Eine Signaltaxonomie, die tatsächlich weiterleitet

Klassifizieren Sie Signale nach Quelle und Beweiskraft und hängen Sie an jede Klasse einen festen Triage-Verantwortlichen und eine Frist. Zweck der Taxonomie ist die Weiterleitung, nicht die Dokumentation.

Nur Klasse F trägt eine gesetzliche Frist — und die ist unnachgiebig. Nach Artikel 73 melden Anbieter einen schwerwiegenden Vorfall der Marktaufsichtsbehörde des Mitgliedstaats, in dem er eingetreten ist, unmittelbar nach Feststellung eines ursächlichen Zusammenhangs oder seiner hinreichenden Wahrscheinlichkeit, spätestens jedoch 15 Tage nach Kenntniserlangung. Bei einer weitreichenden Verletzung oder einem Vorfall nach Artikel 3 Nummer 49 Buchstabe b verkürzt sich die Frist auf zwei Tage, beim Tod einer Person auf zehn Tage. Artikel 73 Absatz 5 erlaubt ausdrücklich einen unvollständigen Erstbericht mit nachfolgendem vollständigen Bericht. Nutzen Sie das prozessual — auf die vollständige Ursachenanalyse zu warten, ist der häufigste Grund für versäumte Fristen.

Eine weitere Vorgabe aus Artikel 73 Absatz 6 hat unmittelbare technische Folgen: Nach der Meldung muss der Anbieter untersuchen und darf das KI-System nicht so verändern, dass eine spätere Bewertung der Ursachen beeinträchtigt wird, bevor die Behörden informiert sind. Praktisch heißt das: Ihre Rollback-Werkzeuge müssen eindämmen können, ohne Beweise zu zerstören — Feature-Flag deaktivieren, Verkehr auf einen Fallback-Pfad leiten und den exakten Artefaktstand erhalten, statt den Prompt zu patchen und den reproduzierbaren Zustand zu verlieren.

Die geschlossene Schleife: vom Signal zur kontrollierten Änderung

Schritt 1: Erfassen — auch über Kanäle, die Ihnen nicht gehören

Die In-Band-Erfassung ist die einfachere Hälfte: Protokollieren Sie die Entscheidung, die Eingaben (oder deren Hashes, wo der Datenschutz das verlangt), die Kennungen des abgerufenen Kontexts, die Release-Kennung, das Konfidenz- oder Enthaltungssignal und die menschliche Handlung. Die Disziplin liegt darin, jeden Datensatz mit einer unveränderlichen Release-Kennung zu versehen, damit Zuordnung ein Join wird und keine Ermittlung.

An der Out-of-Band-Erfassung scheitern die meisten Programme. Beschwerdestellen, Betriebsrats-Eskalationen und Support-Tickets tragen die Signale der Klassen A und F — und liegen typischerweise in Systemen ohne Verbindung zu Ihrer KI-Plattform. Die minimale tragfähige Integration ist ein einziges Pflichtfeld — „War eine KI-gestützte Entscheidung beteiligt, und wenn ja: welche Vorgangskennung?“ — im Eingangsformular jedes Kanals, der eine Beschwerde über ein automatisiertes Ergebnis entgegennehmen kann. Ohne dieses Feld existiert das Signal, lässt sich aber keinem Release zuordnen.

Betreiber sollten die Aufbewahrungsuntergrenze aus Artikel 26 Absatz 6 beachten: Automatisch erzeugte Protokolle eines Hochrisiko-KI-Systems, soweit sie der Kontrolle des Betreibers unterliegen, sind für einen der Zweckbestimmung angemessenen Zeitraum aufzubewahren, mindestens jedoch sechs Monate, sofern nicht anderes Unions- oder nationales Recht — insbesondere das Datenschutzrecht — etwas anderes vorsieht. Sechs Monate sind eine Untergrenze, kein Ziel. Bei einem jährlichen Neubewertungszyklus ist die Hälfte Ihrer Nachweise verfallen, bevor Sie sie brauchen.

Schritt 2: Triage nach Schwere und Umkehrbarkeit, nicht nach Menge

Der übliche Fehler ist die Priorisierung nach Ticketzahl — damit werden seltene, schwerwiegende Ereignisse systematisch nach hinten geschoben. Priorisieren Sie stattdessen auf zwei Achsen: Schwere des möglichen Schadens und Umkehrbarkeit der getroffenen Entscheidung.

Zwei Betriebsregeln machen diese Tabelle wirksam. Erstens: Der Triage-Verantwortliche hat eine ständige Befugnis zur Eindämmung — Feature-Flag deaktivieren oder Human Review erzwingen — ohne Sitzung eines Änderungsgremiums. Eindämmung ist keine Änderung, sondern die Rückkehr in einen zuvor freigegebenen, konservativeren Zustand. Zweitens: Eindämmung und Untersuchung laufen parallel. Ihre Serialisierung macht aus einem Zwei-Stunden-Vorfall einen Zwei-Wochen-Vorfall.

Schritt 3: Zuordnung gegen das Release-Bundle

Zuordnung funktioniert nur, wenn ein einziges Artefakt die gesamte Entscheidungskonfiguration zu einem Zeitpunkt festhält. Das ist dasselbe Konstrukt wie im Beitrag LLM-Release-Bundle: Änderungen reproduzierbar und reversibel: ein unveränderliches Manifest über Modellversion und Gewichte, Quantisierungsvariante, System-Prompt und Template-Revision, Retrieval-Index-Snapshot und Embedding-Modell, Tool- und Funktionsschemata, Policy-/Guardrail-Version sowie den Hash der Evaluator-Suite. Ergänzen Sie eine Dimension, die reine MLOps-Manifeste meist auslassen: die Human-Oversight-Konfiguration — welche Prüferrollen berechtigt waren, welche Eskalationsschwelle galt und wie die Besetzung in diesem Zeitfenster aussah.

Damit wird Zuordnung zum mechanischen Diff. Erscheint am 12. August eine Übersteuerungsdrift der Klasse B, fragen Sie ab, welche der acht Dimensionen sich zwischen dem 5. und dem 12. August geändert hat. In realen Vorfällen ist es meist genau eine — und häufig nicht das Modell: Index-Neuaufbauten, vorgelagerte Schemaänderungen und Veränderungen der Prüferbesetzung sind in Ursachendaten deutlich überrepräsentiert gemessen an der Aufmerksamkeit, die Modellversionen erhalten.

Die datenseitige Zuordnung braucht eine eigene Lineage. Führt eine Segmentregression der Klasse C auf Trainings- oder Retrieval-Inhalte zurück, müssen Sie Quelldsätze, Transformationen und Kohortenabdeckung erreichen — die Struktur aus Daten-Governance für Hochrisiko-KI. Ohne Lineage bleibt als Korrektur nur ein vollständiges Retraining: langsam, teuer und nicht überprüfbar.

Schritt 4: den Korrekturpfad bewusst wählen

Nach der Zuordnung bestimmt der Korrekturpfad den Validierungsaufwand und den Rollback-Plan. Wer standardmäßig den billigsten Pfad wählt, sammelt Prompt-Patches an, die nach sechs Monaten niemand mehr nachvollziehen kann.

Die letzten beiden Zeilen überspringen Engineering-Teams gern. Artikel 26 Absatz 2 verlangt von Betreibern, die menschliche Aufsicht natürlichen Personen zu übertragen, die über die erforderliche Kompetenz, Ausbildung, Befugnis und Unterstützung verfügen. „Der Prüfer hat 400 Fälle pro Schicht freigegeben und irgendwann nicht mehr gelesen“ ist ein echter, behebbarer Defekt der Aufsichtskonfiguration — kein Schulungsproblem. Wie Kompetenz und Berechtigung technisch verknüpft werden, beschreibt rollenbasierte KI-Kompetenz als Zugriffskontrolle.

Schritt 5: gegen ein vorab registriertes Freigabekriterium validieren

Das wertvollste Artefakt dieser Schleife ist die Tabelle „Vorfall zu Freigabekriterium“. Jeder Vorfall, der zu einer Änderung führt, muss eine dauerhafte, automatisierte Prüfung im Release-Gate ergänzen. So wird aus punktueller Brandbekämpfung eine Ratsche: Das System kann nicht zweimal unbemerkt in denselben Fehler zurückfallen.

Zwei Konstruktionshinweise. Aggregierte Scores verbergen genau die Regressionen, um die es hier geht — das Kriterium muss je Segment ausgewertet werden (Sprache, Dokumentart, Kohorte, seltene Fallklasse); das ist die Argumentation aus Release-Gates für Modelländerungen im Unternehmen. Und die fixen Sets müssen tatsächlich eingefroren und zugriffsgeschützt sein; eine Suite, die in Trainingsdaten sickert, misst nichts mehr.

Schritt 6: Neu-Freigabe mit Safety-Case-Delta

Artikel 9 definiert das Risikomanagementsystem als „kontinuierlichen iterativen Prozess“ über den gesamten Lebenszyklus mit regelmäßiger systematischer Überprüfung und Aktualisierung; Artikel 9 Absatz 2 Buchstabe c verlangt ausdrücklich die Bewertung von Risiken, die aus Post-Market-Monitoring-Daten hervorgehen. Praktisch bedeutet das: Jede wesentliche Änderung erzeugt ein kurzes, strukturiertes Delta statt einer vollständigen Neufassung:

1. Welches Risiko im Register adressiert diese Änderung, und welcher Nachweis belegt die Minderung?
2. Welches neue Risiko hat die Änderung eingeführt (neues Werkzeug, breiterer Geltungsbereich, gelockerte Schwelle, entfallener Prüfschritt)?
3. Welches Freigabekriterium wurde ergänzt, und an welcher Stelle der Pipeline läuft es?
4. Was ist der Rollback-Auslöser, und wer darf ihn namentlich ziehen?
5. Müssen technische Dokumentation und Post-Market-Monitoring-Plan angepasst werden, und wer hat freigegeben?

Halten Sie es auf einer Seite und erzeugen Sie es soweit möglich aus dem Release-Bundle. Ein Delta, das einen Workshop erfordert, wird nicht geschrieben — und ein ungeschriebenes Delta bedeutet, dass die nächste Prüfung eine Versionshistorie ohne Begründung vorfindet.

Fehlermodi aus der Produktion

• Die nicht verknüpfte Beschwerde. Eine Beschwerde über ein automatisiertes Ergebnis wird vom Support kulant gelöst und nie mit einer Vorgangs- oder Release-Kennung verbunden. Das Muster bleibt unsichtbar, bis eine Behörde danach fragt. Abhilfe: Pflichtfeld zur KI-Beteiligung in jedem Eingangskanal.
• Stiller Index-Neuaufbau. Der Retrieval-Index wird nächtlich neu gebaut, außerhalb des Release-Prozesses. Die Qualität bewegt sich, die Modellversion blieb gleich, die Zuordnung stockt tagelang. Abhilfe: Index-Snapshots tragen Release-Kennungen und werden wie Modelländerungen freigegeben.
• Der heiß gepatchte Prompt. Jemand ändert den System-Prompt, um einen Vorfall zu stoppen. Das Verhalten ändert sich, die Beweislage für die Ursachenanalyse ist zerstört — und bei meldepflichtigen Vorfällen kollidiert das mit Artikel 73 Absatz 6. Abhilfe: Eindämmung nur über Flags und Routing; Inhaltsänderungen durchlaufen die Validierung.
• Alarmmüdigkeit als Risikokontrolle. Jede Anomalie erzeugt ein Ticket, die Warteschlange übersteigt die Triage-Kapazität, das Team schließt Tickets im Block. Schweresignale ertrinken in Mengensignalen. Abhilfe: Risikosignal-Pipeline und Health-Alert-Pipeline trennen — andere Verantwortliche, andere Warteschlangen.
• Umkehrbarkeit angenommen, nie geübt. Rollback existiert auf dem Papier. Niemand hat ihn gegen das aktuelle Indexformat, den aktuellen Adapter-Stack oder die aktuelle Policy-Version ausgeführt. Abhilfe: quartalsweise Rollback-Übung mit gemessener Wiederherstellungszeit, selbst als Freigabekriterium behandelt.
• Nachweise verfallen vor der Prüfung. Protokolle werden sechs Monate lang aufbewahrt, der Neubewertungszyklus ist jährlich — die Spur eines Januar-Vorfalls fehlt bei der Juli-Prüfung. Abhilfe: Aufbewahrung aus Neubewertungstakt und branchenspezifischen Verjährungsfristen ableiten und mit der datenschutzrechtlichen Datenminimierung abgleichen.

Was dieses System nicht löst

Eine geschlossene Risiko-Rückkopplungsschleife ist eine Betriebskontrolle, keine Korrektheitsgarantie. Sie erkennt keinen Schaden, der in keinem überwachten Kanal ein Signal erzeugt — stille Schäden, nicht gemeldete Diskriminierung und Auswirkungen auf Personen, die Ihren Beschwerdeprozess nie erreichen, bleiben strukturell unsichtbar. Genau deshalb ist die Grundrechte-Folgenabschätzung eine eigenständige Disziplin und kein Nebenprodukt des Monitorings.

Sie bestimmt weder Ihre rechtliche Einstufung noch Ihre Rolle als Anbieter oder Betreiber, noch ob ein Ereignis die Definition eines schwerwiegenden Vorfalls nach Artikel 3 Nummer 49 erfüllt. Diese Beurteilung ist zeitkritisch und rechtlich folgenreich; Aufgabe des technischen Systems ist es, Kandidaten schnell sichtbar zu machen und Beweise zu sichern — nicht, die Entscheidung zu treffen. Die Verbindung von Risikobefunden zu Kontrollen und Tests behandelt die gemeinsame FRIA-DPIA-Evidenzplattform.

Sie repariert auch kein System, das für seine Zweckbestimmung ungeeignet ist. Reicht die zugrunde liegende Leistungsfähigkeit für die Aufgabe nicht aus, dokumentiert eine schnelle Rückkopplungsschleife die Fehler lediglich präziser. Rücknahme und Umfangsreduktion müssen in der Korrekturpfad-Tabelle echte Optionen bleiben — sonst wird die Schleife zur Rechtfertigungsmaschine für ein System, das nicht laufen sollte.

Umsetzungsreihenfolge

1. Release-Kennung durchgängig instrumentieren. Ohne sie funktioniert nichts Nachgelagertes. In den meisten Stacks zwei bis vier Wochen.
2. Feld zur KI-Beteiligung in jedem Out-of-Band-Kanal ergänzen: Beschwerden, Support, Betriebsrats-Eskalation, Revisionsfeststellungen.
3. Die sechsteilige Signaltaxonomie mit benannten Verantwortlichen und Erstkontaktfristen schreiben. Dort veröffentlichen, wo diese Personen arbeiten.
4. Die Triage-Matrix aus Schwere und Umkehrbarkeit aufbauen und ständige Eindämmungsbefugnis erteilen. Mit einer Tabletop-Übung testen.
5. Die erste stratifizierte Evaluationssuite einfrieren und als blockierende Prüfung in das Promotion-Gate einbinden.
6. Die Tabelle „Vorfall zu Freigabekriterium“ mit den letzten drei rekonstruierbaren realen Vorfällen beginnen. Dieses Artefakt nutzen Prüfer und Entwickler gleichermaßen.
7. Eine Rollback-Übung durchführen und die gemessene Wiederherstellungszeit festhalten. Übersteigt sie Ihre Eindämmungsfrist, ist das Ihr nächstes Arbeitspaket.

Quellen

• Verordnung (EU) 2024/1689 (AI Act) — konsolidierte Fassung — Artikel 9, 20, 26, 72 und 73.
• Verordnung (EU) 2026/1744 (Digital Omnibus on AI) — ändert Artikel 72 Absatz 3 und die Anwendungszeitpunkte in Artikel 113.
• AI Act Service Desk der Europäischen Kommission — Artikel 72 — amtlicher Artikeltext und zugehörige Erwägungsgründe.
• Europäische Kommission — Regulierungsrahmen für KI — risikobasierte Struktur und Pflichtenüberblick.

Womit Sie beginnen

Wenn Sie ein Hochrisiko-KI-System betreiben oder vorbereiten, ist der wirksamste erste Schritt kein Governance-Workshop — sondern eine Release-Kennung an jeder Entscheidung und ein Feld zur KI-Beteiligung im Beschwerdeeingang. Diese beiden Änderungen machen alle späteren Kontrollen überhaupt möglich.

Wenn Sie die Schleife gegen Ihre tatsächliche Architektur prüfen lassen möchten: Ich führe eine fokussierte Post-Market-Feedback-Bewertung durch — Signaltaxonomie und Kanalabdeckung, Reife von Release-Bundle und Zuordnung, Triage-Befugnisse, Rollback-Übung und die Tabelle „Vorfall zu Freigabekriterium“. Ergebnis ist ein Umsetzungsplan mit benannten Verantwortlichen und messbaren Gates, kein Foliensatz.