EU AI Act: Beobachtung nach Inverkehrbringen auf Azure

Die prominenten Pflichten des EU AI Act — Konformitätsbewertung, technische Dokumentation, CE-Kennzeichnung — fallen vor dem Inverkehrbringen eines Hochrisikosystems an. Die Pflicht, die jedoch über die Lebensdauer hinweg den größten Aufwand verursacht, beginnt am Tag nach dem Go-live: die Beobachtung nach Inverkehrbringen. Ab dem 2. August 2026 müssen Anbieter von Hochrisiko-KI-Systemen nach Anhang III ein dokumentiertes Beobachtungssystem betreiben, Protokolle über die Lebensdauer führen und schwerwiegende Vorfälle innerhalb knapper gesetzlicher Fristen melden.

Das ist ein Betriebs-, kein Papierproblem. Im Folgenden beschreiben wir, wie wir bei CC Conceptualise die Beobachtung nach Inverkehrbringen für Hochrisiko-KI auf Azure aufbauen — was zu protokollieren ist, wie Drift erkannt wird und wie der Meldeprozess so verdrahtet wird, dass eine 15-Tage-Frist Sie nie unvorbereitet trifft.

Kurzfassung / Kernaussagen

Die Beobachtung nach Inverkehrbringen ist verpflichtend und kontinuierlich für Hochrisiko-KI nach Anhang III ab dem 2. August 2026 — ein dokumentiertes System, keine jährliche Prüfung.
Protokollierung über die Lebensdauer ist gesetzlich vorgeschrieben: Ereignisse müssen automatisch aufgezeichnet und aufbewahrt werden (in der Regel mindestens sechs Monate), um Rückverfolgbarkeit und Vorfalluntersuchung zu ermöglichen.
Schwerwiegende Vorfälle sind der Marktüberwachungsbehörde unverzüglich zu melden — spätestens nach 15 Tagen, 10 Tagen bei einem Todesfall und 2 Tagen bei weitverbreiteten Verstößen oder Störungen kritischer Infrastruktur.
Model Drift ist der stille Konformitätskiller: Sie untergräbt die bescheinigte Genauigkeit und Robustheit, weshalb ihre Erkennung faktisch verpflichtend ist.
Azure liefert die Bausteine — Azure Monitor, Modell-Monitoring in Azure ML, AI-Foundry-Auswertungen, Purview — doch keiner ist standardmäßig konform; die eigentliche Arbeit ist die Konfiguration entlang der Verordnung.

Was die Verordnung nach dem Go-live tatsächlich verlangt

Drei Pflichten prägen die Phase nach Inverkehrbringen. Sie greifen ineinander, und sie isoliert zu behandeln ist der häufigste Fehler, den wir sehen.

Pflicht	Anforderung	Wichtigster Azure-Baustein
Beobachtung nach Inverkehrbringen (Art. 72)	Ein dokumentiertes, proaktives System, das Leistungsdaten über die Lebensdauer sammelt und auswertet, die fortlaufende Konformität prüft und das Risikomanagement speist	Azure ML Modell-Monitoring, AI-Foundry-Auswertungen, Azure Monitor
Automatische Protokollierung (Art. 12, 19)	Ereignisse werden automatisch über die Lebensdauer in zweckangemessenem Umfang aufgezeichnet; Protokolle unter Anbieterkontrolle, in der Regel ≥6 Monate	Azure Monitor, Log Analytics, unveränderlicher Speicher
Meldung schwerwiegender Vorfälle (Art. 73)	Meldung an die Marktüberwachungsbehörde bei kausalem Zusammenhang; gestaffelte Fristen bis hinab zu 2 Tagen	Vorfall-Workflow auf Basis von Azure-Monitor-Alarmen und einem nachverfolgten Reaktionsprozess

Das verbindende Element sind Ihr Risikomanagementsystem und Ihre technische Dokumentation. Die Beobachtungsergebnisse sind kein Selbstzweck — sie müssen in die Risikoakte zurückfließen, und wesentliche Änderungen können eine erneute Konformitätsbewertung auslösen. Wenn Sie noch klären, welche Ihrer Systeme unter dieses Regime fallen, beginnen Sie mit unserem Leitfaden zur Hochrisiko-Einstufung nach Anhang III, bevor Sie hier etwas aufbauen.

Protokollierung: das Fundament, auf dem alles andere ruht

Artikel 12 verlangt, dass Hochrisikosysteme Ereignisse über ihre Lebensdauer automatisch protokollieren. Die Verordnung ist bewusst zweckbezogen — sie liefert kein Schema —, daher müssen Sie aus den Risiken und der Zweckbestimmung Ihres Systems ableiten, was zu protokollieren ist. In der Praxis erfasst ein belastbares Hochrisiko-Protokoll:

