AI Act: Marktbeobachtung und Meldung von Vorfällen, der vollständige Leitfaden

Ihr KI-System auf den Markt zu bringen, ist nur die halbe Miete. Die Konformitätsbewertung zu bestehen und eine CE-Kennzeichnung anzubringen mag sich wie das Überqueren der Ziellinie anfühlen, aber nach dem EU AI Act (Verordnung (EU) 2024/1689) ist es in Wahrheit der Startpunkt für eine dauerhafte Reihe von Pflichten. Die Verordnung verlangt eine laufende Marktbeobachtung und die sofortige Meldung schwerwiegender Vorfälle, Pflichten, die niemals enden, solange das System im Einsatz ist. Ein Anbieter, der Compliance als einmaliges Ereignis behandelt, wird irgendwann mit einer Durchsetzungsmaßnahme, einem Reputationsschaden oder beidem konfrontiert.

Dieser Leitfaden behandelt die zwei miteinander verknüpften Säulen der laufenden Compliance: das System zur Marktbeobachtung nach Artikel 72 und die Meldung schwerwiegender Vorfälle nach Artikel 73. Wir gehen durch, was zu beobachten ist, wie Sie eine Beobachtungs-Infrastruktur aufbauen, wann und wie Sie Vorfälle melden und wer entlang der Kette von Anbieter und Betreiber wofür verantwortlich ist.

• Marktbeobachtung ist Pflicht für alle Anbieter von Hochrisiko-KI. Sie muss verhältnismäßig, aktiv und systematisch über den gesamten Lebenszyklus des KI-Systems erfolgen (Artikel 72).
• Das Beobachtungssystem muss als Teil Ihrer technischen Dokumentation dokumentiert und in Ihr Qualitätsmanagementsystem eingebunden sein.
• Sie müssen Leistung, Bias, Nutzungsmuster, Beschwerden und Protokolldaten verfolgen und nachweisen, dass Sie das tun.
• Schwerwiegende Vorfälle, also solche, die Tod, schweren Gesundheitsschaden, Störung kritischer Infrastruktur, Verletzung von Grundrechten oder schweren Sach- oder Umweltschaden verursachen, müssen der zuständigen Marktüberwachungsbehörde innerhalb strenger Fristen gemeldet werden (Artikel 73).
• Anbieter tragen die primäre Pflicht zur Beobachtung und Meldung. Betreiber müssen Protokolle aufbewahren, mit den Anbietern zusammenarbeiten und den Anbieter sofort informieren, sobald sie von einem schwerwiegenden Vorfall Kenntnis erlangen.
• Wer kein System zur Marktbeobachtung unterhält oder schwerwiegende Vorfälle nicht meldet, riskiert Bußgelder von bis zu 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes.
• Das Beobachtungssystem ist nicht optional, nicht bloß wünschenswert und kein "Nice-to-have". Es ist ab dem 2. August 2026 eine durchsetzbare gesetzliche Anforderung.

System zur Marktbeobachtung (Artikel 72)

Artikel 72 verpflichtet jeden Anbieter eines Hochrisiko-KI-Systems, ein System zur Marktbeobachtung einzurichten und zu dokumentieren. Das System muss der Art der KI-Technologie und den Risiken des Systems angemessen sein, und es muss relevante Daten, die von Betreibern bereitgestellt oder über andere Quellen erhoben werden, über die gesamte Lebensdauer des Systems sammeln, dokumentieren und analysieren.

Was "verhältnismäßig, aktiv und systematisch" bedeutet

• Verhältnismäßig bedeutet, dass Tiefe und Häufigkeit der Beobachtung zum Risikoniveau passen müssen. Ein Kredit-Scoring-System, das Millionen von Verbrauchern bedient, verlangt eine intensivere Beobachtung als ein begrenztes internes Pilotprojekt.
• Aktiv bedeutet, dass der Anbieter nicht einfach auf Beschwerden warten kann. Er muss proaktiv nach Hinweisen auf Verschlechterung, Missbrauch, Verschiebungen beim Bias und aufkommende Risiken suchen, über automatisierte Pipelines, Meldekanäle der Betreiber und unabhängige Audits.
• Systematisch bedeutet, dass die Beobachtung einem dokumentierten Plan mit definierten Metriken, Schwellenwerten, Frequenzen und Eskalationsverfahren folgen muss. Sporadische Stichproben erfüllen die Anforderung nicht.

