Post-Market-Überwachung von KI: Wie Nutzungssignale in überprüfbare Kontrollen umgesetzt werden

Was die Post-Market-Überwachung verlangt

Die Post-Market-Überwachung ist das System, mit dem ein Anbieter relevante Informationen über die Leistung eines Hochrisiko-KI-Systems sammelt und auswertet, nachdem es in Verkehr gebracht oder in Betrieb genommen wurde. Ihr Zweck besteht nicht darin, um ihrer selbst willen möglichst viele Protokolle oder Daten anzuhäufen. Sie soll dem Anbieter vielmehr ermöglichen, zu prüfen, ob das System die einschlägigen Anforderungen weiterhin erfüllt und ob Probleme aufgetreten sind, die untersucht werden müssen oder Maßnahmen erfordern.

Artikel 72 der KI-Verordnung weist dem Anbieter die Verantwortung zu, ein solches System einzurichten und zu dokumentieren. Es muss in einem angemessenen Verhältnis zur Art der Technologie und zu den Risiken des Systems stehen. Außerdem muss der Anbieter einen Plan für die Post-Market-Überwachung als Teil der technischen Dokumentation vorhalten. In der Praxis erläutert der Plan, wie Daten erhoben und analysiert werden, welche Signale auf eine Abweichung hindeuten können und wie entschieden wird, ob ein Eingreifen erforderlich ist.

Die Verpflichtung betrifft Hochrisiko-KI-Systeme. Sie bedeutet weder, dass alle Anbieter jedes Produkt mit derselben Intensität überwachen müssen, noch, dass sie sämtliche verfügbaren Daten erfassen sollen. Die Verhältnismäßigkeit ist entscheidend: Datenquellen, Indikatoren und Überprüfungsintervalle sollten in einem nachvollziehbaren Verhältnis zum vorgesehenen Verwendungszweck, zum Einsatzkontext und zu den Risiken stehen, die das System verursachen kann.

Es ist hilfreich, zwei Ebenen auseinanderzuhalten. Die rechtliche Anforderung besteht darin, ein angemessenes, dokumentiertes System und einen entsprechenden Plan einzurichten. Die in diesem Leitfaden vorgeschlagenen Indikatoren, Schwellenwerte und Abläufe sind Gestaltungsmöglichkeiten, mit denen sich diese Verpflichtung praktisch umsetzen lässt. Sie bilden keine universell geltende, von der Verordnung vorgeschriebene Liste.

Was beobachtet werden sollte und woher die Daten kommen können

Die Verordnung sieht relevante Daten vor, die von Betreibern bereitgestellt werden, ebenso wie Daten aus anderen Quellen. Das lässt den Anbietern Spielraum, ein auf ihr Produkt zugeschnittenes System zu entwickeln. Es hebt jedoch weder die Notwendigkeit auf, die Relevanz einer Quelle zu begründen, noch die Frage, wie die daraus gewonnenen Informationen auszulegen sind. Die Daten sollten dazu beitragen, die Leistung des Systems während seiner Lebensdauer zu bewerten und Veränderungen zu erkennen, die sich auf die Einhaltung der Anforderungen oder auf die Risiken auswirken können.

Eine erste Bestandsaufnahme kann Betriebskennzahlen, anormale Ergebnisse, technische Störungen, Beschwerden, strukturiertes Nutzerfeedback, Supportanfragen und Änderungen der Nutzungsbedingungen umfassen. Je nach System kann es außerdem relevant sein, Veränderungen bei der Nutzerpopulation, den Eingabedaten oder den Abläufen zu beobachten, in die das System eingebunden ist. Nicht jedes dieser Signale ist in jedem Fall verpflichtend. Ob es nützlich ist, hängt vom Kontext und von dem Risiko ab, das überwacht werden soll.

Die Interaktion mit anderen KI-Systemen verdient Aufmerksamkeit, wenn sie für das Verständnis der Leistung oder der Risiken relevant ist. Ein System kann beispielsweise Ergebnisse eines anderen Systems erhalten oder seine Ausgaben in einen automatisierten Prozess einspeisen. In solchen Fällen können eine Änderung des verbundenen Systems, des Datenformats oder des Arbeitsablaufs das beobachtete Verhalten beeinflussen, ohne dass das überwachte Modell selbst verändert wurde. Der Plan sollte angeben, welche Abhängigkeiten relevant sind und wie Änderungen daran erkannt werden.

