Überwachung nach dem Inverkehrbringen: Praxisleitfaden für SaaS-Teams

Überwachung nach dem Inverkehrbringen bedeutet, das Verhalten eines KI-Systems nach der Veröffentlichung zu prüfen und anhand der Erkenntnisse seine Sicherheit und Konformität zu erhalten. Für SaaS-Teams beginnt dies mit einer benannten verantwortlichen Person, einem dokumentierten Überwachungsplan, verlässlichen Rückmeldungen aus der Praxis und einem Weg von jedem wesentlichen Befund zu einer Entscheidung. Ein Dashboard liefert erst dann nützliche Nachweise, wenn jemand es auswertet und entsprechend handelt.

Dieser Leitfaden behandelt Hochrisiko-KI-Systeme nach der EU-KI-Verordnung. Die betrieblichen Empfehlungen können auch anderen KI-Funktionen helfen; dadurch fällt jedoch nicht jedes SaaS-Produkt unter Artikel 72. Die folgenden Checklisten, Prüfintervalle und Beispiele sind Umsetzungsempfehlungen, keine vorgeschriebene regulatorische Vorlage.

Geltungsbereich und aktuellen Zeitplan bestimmen

Artikel 72 verlangt von Anbietern von Hochrisiko-KI-Systemen eine dokumentierte, verhältnismäßige Überwachung nach dem Inverkehrbringen. Sie umfasst die systematische Erhebung und Auswertung relevanter Leistungsdaten über die gesamte Lebensdauer, einschließlich relevanter Wechselwirkungen mit anderen KI-Systemen. Damit soll die fortlaufende Einhaltung der Hochrisiko-Anforderungen bewertet werden. KI-Verordnung, Artikel 72.

Beginnen Sie mit Zweckbestimmung, Risikoeinstufung und Unternehmensrolle. Eine Anwendung unter eigenem Namen anzubieten, ein gekauftes System zu betreiben oder ein KI-Modell mit allgemeinem Verwendungszweck bereitzustellen sind unterschiedliche Situationen. Lassen Sie die zuständige Rechtsperson Rolle und Vorschriften einschließlich Übergangsregelungen für bestehende Systeme bestätigen, bevor Sie das Überwachungsprogramm als gesetzliche Pflicht darstellen.

Stand 13. September 2026 nennt die Kommission den 2. Dezember 2027 als Anwendungsdatum für Hochrisiko-Regeln nach Anhang III und den 2. August 2028 für Hochrisiko-KI in Produkten nach Anhang I. Diese aktualisierten Termine folgen dem Inkrafttreten des KI-Omnibus am 27. Juli 2026. Sie verschieben nicht pauschal sämtliche KI-Pflichten. Aktualisierung der Kommission.

Der geänderte Artikel 72 Absatz 3 verlangt einen Überwachungsplan und setzt der Kommission für Leitlinien einschließlich einer Vorlage eine Frist bis zum 2. September 2027. Stellen Sie die ursprüngliche Frist für einen Durchführungsrechtsakt im Februar 2026 nicht als aktuellen Stand dar. Verordnung (EU) 2026/1744, Artikel 1 Nummer 30.

Bewahren Sie beim Plan einen datierten Vermerk zur Anwendbarkeit auf: Systemversion, Begründung, relevante Termine, prüfende Person und nächster Neubewertungsauslöser. Prüfen Sie ihn erneut, wenn sich Verwendungszweck, Markt oder Produktverantwortlichkeiten ändern. Ein klarer Geltungsbereich verhindert, dass das Überwachungsteam ein unbelegtes Versprechen vollständiger Konformität aller Funktionen übernimmt.

Anbieterüberwachung mit Kundenrückmeldungen verbinden

Anbieter sehen möglicherweise die Diensttelemetrie, während Kunden die Folgen einzelner Ausgaben erleben. Verbinden Sie beide Perspektiven durch einen Rückmeldeweg. Kundennahe Teams sollten genügend Kontext erfassen, um Produktfehler, ungeeignete Eingaben, Konfigurationsprobleme und eine Nutzung außerhalb des dokumentierten Zwecks unterscheiden zu können.