Einbindung in den weiteren Compliance-Rahmen

Das System zur Marktbeobachtung existiert nicht isoliert. Es muss einspeisen in und schöpfen aus:

• Dem Risikomanagement-System (Artikel 9), die Beobachtungsdaten müssen genutzt werden, um die Risikobewertungen über den gesamten Lebenszyklus hinweg fortlaufend zu aktualisieren.
• Der technischen Dokumentation (Artikel 11), der Beobachtungsplan und seine Ergebnisse bilden einen verpflichtenden Abschnitt Ihrer Dokumentation nach Anhang IV.
• Dem Qualitätsmanagementsystem (Artikel 17), das QMS muss Verfahren für die Marktbeobachtung enthalten, und die Beobachtungsergebnisse müssen im QMS-Ablauf Korrekturmaßnahmen auslösen.
• Dem Protokollierungssystem (Artikel 12), die vom System automatisch erzeugten Protokolle liefern die Rohdaten, die die Beobachtungsprozesse auswerten.

Fehlt eines dieser Systeme oder ist es nicht verbunden, hat die gesamte Compliance-Architektur eine Lücke.

Was zu beobachten ist

Der AI Act schreibt keine starre Liste von Metriken vor, aber die Artikel 9, 12 und 72 machen zusammen mit dem Entwurf der Leitlinien der Kommission die Erwartungen deutlich. Nachfolgend ein praktischer Rahmen.

Leistungsbeobachtung (Genauigkeit, Drift, Verschlechterung)

Verfolgen Sie die zentrale Ausgabequalität Ihres KI-Systems laufend:

Legen Sie für jede Metrik Alarmschwellen fest. Wenn die Genauigkeit unter eine definierte Basislinie fällt oder die Drift einen statistischen Schwellenwert überschreitet (z. B. Population Stability Index > 0,2), sollte das Beobachtungssystem automatisch einen Untersuchungsablauf auslösen.

Bias-Beobachtung (Fairness-Metriken über die Zeit)

Bias-Tests sind keine einmalige Übung. Bevölkerungsverteilungen verschieben sich, gesellschaftliche Muster verändern sich, und Modelle, die bei der Bereitstellung fair waren, können im Betrieb unfair werden. Beobachten Sie:

• Demografische Parität, werden positive Ergebnisse anteilig über geschützte Gruppen verteilt?
• Ausgeglichene Quoten (Equalised Odds), sind die Raten für wahr positive und falsch positive Ergebnisse über die Gruppen hinweg konsistent?
• Prädiktive Parität, hält die Präzision des Systems über die Gruppen hinweg?
• Disparate-Impact-Verhältnis, erhält eine Gruppe günstige Ergebnisse mit einer Rate von weniger als 80 % der am stärksten begünstigten Gruppe?

Wo das System Daten zu geschützten Merkmalen (oder Stellvertretermerkmalen) verarbeitet, schlüsseln Sie alle Leistungsmetriken nach diesen Merkmalen auf. Dokumentieren Sie die Methodik und alle Einschränkungen (z. B. wenn geschützte Merkmale abgeleitet statt direkt beobachtet werden).

Nutzungsbeobachtung (Zweckbestimmung vs. tatsächliche Nutzung, Missbrauchserkennung)

Der AI Act knüpft Pflichten an die Zweckbestimmung des Systems, wie sie in der Betriebsanleitung des Anbieters festgelegt ist. Die Beobachtung muss erkennen, wenn die tatsächliche Nutzung über diese Zweckbestimmung hinausdriftet:

• Verfolgen Sie die Arten der eingereichten Eingaben. Reichen Nutzer Datenkategorien ein, für die das System nicht ausgelegt oder validiert wurde?
• Beobachten Sie die Einsatzkontexte. Wird ein für die Vorprüfung ausgelegtes System für die endgültige Entscheidungsfindung genutzt?
• Erkennen Sie feindliche Eingaben oder Versuche der Prompt-Injection.
• Kennzeichnen Sie Nutzungsvolumen oder Muster, die darauf hindeuten, dass das System in einem Umfang oder Bereich eingesetzt wird, der nicht von der Konformitätsbewertung abgedeckt ist.

Wird Missbrauch erkannt, muss der Anbieter feststellen, ob es sich um eine vernünftigerweise vorhersehbare Fehlanwendung handelt (die im Risikomanagement-System hätte behandelt werden müssen) oder um ein nicht vorhersehbares Szenario, das eine aktualisierte Risikodokumentation erfordert.