Die Zusammenarbeit mit dem Betreiber ist wichtig, weil der Anbieter möglicherweise nicht alle tatsächlichen Einsatzbedingungen unmittelbar beobachten kann. Eine operative Vereinbarung kann konkretisieren, welche Datenkategorien ausgetauscht werden, wer sie aufbereitet, in welchen Abständen und über welchen Kanal sie übermittelt werden und an wen dringende Signale zu richten sind. Das ist eine praktische Empfehlung: Die Verordnung macht diese konkrete Liste nicht zu einem Pflichtformular. Der Austausch sollte auf das beschränkt werden, was für den Überwachungszweck erforderlich ist, und die sonstigen geltenden Anforderungen beachten.

Einen umsetzbaren Plan gestalten

Ein operativer Plan beginnt mit dem vorgesehenen Verwendungszweck und den Risiken, die das System in diesem Kontext mit sich bringen kann. Darauf aufbauend legt er fest, welche Daten eine relevante Veränderung erkennen lassen könnten und welche Entscheidungen daraus folgen können. Eine Kennzahlentabelle ohne Verantwortliche, Prüfkriterien oder Handlungswege ist schwer nutzbar und macht nur unzureichend nachvollziehbar, wie mit einem Signal umgegangen wurde.

Es ist sinnvoll, unterschiedliche Zuständigkeiten festzulegen. Ein technisches Team kann die Datenqualität prüfen und das Systemverhalten analysieren; das Produktteam kann Änderungen an Funktionen oder Einsatzbedingungen bewerten; die Compliance-Funktion kann die einschlägigen Pflichten und die Dokumentation überprüfen; und eine klar benannte Person oder ein Team mit entsprechender Befugnis kann entscheiden, ob ein Fall eskaliert werden muss. In kleinen Organisationen kann eine Person mehrere Aufgaben übernehmen. Dennoch sollten Entscheidungen und ihre Begründungen eindeutig zuzuordnen sein.

Indikatoren sollten so formuliert sein, dass sie eine konsistente Überprüfung ermöglichen. Dazu können Fehlerraten, Nichtverfügbarkeit, Veränderungen in der Verteilung der Eingaben, Unterschiede zwischen für die Systembewertung relevanten Gruppen oder eine Zunahme von Ergebnissen gehören, die eine menschliche Prüfung erfordern. Ein Indikator ist nur dann nützlich, wenn festgelegt ist, wie er berechnet wird, welcher Zeitraum betrachtet wird und welche Einschränkungen er hat. Eine Kennzahl sollte nicht als abschließender Beweis dargestellt werden, wenn sie lediglich einen Anlass zur Untersuchung liefert.

Der Anbieter kann interne Alarmstufen festlegen. Eine Veränderung oberhalb eines vereinbarten Schwellenwerts könnte beispielsweise eine technische Prüfung auslösen. Tritt sie wiederholt auf oder zeigt sie sich in mehreren Einsatzkontexten, kann eine umfassendere Bewertung gerechtfertigt sein. Solche Schwellenwerte sind empfohlene Managementinstrumente und keine allgemein durch Artikel 72 festgelegten Werte. Sie sollten überprüft werden, wenn sich die Nutzung, die verfügbare Evidenz oder das Risikoprofil ändert.

Signale untersuchen und Entscheidungen dokumentieren

Ein Signal bedeutet nicht automatisch, dass ein Verstoß vorliegt. Es kann auf unvollständige Daten, eine Änderung im Prozess des Kunden, eine vorübergehende Störung oder eine tatsächliche Verschlechterung zurückzuführen sein. Bei der Untersuchung sollten diese Möglichkeiten voneinander unterschieden und die geprüften Informationen festgehalten werden. Betrifft das Signal mehrere Einsatzkontexte, sollte geprüft werden, ob eine gemeinsame Ursache vorliegt, etwa eine bestimmte Version, eine gemeinsam genutzte Abhängigkeit oder eine Veränderung der Eingabebedingungen.