Den Bezugszeitraum jeder Nutzung und die Eingabedaten (oder einen datenschutzwahrenden Verweis darauf).
Die System- und Modellversion hinter jeder Entscheidung, um exakt rekonstruieren zu können, was eine Ausgabe erzeugt hat.
Ausgabe, Konfidenz und jeden menschlichen Eingriff — wer wann eingegriffen und was geändert hat.
Betriebsereignisse — Ausfälle, Fallbacks, Content-Safety-Auslöser, Schwellenüberschreitungen.

Wie wir das auf Azure aufbauen

Anwendungs- und Inferenztelemetrie wird über Azure Monitor in einen dedizierten Log-Analytics-Arbeitsbereich geleitet, mit Diagnoseeinstellungen, die in unveränderlichen (WORM-)Blob-Speicher für den Aufbewahrungszeitraum exportieren. Zwei Punkte sind für die Konformität entscheidend und werden regelmäßig übersehen:

Manipulationssicherheit. Protokolle, die Konformität belegen, müssen selbst vertrauenswürdig sein. Setzen Sie Unveränderlichkeitsrichtlinien und strenge RBAC ein, damit die Betreiber des Modells dessen Historie nicht stillschweigend umschreiben können.
Aufbewahrung. Die Verordnung erwartet einen angemessenen Zeitraum, in der Regel mindestens sechs Monate, sofern nicht sektorspezifisches Recht (oder Ihr eigener Untersuchungsbedarf) eine längere Frist verlangt. Legen Sie dies ausdrücklich fest; übernehmen Sie nicht die Standard-Aufbewahrung von 30 Tagen und gehen Sie davon aus, abgesichert zu sein.

Ein Muster, das wir wiederholt einsetzen: eine am API-Gateway erzeugte Korrelations-ID, die durch jedes Protokoll gefädelt wird, sodass eine Untersuchung eines schwerwiegenden Vorfalls Inferenz-, Aufsichts- und Infrastrukturereignisse in Minuten statt Tagen zu einer Zeitleiste zusammenführt.

Drift: das Risiko, das die Verordnung nie benennt, aber stets meint

„Drift" kommt im AI Act nirgends vor. Dennoch machen die Anforderungen an Genauigkeit, Robustheit und fortlaufende Konformität die Drift-Erkennung faktisch verpflichtend. Ein Hochrisiko-Modell für Kreditentscheidungen oder Triage, das beim Inverkehrbringen konform war, kann sich still verschlechtern, während sich die Welt darunter verschiebt — und sobald seine reale Genauigkeit unter die in der technischen Dokumentation festgelegte Schwelle fällt, sind Sie nicht-konform, mit oder ohne Beobachtung.

Drei Arten sind instrumentierungswürdig:

Datendrift — die Eingabeverteilung entfernt sich von den Trainings-/Referenzdaten.
Vorhersage- (Konzept-)Drift — die Beziehung zwischen Eingaben und der korrekten Ausgabe verändert sich.
Datenqualitätsdrift — Nullwerte, Schemaänderungen oder vorgelagerte Pipeline-Fehler verfälschen die Eingaben.

Drift-Monitoring auf Azure ML

Das Modell-Monitoring von Azure Machine Learning berechnet Drift-, Datenqualitäts- und Vorhersagedrift-Signale gegenüber einer von Ihnen aus dem Produktions-Referenzdatensatz definierten Baseline. Die Erfassungsebene (Model Data Collector) erfasst Eingaben und Ausgaben bei der Inferenz; geplante Monitore berechnen Kennzahlen und lösen Alarme aus.

Signal	Was es erkennt	Empfohlene Aktionsschwelle
Datendrift	Verschiebung der Eingabeverteilung	Alarm bei abgestimmter statistischer Schwelle; untersuchen, bevor die Genauigkeitsgrenze erreicht wird
Vorhersagedrift	Ausgabeverteilung / Konzeptverschiebung	Alarm und Auslösen einer Genauigkeitsprüfung mit gelabelten Daten
Datenqualität	Nullwerte, Wertebereich, Schemabrüche	Harter Alarm; ggf. automatischer Fallback auf sicheren Standard
Ground-Truth-Genauigkeit	Tatsächliche Leistung vs. dokumentierte Schwelle	Die Konformitätslinie — eine Überschreitung bedeutet mögliche Nicht-Konformität

Die Konformitätsdisziplin, die die meisten Teams übersehen: Koppeln Sie Ihre Drift-Schwellen an die Kennzahlen Ihrer technischen Dokumentation, nicht an bequeme Standardwerte. Wenn Ihr Konformitätsnachweis 92 % Präzision behauptet, muss Ihr Monitoring alarmieren, bevor die Produktionspräzision sich dieser Grenze nähert — und der Alarm muss einen handlungsbefugten Menschen erreichen.