Feedback und Beschwerden

Richten Sie formelle Kanäle ein für:

• Feedback der Betreiber, strukturierte Mechanismen, mit denen Betreiber Probleme, unerwartetes Verhalten, Beinahe-Vorfälle und Nutzerbeschwerden melden können.
• Beschwerden betroffener Personen, über die betroffene Einzelpersonen Bedenken zu KI-gestützten Entscheidungen anzeigen können, die sie betreffen (besonders relevant für Systeme, die den Rechten auf Erläuterung nach Artikel 86 unterliegen).
• Internes Meldewesen, Verfahren, mit denen Beschäftigte und Auftragnehmer Bedenken eskalieren können.

Jede Beschwerde muss protokolliert, priorisiert, untersucht und, wo begründet, in das Risikomanagement-System zurückgespielt werden. Daten zu Beschwerdevolumen und -kategorie sollten Teil regelmäßiger Beobachtungsberichte sein.

Aufbewahrung von Protokollen (Artikel 12, automatische Protokollierung, mindestens 6 Monate Aufbewahrung für Betreiber)

Artikel 12 verlangt, dass Hochrisiko-KI-Systeme über automatische Protokollierungsfunktionen verfügen. Protokolle müssen Ereignisse erfassen, die für die Erkennung von Risiken, die Erleichterung der Marktbeobachtung und die Nachvollziehbarkeit relevant sind. Der Mindestinhalt der Protokolle umfasst:

• Den Zeitraum jeder Nutzung (Start- und Enddatum bzw. -uhrzeit).
• Die Referenzdatenbank, gegen die Eingabedaten geprüft wurden.
• Eingabedaten, bei denen die Suche zu einem Treffer führte.
• Die Identifizierung der natürlichen Personen, die an der Überprüfung der Ergebnisse beteiligt waren.

Betreiber müssen die vom Hochrisiko-KI-System automatisch erzeugten Protokolle für einen der Zweckbestimmung angemessenen Zeitraum aufbewahren, in jedem Fall aber mindestens sechs Monate, sofern im geltenden EU- oder nationalen Recht nichts anderes vorgesehen ist (Artikel 26).

Anbieter sollten ihre Protokollierungs-Infrastruktur so gestalten, dass es Betreibern leicht fällt, die Vorgaben einzuhalten, mit automatisiertem Protokoll-Export, manipulationssicherer Speicherung und Werkzeugen zur Verwaltung der Aufbewahrung.

Meldung schwerwiegender Vorfälle (Artikel 73)

Was als "schwerwiegender Vorfall" gilt

Artikel 73 verpflichtet Anbieter, jeden schwerwiegenden Vorfall den Marktüberwachungsbehörden des oder der Mitgliedstaaten zu melden, in denen der Vorfall aufgetreten ist. Der Begriff "schwerwiegender Vorfall" ist in Artikel 3(49) des AI Act definiert:

Ein schwerwiegender Vorfall ist ein Vorfall oder eine Fehlfunktion eines KI-Systems, der bzw. die direkt oder indirekt zu einem der folgenden Ergebnisse führt:

1. Tod oder schwerer Gesundheitsschaden, die Ausgabe oder das Versagen des Systems trägt zum Tod einer Person bei oder verursacht einen schweren Schaden für die Gesundheit einer Person. Dies umfasst sowohl körperlichen als auch psychischen Schaden.

2. Schwere und irreversible Störung kritischer Infrastruktur, das System verursacht die Störung der Verwaltung und des Betriebs kritischer Infrastruktur (Energie, Verkehr, Wasser, Bankwesen, digitale Infrastruktur, Gesundheitswesen usw.) auf schwere und irreversible Weise oder trägt dazu bei.

3. Verletzung von Grundrechten, die Ausgabe oder das Versagen des Systems führt zu einem Verstoß gegen Pflichten aus dem Unionsrecht, die dem Schutz der Grundrechte dienen, einschließlich Nichtdiskriminierung, Privatsphäre, Datenschutz, Meinungsfreiheit und dem Recht auf einen wirksamen Rechtsbehelf.

4. Schwerer Sach- oder Umweltschaden, das System verursacht weitreichenden Schaden an Sachwerten oder der Umwelt, der in Umfang und Auswirkung schwer ist.