Betreiber haben nach Artikel 26 Absatz 5 eine eigene Pflicht zur betrieblichen Überwachung, einschließlich relevanter Mitteilungen an Anbieter und der Eskalation bestimmter Risiken und schwerwiegender Vorfälle. Der Überwachungsplan des Anbieters ersetzt diese Verantwortung nicht. KI-Verordnung, Artikel 26.

Vereinbaren Sie, wer Beschwerden erhält, wie Kunden die betroffene Version identifizieren und wer weitere Informationen anfordern kann. Sehen Sie einen Weg für dringende Anliegen außerhalb regulärer Kundengespräche vor. Wenn Kunden das System selbst hosten und Sie Produktionsdaten nicht einsehen können, dokumentieren Sie diese Grenze und vereinbaren Sie alternative Nachweise, etwa aggregierte Erkenntnisse, kontrollierte Reproduktionen oder kundenseitige Bewertungen.

Zum organisatorischen Kontext siehe die englischsprachigen Leitfäden zu KI-Governance-Erwartungen an SaaS-Anbieter und Compliance-Verantwortlichkeiten.

Einen ausführbaren Plan erstellen

Beginnen Sie mit einem kurzen Plan für ein klar abgegrenztes System. Verknüpfen Sie bestehende Entwicklungs-, Support-, Sicherheits- und Risikounterlagen, statt Nachweise mehrfach zu kopieren. Diese Felder bieten einen praktischen Einstieg:

• Systemgrenze: Zweckbestimmung, betroffene Nutzer, unterstützte Konfigurationen, Versionen und verbundene KI-Komponenten.
• Verantwortung: Planverantwortlicher, technische Prüfung, rechtlicher Eskalationskontakt und Vertretung.
• Signale: Bewertungsergebnisse, Beschwerden, menschliche Übersteuerungen, Dienstfehler, Anbietermitteilungen und bekannte Beobachtungslücken.
• Methoden: Stichprobenverfahren, Vergleichsbasis, Prüfhäufigkeit und Grenzen jeder Messung.
• Entscheidungen: Auslöser für Untersuchung, Einschränkungen, Rücknahme einer Version, Kundeninformation und Eskalation an die Geschäftsleitung.
• Nachweise: Ablageorte für Befunde, Freigaben, Korrekturmaßnahmen und Nachprüfungen.
• Änderungsauslöser: neue Modelle, Prompts, Datenquellen, Integrationen, Kundengruppen und Verwendungszwecke.

Benennen Sie für jedes Signal einen Empfänger. In einem gemeinsamen Postfach ohne verantwortliche Prüfung können Berichte liegen bleiben, weil jeder die Bearbeitung bei jemand anderem vermutet. In kleinen Unternehmen kann eine Person mehrere Rollen übernehmen. Der Plan sollte dennoch unterscheiden, wer untersucht, wer Restrisiken akzeptiert und wer den Weiterbetrieb freigibt.

Erproben Sie den Plan anhand einer aktuellen Supportbeschwerde. Kann die prüfende Person Version und Vergleichsbasis finden, den zuständigen Entwickler kontaktieren und eine Entscheidung dokumentieren, ohne private Nachrichten durchsuchen zu müssen? Falls nicht, verbessern Sie zunächst die Übergabe, bevor Sie weitere Kennzahlen ergänzen.

Signale wählen, die Entscheidungen beeinflussen

Beginnen Sie mit den Fehlerszenarien der Risikobewertung. Fragen Sie für jedes Szenario, welche beobachtbaren Nachweise auf eine nachlassende Kontrolle hindeuten würden. Verfügbarkeit und Antwortzeit können relevant sein, belegen aber nicht die fortlaufende Eignung der Ausgaben für den vorgesehenen Zweck.