Drift und Protokollierung in die menschliche Aufsicht einbinden

Die menschliche Aufsicht nach Artikel 14 ist kein Häkchen, sondern der Akteur, den Ihr Monitoring befähigen muss. Ein Drift-Alarm, der in einem ungelesenen Kanal landet, ist ein Befund, für den Sie haftbar sind, auf den Sie aber nicht reagiert haben. Wir verbinden Schwellenüberschreitungen direkt mit einer Bereitschaft, die dokumentiert befugt ist, das System anzuhalten, zurückzurollen oder zu übersteuern — und protokollieren diese Eingriffe in dieselbe Spur zurück. Dieser geschlossene Regelkreis verwandelt Telemetrie in belastbare Governance. Den breiteren Maßnahmenkatalog, in dem dies eingebettet ist, beschreibt unser Leitfaden zur Konformitätsbewertung.

Loading diagram...

Meldung schwerwiegender Vorfälle: die Fristen kennen, bevor Sie sie brauchen

Artikel 73 ist der Punkt, an dem die Beobachtung nach Inverkehrbringen auf die Aufsichtsbehörde trifft. Ein schwerwiegender Vorfall führt unmittelbar oder mittelbar zum Tod oder zu schweren Gesundheitsschäden, zu einer schweren und irreversiblen Störung kritischer Infrastruktur, zu einer Verletzung von Grundrechtspflichten nach EU-Recht oder zu schweren Sach- oder Umweltschäden.

Sobald Sie einen kausalen (oder hinreichend wahrscheinlichen) Zusammenhang zwischen Ihrem System und dem Vorfall feststellen, läuft die Meldefrist:

Szenario	Frist nach Feststellung des Zusammenhangs
Allgemeiner schwerwiegender Vorfall	Unverzüglich, höchstens 15 Tage
Tod einer Person	Höchstens 10 Tage
Weitverbreiteter Verstoß oder schwere Störung kritischer Infrastruktur	Höchstens 2 Tage

Zwei Tage sind brutal knapp, wenn die Frage „Wer entscheidet, dass dies schwerwiegend ist?" erstmals während des Vorfalls diskutiert wird. Legen Sie vorab schriftlich fest:

Wer triagiert einen Alarm zu einem Vorfallkandidaten.
Wer die Bewertung des kausalen Zusammenhangs vornimmt und auf welcher Beweisgrundlage (hier zahlt sich Ihre Korrelations-ID-Protokollierung aus).
Wer befugt ist, bei der zuständigen Marktüberwachungsbehörde zu melden, und über welchen Weg.
Wie die Fristen von 2 / 10 / 15 Tagen nachverfolgt werden, damit die richtige Frist auf die richtige Vorfallklasse angewandt wird.

Wir behandeln dies als Runbook mit einer geprobten Tabletop-Übung, nicht als Richtlinien-PDF. Die Bußgelder machen die Dimension greifbar: Nicht-Konformität bei Hochrisiko kann 15 Mio. EUR oder 3 % des weltweiten Umsatzes erreichen, verbotene Praktiken 35 Mio. EUR oder 7 %.

Prüfbar machen: ISO/IEC 42001

All das ist innerhalb eines Managementsystems belastbarer. ISO/IEC 42001, die Norm für KI-Managementsysteme, liefert das Governance-Gerüst — Rollen, Beobachtungsprozesse, Vorfallbehandlung, kontinuierliche Verbesserung —, das sich sauber auf die Beobachtungs- und Risikomanagementpflichten der Verordnung abbilden lässt. Sie ersetzt die gesetzlichen Pflichten nicht, macht sie aber wiederholbar und prüfbereit und gibt Ihrer Geschäftsleitung und Ihrem CISO eine erkennbare Struktur statt einer improvisierten Tabelle.

Eine 6-Schritt-Einführungssequenz

Für Teams, die dies jetzt vor der Frist im August 2026 aufsetzen, empfehlen wir diese Reihenfolge:

Beobachtungssignale aus der Risikoakte ableiten — dokumentierte Schwellen in messbare Kennzahlen und Alarme übersetzen.
Lebensdauer-Protokollierung aktivieren — Azure Monitor + Log Analytics, unveränderliche Aufbewahrung ≥6 Monate, durchgängige Korrelations-IDs.
Drift- und Qualitätsmonitore bereitstellen — Azure ML Modell-Monitoring gegen eine Produktions-Baseline.
Alarme mit der menschlichen Aufsicht verbinden — befugte Bereitschaft, protokollierte Eingriffe.
Den Vorfallweg aufsetzen — Triage, Bewertung des kausalen Zusammenhangs und das Meld-Runbook für 2 / 10 / 15 Tage.
Den Regelkreis ins Risikomanagement schließen — Prüfung in festem Turnus, Aktualisierung der Dokumentation, Auslöser für Neubewertungen.