Die Schlüsselformulierung lautet "direkt oder indirekt". Ein System, das eine Empfehlung liefert, auf die anschließend ein Mensch handelt und die zu einem Schaden führt, kann dennoch die Meldepflicht auslösen, wenn die Kausalkette hinreichend direkt ist.

Wer melden muss

Der Anbieter ist der primär Meldepflichtige. Die Pflicht hängt jedoch von der Kenntnis ab:

• Anbieter müssen der zuständigen Marktüberwachungsbehörde melden, nachdem sie Kenntnis davon erlangt haben, dass ein schwerwiegender Vorfall eingetreten ist.
• Betreiber müssen den Anbieter (und gegebenenfalls den Händler) sofort informieren, nachdem sie von einem schwerwiegenden Vorfall Kenntnis erlangt haben (Artikel 26). Kann der Betreiber den Anbieter nicht erreichen, oder in Fällen, in denen der Betreiber selbst Anbieterpflichten hat (z. B. nach Artikel 25), muss der Betreiber direkt an die Marktüberwachungsbehörde melden.

Der Entwurf der Leitlinien der Kommission

Im September 2025 veröffentlichte die Europäische Kommission den Entwurf ihrer Leitlinien zur Meldung schwerwiegender Vorfälle und lieferte damit eine entscheidende Klärung mehrerer unklarer Aspekte von Artikel 73.

Meldevorlage

Die Leitlinien enthalten eine standardisierte Meldevorlage, die in drei Teile gegliedert ist:

1. Erstmeldung, grundlegende Identifizierung des Systems, des Vorfalls und des unmittelbaren Schadens.
2. Zwischenbericht, aktualisierte Informationen im Verlauf der Untersuchung, einschließlich einer Ursachenanalyse.
3. Abschlussbericht, vollständige Erkenntnisse, ergriffene Korrekturmaßnahmen und Maßnahmen zur Verhinderung einer Wiederholung.

Anbieter sollten diese Vorlage jetzt in ihren Ablauf zum Vorfallmanagement einbinden, statt zu versuchen, sie unter dem Druck eines tatsächlichen Vorfalls zu übernehmen.

Klärung des "indirekten Kausalzusammenhangs"

Die Leitlinien stellen klar, dass "indirekt führt zu" Situationen abdeckt, in denen: die Ausgabe des KI-Systems ein wesentlicher Faktor in einer Ereigniskette war, die zum Schaden führte, selbst wenn ein Mensch eingegriffen hat; das System seine vorgesehene Funktion nicht erfüllt hat und dieses Versagen zum Schaden beigetragen hat; oder die kumulativen Auswirkungen des Systems über die Zeit zum Schaden geführt haben (z. B. systematischer Bias, der über eine Bevölkerung hinweg diskriminierende Ergebnisse verursacht). Die Leitlinien stellen ausdrücklich klar, dass menschliche Aufsicht die Kausalkette nicht automatisch unterbricht, wenn die Ausgabe des Systems dazu bestimmt war, die menschliche Entscheidung zu informieren, und der Mensch sich vernünftigerweise darauf verlassen hat, kann der indirekte Zusammenhang dennoch bestehen.

Beispiele aus den Leitlinien

Der Entwurf der Leitlinien der Kommission liefert anschauliche Beispiele:

• Eine medizinische Triage-KI, die einen Patienten fälschlicherweise als niedrig priorisiert einstuft und so zu einer verzögerten Diagnose beiträgt, die zu einer schweren Gesundheitsverschlechterung führt, das ist ein meldepflichtiger schwerwiegender Vorfall.
• Ein System für vorausschauende Polizeiarbeit, das das Risiko in Vierteln mit Minderheiten systematisch überschätzt und so zu unverhältnismäßiger Überwachung und einer Verletzung des Rechts auf Nichtdiskriminierung führt, meldepflichtig unter der Kategorie Grundrechte.
• Ein Teilsystem eines autonomen Fahrzeugs, das eine Gefahr auf der Straße falsch erkennt und so zu einer Kollision mit schwerer Verletzung beiträgt, meldepflichtig unter der Kategorie Gesundheit/Tod.
• Eine geringfügige Softwarestörung, die einen vorübergehenden Anzeigefehler in einem KI-gestützten Dashboard verursacht, ohne nachgelagerte Auswirkung auf Entscheidungen oder Sicherheit, nicht meldepflichtig als schwerwiegender Vorfall.