Mögliche Signale sind falsche Ausgaben in geprüften Stichproben, ausbleibende Eskalationen unsicherer Fälle, unerwartete Änderungen menschlicher Übersteuerungen, Beschwerden über wiederkehrenden Ausschluss und Fehler nach vorgelagerten Aktualisierungen. Vergleichen Sie Ergebnisse in relevanten Betriebskontexten, soweit dies sinnvoll und rechtmäßig ist. Fehlende oder sehr kleine Stichproben sind eine Einschränkung, kein Beleg gleichwertiger Leistung.

Dokumentieren Sie Berechnung und Grundgesamtheit jeder Kennzahl. Eine wöchentliche Fehlerquote kann sinken, weil sich das Produkt verbessert, schwierige Fälle aus der Stichprobe verschwinden oder die Datenerhebung ausfällt. Ergänzen Sie Zahlen daher um Angaben zu Nutzung, Konfiguration und Messabdeckung.

Begründen Sie Alarmschwellen schriftlich. Eine beispielhafte interne Regel könnte bei wiederholten Fehlern einer neuen Version in einem kritischen Bewertungsszenario eine Untersuchung auslösen. Dies ist eine interne Entscheidungsregel, kein gesetzlicher Zahlenwert. Lassen Sie Fehlalarme und übersehene Fehler prüfen, damit sich auch die Überwachung verbessert.

Erfassen Sie nicht standardmäßig vollständige Kundengespräche. Wählen Sie mit Datenschutz- und Sicherheitsverantwortlichen die erforderlichen Mindestinformationen, Zugriffsbeschränkungen und passende Aufbewahrungsfristen je Nachweisart. Nutzen Sie möglichst eine Fallkennung mit zugriffsbeschränktem Begleitmaterial, statt sensible Inhalte in Tickets und Dashboards zu vervielfältigen.

Prüfrhythmen und Änderungsauslöser festlegen

Trennen Sie unmittelbare Warnungen, Routineanalysen und regelmäßige Managementbewertungen. Ein Team könnte dringende Signale sofort sichten, Trends wöchentlich prüfen und den Plan während der frühen Einführung monatlich neu bewerten. Diese Intervalle sind Ausgangsvorschläge; begründen Sie den Rhythmus mit Risiken und Änderungsgeschwindigkeit des Systems.

Bei jeder Veröffentlichung sollten möglicherweise veränderte Annahmen sichtbar werden. Neue Abrufquellen, Modellweiterleitung, Berechtigungen, Sprachen und Kundengruppen können das Verhalten verändern, obwohl die Oberfläche gleich bleibt. Erfassen Sie vor der Änderung eine Vergleichsbasis, definieren Sie den Beobachtungszeitraum und bestimmen Sie, welche Befunde einen Einführungsstopp rechtfertigen würden.

Beziehen Sie Anbieteraktualisierungen ein. Klären Sie, wer Versionshinweise erhält, wie Versionen identifiziert werden und was bei Änderungen eines vorgelagerten Dienstes ohne festgelegte Version geschieht. Dokumentieren Sie bei begrenzter Beobachtbarkeit ergänzende Prüfungen und verbleibende Unsicherheit, statt vollständige Abdeckung zu suggerieren.

Ergänzende Abläufe beschreibt der englischsprachige Beitrag Wie KI Compliance-Überwachung und Berichterstattung verändert. Halten Sie das Prüfergebnis kurz: Was hat sich geändert, welche Nachweise wurden betrachtet, welche Entscheidung folgte und wer übernimmt den nächsten Schritt?

Befunde in Korrekturmaßnahmen überführen

Jeder wesentliche Befund braucht einen Falldatensatz. Erfassen Sie Entdeckungszeitpunkt, betroffene Version und Konfiguration, verfügbare Nachweise, mögliche Auswirkungen, erste Eindämmung, Entscheidungsverantwortlichen und Nachverfolgungsfrist. Kennzeichnen Sie Unsicherheit ausdrücklich: Ein plausibler Verdacht kann rasches Handeln erfordern, bevor die Ursache bekannt ist.