Wenn der August 2026 vor Ihnen liegt, ordnet unsere Readiness-Checkliste das weitere Programm um diesen Beobachtungskern herum.

FAQ

Was verlangt die Beobachtung nach Inverkehrbringen gemäß EU AI Act?

Anbieter von Hochrisiko-KI-Systemen müssen ein dokumentiertes, proaktives Beobachtungssystem betreiben, das Leistungsdaten über die gesamte Lebensdauer sammelt und auswertet. Es prüft die fortlaufende Konformität, deckt Drift und neue Risiken auf und speist die Erkenntnisse in das Risikomanagement zurück. Diese Pflichten gelten ab dem 2. August 2026 für Hochrisikosysteme nach Anhang III.

Welche Protokollierung schreibt der EU AI Act für Hochrisiko-KI vor?

Hochrisiko-KI-Systeme müssen Ereignisse über ihre Lebensdauer automatisch in einem dem Zweck angemessenen Umfang aufzeichnen (Protokolle). Die Protokolle müssen Rückverfolgbarkeit, Beobachtung nach Inverkehrbringen und die Untersuchung von Vorfällen ermöglichen. Anbieter müssen die Protokolle unter ihrer Kontrolle für einen angemessenen Zeitraum aufbewahren, in der Regel mindestens sechs Monate, sofern keine längere gesetzliche Frist gilt.

Wann und innerhalb welcher Frist muss ein schwerwiegender Vorfall gemeldet werden?

Ein schwerwiegender Vorfall führt zum Tod oder zu schweren Gesundheitsschäden, zu einer schweren und irreversiblen Störung kritischer Infrastruktur, zu einer Verletzung von Grundrechtspflichten oder zu schweren Sach- oder Umweltschäden. Anbieter melden der zuständigen Marktüberwachungsbehörde unverzüglich nach Feststellung eines kausalen Zusammenhangs, spätestens nach 15 Tagen; bei Todesfällen gelten 10 Tage und bei weitverbreiteten Verstößen oder Störungen kritischer Infrastruktur 2 Tage.

Welche Rolle spielt Model Drift für die Konformität nach dem AI Act?

Drift wird in der Verordnung nicht benannt, doch unerkannte Genauigkeits-, Daten- oder Konzeptdrift ist ein direkter Weg, die beim Inverkehrbringen bescheinigte Konformität zu verlieren. Die Beobachtung nach Inverkehrbringen sowie die Anforderungen an Genauigkeit, Robustheit und menschliche Aufsicht verpflichten faktisch dazu, Drift zu erkennen und zu reagieren, bevor Schaden oder Nicht-Konformität entsteht.

Welche Azure-Dienste unterstützen Beobachtung und Protokollierung nach dem AI Act?

Azure Monitor und Log Analytics übernehmen die Ereignisprotokollierung und Aufbewahrung; das Modell-Monitoring und die Datenerfassung in Azure Machine Learning decken Drift, Datenqualität und Leistungssignale ab; Azure AI Foundry liefert Auswertungs- und Content-Safety-Telemetrie. Microsoft Purview unterstützt Datenherkunft und Aufbewahrungsverwaltung. Keiner dieser Dienste ist von Haus aus konform — es sind Bausteine, die Sie an die Anforderungen der Verordnung anpassen müssen.

Hilft ISO/IEC 42001 bei der Beobachtung nach Inverkehrbringen?

Ja. ISO/IEC 42001, die Norm für KI-Managementsysteme, liefert das Governance-Gerüst — Rollen, Beobachtungsprozesse, kontinuierliche Verbesserung und Vorfallbehandlung — das sich sauber auf die Beobachtungs- und Risikomanagementpflichten der Verordnung abbilden lässt. Sie ersetzt die gesetzlichen Pflichten nicht, macht sie aber prüfbar und wiederholbar.

Die Beobachtung nach Inverkehrbringen ist der Punkt, an dem AI-Act-Konformität aufhört, ein Dokument zu sein, und zu einer Betriebsdisziplin wird. Wenn Sie die Architektur für Protokollierung, Drift und Vorfallmeldung eines Hochrisikosystems auf Azure entwerfen — oder unter Belastung prüfen —, unterstützt Sie unser Team für KI- und Datenplattform-Engineering dabei, sie auf einem prüfungssicheren Niveau aufzubauen.