Meldefristen und -prozess

Der AI Act und die Leitlinien der Kommission legen einen strukturierten Meldeprozess mit definierten Fristen fest. Verzögerungen bei der Meldung sind selbst ein Compliance-Verstoß.

Schritt-für-Schritt-Prozess

Wichtige Details zu den Fristen

• 2-Tage-Frist bei Vorfällen mit Tod oder schwerem Gesundheitsschaden: Die Uhr beginnt zu laufen, sobald der Anbieter Kenntnis erlangt. "Kenntnis erlangen" schließt eine konstruktive Kenntnis ein, wenn der Anbieter aufgrund verfügbarer Informationen (z. B. Betreiberberichte, öffentliche Berichte) vernünftigerweise hätte Bescheid wissen müssen, läuft die Frist ab diesem Zeitpunkt.
• 10-Tage-Frist bei schwerer und irreversibler Störung kritischer Infrastruktur.
• 15-Tage-Frist für alle anderen schwerwiegenden Vorfälle (Grundrechtsverletzungen, Sach- oder Umweltschäden).
• Kann der Anbieter die Erstmeldung nicht innerhalb der Frist abschließen, muss er einen vorläufigen Bericht mit den verfügbaren Informationen einreichen und ihn ergänzen, sobald die Untersuchung fortschreitet.
• Berichte müssen bei der Marktüberwachungsbehörde jedes Mitgliedstaats eingereicht werden, in dem der Vorfall aufgetreten ist.

Was die Erstmeldung enthalten muss

Mindestens: die Identität des Anbieters; die Identifizierung des KI-Systems (Name, Version, Nummer des CE-Zertifikats, Registrierungsnummer in der EU-Datenbank); eine Beschreibung des Vorfalls und des verursachten Schadens; Datum und Ort; eine erste Einschätzung der Vorfallkategorie; alle sofort ergriffenen Korrekturmaßnahmen; und Kontaktdaten für Rückfragen.

Beobachtungspflichten von Anbieter und Betreiber

Zu verstehen, wer wofür verantwortlich ist, ist entscheidend, um Lücken und doppelte Arbeit zu vermeiden. Die folgende Tabelle vergleicht die Beobachtungs- und Meldepflichten von Anbietern und Betreibern für Hochrisiko-KI-Systeme.

Wichtige Betreiberpflichten im Detail

Betreiber sind keine passiven Empfänger. Nach Artikel 26 müssen Betreiber: das System gemäß der Betriebsanleitung des Anbieters nutzen; die menschliche Aufsicht kompetenten Personen zuweisen; den Betrieb des Systems in ihrem Einsatzkontext beobachten; Protokolle mindestens sechs Monate aufbewahren; betroffene Personen darüber informieren, dass sie einem Hochrisiko-KI-System unterliegen; den Anbieter über jeden schwerwiegenden Vorfall sofort informieren; und die Nutzung aussetzen, wenn sie der Ansicht sind, dass das System ein Risiko darstellt.

Ein Betreiber, der es versäumt, den Anbieter über einen schwerwiegenden Vorfall zu informieren, oder der ein System weiter nutzt, das er als nicht konform kennt, sieht sich Durchsetzungsmaßnahmen und Bußgeldern im eigenen Namen ausgesetzt.

Ein Beobachtungssystem in der Praxis aufbauen

Theorie ist wichtig, aber die Umsetzung ist das, was Aufsichtsbehörden prüfen werden. Nachfolgend eine praktische Architektur für ein System zur Marktbeobachtung.

Datenpipelines

Gestalten Sie automatisierte Datenpipelines, die laufend aufnehmen:

• Produktive Inferenzprotokolle, jede Vorhersage, Klassifizierung oder Empfehlung, mit Zeitstempeln, Eingabemetadaten, Konfidenzwerten und, wo verfügbar, Ground-Truth-Labeln.
• Feedback der Betreiber, strukturierte API- oder portalbasierte Kanäle für Leistungsbeobachtungen, Beschwerden und Anomalieberichte.
• Externe Daten, regulatorische Mitteilungen, akademische Forschung, Medienberichte und bei Datenschutzbehörden eingereichte Beschwerden.
• Trainingsdaten für erneutes Training, alle neuen Trainingsdaten, die durch Modell-Updates eingeführt werden, mit Herkunftsnachverfolgung.