Ein praktischer Ablauf umfasst Signalsichtung, Schutz betroffener Nutzer, Sicherung erforderlicher Nachweise, Untersuchung, Auswahl einer Korrekturmaßnahme und Ergebnisprüfung. Denkbar sind geänderte Anweisungen, Konfigurationseinschränkungen, die Rückkehr zur vorherigen Version, bessere menschliche Prüfung oder die Aussetzung einer Funktion. Entscheiden Sie anhand des tatsächlichen Fehlers und der anwendbaren Pflichten.

Schließen Sie einen Fall nicht automatisch nach Bereitstellung eines Patches. Wiederholen Sie das fehlgeschlagene Szenario, prüfen Sie repräsentative Nutzung und dokumentieren Sie neue Probleme durch die Änderung. Aktualisieren Sie Risikobewertung, Anweisungen, Überwachungsprüfungen und Versionsunterlagen, wenn der Befund deren Annahmen verändert.

Bei vorübergehend akzeptierten Problemen sind Umfang, Genehmiger, Ablaufdatum, ergänzende Kontrollen und Wiedereröffnungsauslöser festzuhalten. Eine unbefristete Ausnahme lässt sich schwer von einer vergessenen Aufgabe unterscheiden. Die nächste prüfende Person muss verstehen können, warum der Betrieb weiterlief und wann diese Entscheidung geändert würde.

Schwerwiegende Vorfälle gesondert behandeln

Mögliche schwerwiegende Vorfälle erfordern sofortige rechtliche und operative Vorfallsbewertung. Sie dürfen nicht bis zur nächsten Trendprüfung warten. Artikel 73 enthält Meldepflichten und unterschiedliche Fristen: eine allgemeine Höchstfrist von 15 Tagen, kürzere Fristen für bestimmte Fälle und situationsabhängige unverzügliche Meldungen. Er erlaubt nicht, generell 15 Tage abzuwarten. KI-Verordnung, Artikel 73.

Die zuständige Person sollte prüfen, ob die gesetzliche Definition erfüllt ist, welche Meldevorschriften gelten, wer informiert werden muss und wann die Frist begann. Bewerten Sie auch parallele Pflichten aus anderen anwendbaren Regelwerken und Kundenverträgen. Halten Sie diese Entscheidungen getrennt, damit eine Meldung nicht irrtümlich als Erfüllung sämtlicher Pflichten gilt.

Üben Sie vor dem Produktstart ein dringendes Szenario. Prüfen Sie, ob das Team Kontakte findet, Nachweise sichert, Nutzung einschränkt und trotz unvollständiger Fakten einen ersten Bericht erstellt. Legen Sie fest, wer zeitkritische Entscheidungen bei Abwesenheit des regulären Verantwortlichen treffen darf.

Beispiel: Personalsoftware nach einer Modellaktualisierung

Ein hypothetischer SaaS-Anbieter betreibt eine als hochriskant bewertete Anwendung zur Bewerberrangfolge. Nach einer vorgelagerten Modellaktualisierung deuten Kundenbeschwerden auf uneinheitliche Bewertungen unkonventioneller Berufsbiografien hin. Die aggregierte Dienstverfügbarkeit bleibt normal.

Der Überwachungsverantwortliche eröffnet einen Fall, identifiziert betroffene Versionen und Kunden und bittet die Entwicklung um Reproduktion anhand kontrollierter Beispiele. Das Team prüft, ob der Bewertungsdatensatz diese Karriereverläufe abdeckte und ob sich die Rangfolge gegenüber der freigegebenen Vergleichsbasis verändert hat. Rechts- und Produktverantwortliche bewerten mögliche Auswirkungen und etwaige Meldepflichten.