Ein hilfreicher Entscheidungsvermerk enthält das Datum der Erkennung, die Quelle, das betroffene System und die betroffene Version, eine Beschreibung des Signals, die für die Bewertung verantwortliche Person, die geprüfte Evidenz, die Schlussfolgerung und die nächsten Schritte. Wird keine Maßnahme ergriffen, sollte der Vermerk erläutern, warum die verfügbaren Informationen ein Eingreifen nicht rechtfertigten und unter welchen Bedingungen der Fall erneut geprüft würde. Diese Detailtiefe ist eine gute Dokumentationspraxis, aber kein von der Verordnung vorgeschriebenes festes Format.

Welche Maßnahmen infrage kommen, hängt vom Befund ab. Dazu können die Behebung eines Fehlers, eine Aktualisierung der Anweisungen, eine Änderung der Integration, verstärkte menschliche Kontrollen, eine vorübergehende Beschränkung bestimmter Nutzungen oder eine umfassendere technische Prüfung gehören. Die Maßnahme sollte zum beobachteten Problem passen und dokumentiert werden. Wenn das Signal darauf hindeutet, dass das System einschlägige Anforderungen nicht mehr erfüllt oder bislang nicht berücksichtigte Risiken auftreten, muss der Anbieter den Befund mit seinen Bewertungs- und Risikomanagementprozessen verknüpfen, statt ihn als isolierte Supportanfrage zu behandeln.

Auch der Betreiber muss wissen, welche Informationen für eine angemessene Nutzung des Systems wichtig sind und wie relevante Probleme mitgeteilt werden können. Der Plan sollte daher einen Eskalationskanal und einen Mechanismus vorsehen, über den Informationen an den Anbieter zurückgemeldet werden. Bei Produkten mit mehreren Kunden verhindert ein einheitlicher Meldeweg, dass ähnliche Signale auf verschiedene Supportteams verteilt bleiben.

Überwachung, Risikomanagement, Folgenabschätzungen und Vorfälle

Die Post-Market-Überwachung ersetzt das Risikomanagement nicht. Das Risikomanagement ist ein umfassenderer Prozess zur Identifizierung, Analyse und Behandlung von Risiken, der das System begleiten sollte. Die Überwachung liefert Informationen aus dem tatsächlichen Betrieb und kann zeigen, dass eine frühere Annahme nicht mehr trägt, ein neues Risiko entstanden ist oder eine Kontrollmaßnahme nicht wie erwartet funktioniert. Der Plan sollte sicherstellen, dass solche Signale diejenigen erreichen, die bestehende Bewertungen und Maßnahmen überprüfen können.

Sie ist auch nicht mit einer Folgenabschätzung vor der Inbetriebnahme gleichzusetzen. Eine vorherige Folgenabschätzung prüft mögliche Auswirkungen in einem bestimmten Kontext und vor einer konkreten Nutzung, sofern sie einschlägig ist. Die Überwachung betrachtet Informationen während des gesamten Lebenszyklus des Systems und hilft, Veränderungen zu erkennen, die erst im tatsächlichen Einsatz sichtbar werden. Beides ergänzt sich: Eine Maßnahme allein belegt nicht, dass sich das System nach seiner Inbetriebnahme unverändert verhalten wird.

Die in Artikel 73 vorgesehene Meldung schwerwiegender Vorfälle hat einen anderen Auslöser und einen anderen Zweck: Sie betrifft Vorfälle, die nach den geltenden Regeln gemeldet werden müssen. Die Überwachung sollte dagegen systematisch funktionieren und nicht erst beginnen, wenn ein schwerwiegender Vorfall eingetreten ist. Ein Signal kann eine Untersuchung und vorbeugende Maßnahmen rechtfertigen, auch wenn die Schwelle für einen meldepflichtigen Vorfall noch nicht erreicht ist. Wird ein meldepflichtiger Vorfall festgestellt, ersetzt der Überwachungsprozess die vorgeschriebene Meldung nicht.

Um Verwechslungen zu vermeiden, können Organisationen die Prozesse miteinander verknüpfen, ohne sie zusammenzulegen: Ein und dasselbe Ereignis kann eine Überwachungsuntersuchung auslösen und unabhängig davon eine Prüfung der Meldepflicht. Aus den Aufzeichnungen sollte hervorgehen, welcher Weg geprüft wurde, wer die Entscheidung getroffen hat und welche Maßnahmen eingeleitet wurden. So wird weder ein frühes Signal unterschätzt noch jede geringfügige Abweichung automatisch als schwerwiegender Vorfall behandelt.