Nutzen Sie eine ereignisgesteuerte Architektur, damit die Beobachtung bei sicherheitskritischen Systemen nahezu in Echtzeit erfolgt, statt sich auf wöchentliche Batch-Berichte zu verlassen.

Alarmschwellen

Definieren Sie quantitative Schwellenwerte, die eine automatische Eskalation auslösen:

Dashboard-KPIs

Bauen Sie ein Beobachtungs-Dashboard (intern oder für Betreiber zugänglich), das visualisiert:

• Gesamttrends bei Genauigkeit und Leistung (tägliche/wöchentliche gleitende Durchschnitte).
• Bias-Metriken nach geschützter Gruppe, mit Trendlinien und Alarmschwellen.
• Drift-Metriken (PSI, KL-Divergenz) bei Eingabe- und Ausgabeverteilungen.
• Beschwerdevolumen und -kategorisierung.
• Vollständigkeit der Protokolle und Einhaltung der Aufbewahrung.
• Anzahl und Status offener Vorfälle.
• Zeit bis zur Lösung früherer Vorfälle.

Eskalationsverfahren

Dokumentieren Sie eine klare Eskalationskette: Stufe 1 (Beobachtungsteam) priorisiert Alarme und untersucht Routineprobleme. Stufe 2 (Technische Leitung / Data Science) führt bei kritischen Alarmen die Ursachenanalyse durch. Stufe 3 (Compliance / Recht) bewertet, ob das Ereignis einen schwerwiegenden Vorfall nach Artikel 73 darstellt, und erstellt Berichte. Stufe 4 (Geschäftsführung / Vorstand) ist befugt, über Aussetzung, Rückruf oder Rücknahme des Systems zu entscheiden, und wird bei Ereignissen der Notfallstufe sofort unterrichtet.

Dokumentationsvorlagen

Halten Sie vorgefertigte Vorlagen bereit für:

• Monatlicher Beobachtungsbericht, mit einer Zusammenfassung von KPIs, Trends, ausgelösten Alarmen, durchgeführten Untersuchungen und Korrekturmaßnahmen.
• Formular zur Vorfallbewertung, ein strukturierter Fragebogen, um festzustellen, ob ein Ereignis die Schwelle von Artikel 3(49) erfüllt.
• Bericht nach Artikel 73, abgestimmt auf die standardisierte Vorlage der Kommission (Erst-, Zwischen- und Abschlussbericht).
• Nachweis der Korrekturmaßnahme, der die ergriffene Maßnahme, ihre Begründung, ihre Wirkung und den Nachweis dokumentiert, dass sie das Problem behoben hat.
• Aktualisierung des Risikomanagements, die Beobachtungsergebnisse mit dem Risikomanagement-System nach Artikel 9 verbindet und festhält, wie die Risikobewertung aktualisiert wurde.

Beobachtungsszenarien aus der Praxis

Szenario 1: Leistungsverschlechterung beim Kredit-Scoring

Beispiel aus der Praxis: Ein Fintech-Anbieter betreibt ein Hochrisiko-KI-System zum Kredit-Scoring (Anhang III, Nummer 5(a)), das von 30 europäischen Kreditgebern eingesetzt wird. Sechs Monate nach der Bereitstellung zeigt das Dashboard zur Marktbeobachtung, dass die Rate der fälschlichen Ablehnungen des Systems für Antragsteller einer bestimmten nationalen Herkunftsgruppe von 8 % auf 19 % gestiegen ist, während sie für andere Gruppen stabil bei 7 % bleibt. Das Disparate-Impact-Verhältnis ist unter 0,6 gefallen.

Was passieren sollte: Das automatische Alarmsystem löst einen kritischen Alarm aus. Die Untersuchung ergibt, dass eine makroökonomische Verschiebung die betreffende demografische Gruppe unverhältnismäßig getroffen hat, wodurch die Merkmale des Modells für diese Gruppe weniger aussagekräftig wurden. Der Anbieter stellt fest, dass dies eine mögliche Verletzung von Grundrechten (Nichtdiskriminierung) darstellt, und reicht innerhalb von 15 Tagen eine Erstmeldung eines schwerwiegenden Vorfalls ein. Die Korrekturmaßnahmen umfassen ein erneutes Training des Modells mit aktualisierten Daten, die Anpassung der Merkmalsgewichte und die Einführung einer vorläufigen manuellen Prüfung für betroffene Antragsteller. Alle 30 Betreiber werden benachrichtigt. Das Risikomanagement-System wird aktualisiert, um die makroökonomische Sensitivitätsanalyse als ständige Beobachtungsanforderung aufzunehmen.