Je nach Befund könnte der Anbieter die Einführung pausieren, die vorherige Version wiederherstellen, betroffene Funktionen einschränken oder zusätzliche menschliche Prüfungen vorsehen. Kundeninformationen erläutern Umfang und Zwischenmaßnahmen, ohne eine noch nicht festgestellte Ursache zu behaupten.

Der Fall endet erst, wenn die Nachprüfung die gewählte Korrektur stützt und die zuständige Person das Ergebnis dokumentiert. Das Team erweitert begründet Bewertungsabdeckung und Überwachungsauslöser. Dieses Beispiel veranschaulicht einen Ablauf; nicht jede inkonsistente Rangfolge ist damit ein gesetzlich meldepflichtiger schwerwiegender Vorfall.

Häufige Fehler vermeiden

Verfügbarkeit als vollständiges Programm behandeln. Der Betriebszustand zeigt, ob ein Dienst läuft. Ergänzen Sie Prüfungen zu Ausgabequalität, Aufsicht und Risiken des tatsächlichen Zwecks.

Nur auf Beschwerden warten. Schweigende Kunden haben möglicherweise keinen Meldeweg oder erkennen Fehler nicht. Verbinden Sie Rückmeldungen mit geplanten Bewertungen und gezielten Nachfragen.

Eine veraltete Version überwachen. Ordnen Sie Befunde Änderungen an Modell, Anwendung, Konfiguration und Datenquellen zu. Ein Bericht zum vergangenen Quartal sagt möglicherweise wenig über die heutige Version aus.

Nachweise ohne Entscheidungen aufbewahren. Diagramme erklären nicht, warum das Team weiterbetrieb, einschränkte oder stoppte. Bewahren Sie Begründung und Nachprüfung auf.

Vollständige Sichtbarkeit versprechen. Benennen Sie fehlende Kundendaten, unzugängliche Anbieterinterna und Stichprobengrenzen. Erklären Sie deren Auswirkungen auf Aussagekraft und Entscheidungen.

Fragen aus der Praxis

Welchen praktischen Zweck hat die Überwachung nach dem Inverkehrbringen?

Sie erkennt, wann reale Nutzung Annahmen vor der Veröffentlichung infrage stellt, und überführt diese Erkenntnisse in überprüfte Maßnahmen. Das Ergebnis ist eine begründbare Entscheidung mit verifizierter Nachverfolgung und nachvollziehbaren Befunden.

Braucht jedes SaaS-Unternehmen einen Plan nach Artikel 72?

Gehen Sie nicht davon aus. Prüfen Sie Hochrisikoeinstufung, Anbieterrolle, Geltungsbereich und Anwendungszeitpunkt. Andere Systeme können von verhältnismäßiger Überwachung profitieren; Betreiber müssen ihre eigenen Pflichten gesondert prüfen.

Was sollten wir zuerst dokumentieren?

Beginnen Sie mit Systemgrenze, verantwortlicher Person, wesentlichen Fehlerszenarien, verfügbaren Signalen und dringendem Eskalationsweg. Bearbeiten Sie einen realen Befund, bevor Sie den Prozess auf das gesamte Produktportfolio ausweiten.

Welche Nachweise sollte eine Prüfung erzeugen?

Bewahren Sie Planversion, geprüfte Nachweise, Abdeckungsgrenzen, Entscheidung, Maßnahmenverantwortlichen und Verifikationsergebnis auf. Eine prüfende Person sollte den Weg vom Signal bis zum Abschluss ohne Rekonstruktion des Teamgedächtnisses nachvollziehen können.

Quellen

Die rechtliche Darstellung verwendet die konsolidierte KI-Verordnung, die KI-Omnibus-Änderung und die bei den jeweiligen Aussagen verlinkten Kommissionsquellen. Rechtsstand geprüft am 13. September 2026. Betriebsbeispiele und vorgeschlagene Prüfrhythmen sind redaktionelle Empfehlungen.

Bild: Team Meeting von woodleywonderworks, CC BY 2.0, über Wikimedia Commons; auf 1280 × 482 Pixel verkleinert.