Sonderfälle und Zeitplan der Vorschriften

Artikel 72 enthält eine besondere Einschränkung für bestimmte Hochrisiko-KI-Systeme im Bereich der Strafverfolgung: Das Überwachungssystem erstreckt sich nicht auf sensible operative Daten, über die Strafverfolgungsbehörden verfügen. Diese Ausnahme ist eng begrenzt. Sie sollte weder als allgemeine Ausnahme von der Überwachung für jedes von einer Behörde eingesetzte System noch als Erlaubnis verstanden werden, andere relevante Signale außer Acht zu lassen, die nach den geltenden Regeln verarbeitet werden können.

Die Rechtsänderung von 2026 hat den Absatz zur Orientierung durch die Kommission geändert. Die Verordnung sieht vor, dass die Kommission bis zum 2. September 2027 Leitlinien und eine freiwillige Vorlage für den Plan zur Post-Market-Überwachung veröffentlicht. Die Vorlage sollte daher weder als bereits verfügbares Instrument noch als eigenständige verpflichtende Vorgabe beschrieben werden. Bis zu ihrer Veröffentlichung können Anbieter ihre Dokumentation anhand der geltenden rechtlichen Anforderungen und ihrer betrieblichen Erfordernisse strukturieren.

Auch der Zeitplan für die Anwendung auf Hochrisiko-KI-Systeme wurde geändert. Der konsolidierte Text sieht je nach Kategorie unterschiedliche Termine vor: Für Hochrisiko-KI-Systeme nach Anhang III beginnt die Anwendung der einschlägigen Pflichten am 2. Dezember 2027; für Hochrisiko-KI-Systeme, die unter die in Anhang I aufgeführte Harmonisierungsrechtsvorschriften fallen, beginnt sie am 2. August 2028. Die Einstufung und der maßgebliche Termin müssen für jedes System geprüft werden. Ein Datum sollte nicht ohne Weiteres auf alle KI-Produkte übertragen werden.

Diese Termine ändern nichts daran, dass es sinnvoll ist, den Überwachungskreislauf frühzeitig vorzubereiten. Die Einrichtung von Datenquellen, Austauschvereinbarungen und Zuständigkeiten erfordert oft eine Abstimmung zwischen Anbieter und Kunde. Die operative Vorbereitung darf jedoch nicht mit der Behauptung verwechselt werden, eine Verpflichtung gelte für ein bestimmtes System bereits vor dem jeweils maßgeblichen Termin.

Checkliste zur Überprüfung des Plans

Ob ein Plan praktisch funktioniert, zeigt sich nicht an seiner Länge. Entscheidend ist, ob sich damit nachvollziehen lässt, wie das System überwacht wird und was geschieht, wenn ein Signal auftritt. Die folgenden Fragen eignen sich für eine interne Prüfung. Sie ersetzen weder die rechtliche Analyse des Systems noch seine Einstufung oder die Prüfung seiner besonderen Pflichten.

Ein belastbarer Plan benennt das System und seine relevanten Nutzungen, erläutert die verwendeten Informationsquellen und begründet ihre Auswahl, weist Zuständigkeiten zu und legt einen Analyseablauf fest. Außerdem beschreibt er, wie Signale zwischen Anbieter und Betreiber mitgeteilt werden, wie Entscheidungen dokumentiert werden und wie Erkenntnisse mit einer Risikoprüfung oder einer Korrekturmaßnahme verknüpft sind.

Bei der Überprüfung sollte auch geprüft werden, ob die Kennzahlen verständlich sind, ob Warnmeldungen konkrete Maßnahmen auslösen und ob das Team Datenanomalien von einer tatsächlichen Verschlechterung des Systems unterscheiden kann. Können eine neue Version, eine neue Integration oder eine veränderte Nutzungssituation die Leistung beeinflussen, sollte der Plan erläutern, wie eine solche Änderung erkannt und die Überwachung daraufhin überprüft wird.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.