Szenario 2: Fehldiagnose bei der medizinischen Diagnostik

Beispiel aus der Praxis: Ein Anbieter bietet ein KI-gestütztes Werkzeug zur Unterstützung der Radiologie an, das nach Anhang III, Nummer 5(a) (KI für die medizinische Diagnostik) als hochriskant eingestuft ist. Ein Krankenhaus als Betreiber meldet, dass das System versäumt hat, einen bösartigen Tumor auf einer Röntgenaufnahme des Brustkorbs zu kennzeichnen. Der Radiologe, der sich auf die Ausgabe "keine Befunde" der KI als Zweitmeinung verließ, erkannte den Tumor in seiner ersten Durchsicht nicht. Die Diagnose des Patienten verzögerte sich um vier Monate, was zu einem Fortschreiten der Krankheit führte, die eine aggressivere Behandlung erforderte.

Was passieren sollte: Der Betreiber informiert den Anbieter sofort, wie es Artikel 26 verlangt. Der Anbieter ordnet dies der Kategorie Tod/schwerer Gesundheitsschaden zu und reicht innerhalb von 2 Tagen eine Erstmeldung ein. Die Ursachenuntersuchung ergibt, dass der Tumor in einem Bildbereich lag, in dem das Modell eine bekannt geringere Sensitivität hatte, diese Einschränkung aber in der Betriebsanleitung unzureichend kommuniziert war. Korrekturmaßnahmen: Der Anbieter aktualisiert die Betriebsanleitung, trainiert das Modell mit zusätzlichen annotierten Daten neu und gibt eine Sicherheitsmitteilung an alle Betreiber-Krankenhäuser heraus. Die technische Dokumentation wird aktualisiert, und der Anbieter leitet eine umfassendere Überprüfung über alle Betreiberstandorte hinweg ein.

Szenario 3: HR-Screening-Tool wegen systematischem Bias markiert

Beispiel aus der Praxis: Ein multinationaler Konzern setzt ein KI-gestütztes Tool zum Screening von Lebensläufen ein (hochriskant nach Anhang III, Nummer 4(a), Einstellung und Auswahl von Bewerbern). Eine Mitarbeiterin der Personalabteilung bemerkt, dass das Tool weibliche Bewerberinnen für technische Rollen durchgängig niedriger einstuft. Die Mitarbeiterin reicht eine interne Beschwerde ein.

Was passieren sollte: Das Compliance-Team des Betreibers analysiert sechs Monate an Screening-Daten (aufbewahrt nach der Pflicht zur Protokollaufbewahrung) und bestätigt die Ungleichheit: Weibliche Bewerberinnen kommen mit 2,3-fach geringerer Wahrscheinlichkeit in die engere Auswahl als gleich qualifizierte männliche Bewerber. Der Betreiber informiert den Anbieter sofort und setzt die Nutzung für das Screening technischer Rollen aus. Die Ursachenanalyse ergibt, dass die Trainingsdaten zugunsten historisch männlich dominierter Teams verzerrt waren und über Merkmale wie den Namen der Universität einen Geschlechter-Stellvertreter einbetteten. Der Anbieter reicht innerhalb von 15 Tagen eine Meldung eines schwerwiegenden Vorfalls unter der Kategorie Grundrechte ein, trainiert das Modell mit entzerrten Daten neu, ergänzt ausdrückliche Fairness-Bedingungen und teilt allen Betreibern die Korrekturmaßnahmen mit.

Häufig gestellte Fragen

Gilt die Marktbeobachtung auch für KI-Systeme, die nicht hochriskant sind?

Die Pflichten aus Artikel 72 gelten speziell für Hochrisiko-KI-Systeme. Anbieter anderer Systeme sollten dennoch als gute Praxis beobachten, denn ein System kann neu eingestuft werden, wenn sich sein Nutzungskontext ändert. Anbieter von KI-Modellen mit allgemeinem Verwendungszweck mit systemischem Risiko haben zusätzliche Pflichten. Die EU-AI-Act-Compliance-Checkliste behandelt die Beobachtung über die Risikostufen hinweg.

Wie lange müssen wir Beobachtungsdaten und Protokolle aufbewahren?

Betreiber müssen Protokolle mindestens sechs Monate aufbewahren (Artikel 26). Anbieter müssen das Beobachtungssystem über die gesamte Lebensdauer des KI-Systems betreiben. In der Praxis bewahren Sie Beobachtungsdaten mindestens für den Zeitraum der möglichen Haftung auf, typischerweise mehrere Jahre. Branchenspezifische Regeln (Medizinprodukte, Finanzdienstleistungen) können längere Zeiträume vorschreiben.

Was passiert, wenn ein Betreiber einen Vorfall entdeckt, der Anbieter aber nicht erreichbar ist?

Kann der Betreiber den Anbieter nicht innerhalb einer angemessenen Frist erreichen, sollte der Betreiber direkt an die Marktüberwachungsbehörde des Mitgliedstaats melden, in dem der Vorfall aufgetreten ist. Der Betreiber sollte außerdem alle Versuche dokumentieren, den Anbieter zu kontaktieren. Nach Artikel 26 hat der Betreiber eine eigenständige Pflicht, die Nutzung auszusetzen, wenn er der Ansicht ist, dass das System ein Risiko darstellt, unabhängig davon, ob er mit dem Anbieter kommuniziert hat.

Kann ein Anbieter die Beobachtung an einen Betreiber oder Dritten delegieren?

Ein Anbieter kann vertraglich vereinbaren, dass Betreiber oder Drittdienstleister Daten sammeln, Dashboards betreiben oder Beobachtungstätigkeiten durchführen. Die gesetzliche Pflicht verbleibt jedoch beim Anbieter. Der Anbieter kann seine Verantwortung nicht wegdelegieren. Wenn der Dritte nicht angemessen beobachtet, haftet der Anbieter. Jede Delegation muss im Qualitätsmanagementsystem dokumentiert und in den vertraglichen Vereinbarungen mit den Betreibern abgebildet sein.

Ist jeder Bias-Befund ein "schwerwiegender Vorfall", der gemeldet werden muss?

Nein. Ein Bias-Befund ist nur dann ein schwerwiegender Vorfall, wenn er direkt oder indirekt zu einer Verletzung von Grundrechten führt, die schwer ist. Eine geringfügige statistische Abweichung, die erkannt, untersucht und korrigiert wird, bevor sie Schaden verursacht, ist kein meldepflichtiger schwerwiegender Vorfall, sollte aber intern dokumentiert und in das Risikomanagement-System eingespeist werden. Die Feststellung erfordert eine Einzelfallbewertung von Schwere, Umfang und Umkehrbarkeit des Schadens. Im Zweifel entscheiden Sie sich für die Meldung, eine Untermeldung birgt ein größeres regulatorisches Risiko als eine Übermeldung.

Wie greift der AI Act mit der Meldung von Datenschutzverletzungen nach DSGVO ineinander?

Die Meldung schwerwiegender Vorfälle nach dem AI Act ist getrennt von und zusätzlich zu der Meldung von Verletzungen des Schutzes personenbezogener Daten nach DSGVO (Artikel 33 DSGVO). Ein einzelnes Ereignis kann beides auslösen: eine Meldung an die Datenschutzbehörde nach DSGVO und an die Marktüberwachungsbehörde nach Artikel 73. Die Fristen unterscheiden sich (72 Stunden vs. 2 bis 15 Tage), die Behörden unterscheiden sich und die Vorlagen unterscheiden sich. Stellen Sie sicher, dass Ihr Notfallplan beides abdeckt. Mehr zur Überschneidung zwischen AI Act und DSGVO finden Sie in unserem ausführlichen Vergleich.

Nächste Schritte

Marktbeobachtung und Meldung von Vorfällen sind lebende Systeme, die sich weiterentwickeln müssen, während sich Ihr KI-System weiterentwickelt und im Betrieb neue Risiken entstehen. Prüfen Sie Ihre aktuellen Beobachtungsfähigkeiten anhand dieses Leitfadens, ermitteln Sie Lücken und schließen Sie sie vor der Durchsetzungsfrist am 2. August 2026.

Wenn Sie unsicher sind, ob Ihr KI-System als hochriskant gilt, beginnen Sie mit einer kostenlosen AI-Act-Bewertung zur Risikoeinstufung. Wenn ja, sind diese Pflichten der Preis dafür, im europäischen KI-Markt tätig zu sein.