Published on

Check: Welche Provider-Pflichten gelten für mein System?

Authors

Wer ein KI-System entwickelt oder unter eigenem Namen in Verkehr bringt, trägt die schwerste Pflichtenlast des EU AI Act — die des Providers. Anders als Deployer-Pflichten sind Provider-Pflichten nicht schlank, sondern kumulativ: Qualitätsmanagement, technische Dokumentation, Konformitätsbewertung und fortlaufende Beobachtung greifen ineinander und müssen über den gesamten Lebenszyklus belegbar bleiben. Dieser Check führt Sie durch die Frage, welche dieser Pflichten für Ihr konkretes System einschlägig sind und wo Ihre Nachweislücken liegen. Er richtet sich an Produkt- und Entwicklungsverantwortliche, an technische Leitungen und an Compliance-Funktionen in Organisationen, die KI selbst bauen, wesentlich verändern oder unter eigenem Namen vertreiben. Voraussetzung: Sie haben Ihre Rolle bereits geklärt. Falls nicht, starten Sie mit dem Check zur Rollenzuordnung.

Vorbereitung

Halten Sie folgende Informationen bereit:

  • Die Risikoklasse des Systems — oder zumindest eine begründete Arbeitsannahme (siehe Check Hochrisiko).
  • Angaben dazu, ob Sie das System selbst entwickelt haben oder ein fremdes System unter eigenem Namen bereitstellen.
  • Kenntnis darüber, ob Sie ein bestehendes System wesentlich verändert oder für einen neuen Zweck angepasst haben.
  • Eine Übersicht Ihrer vorhandenen Entwicklungs- und Qualitätsdokumentation.
  • Information darüber, ob Ihr System in der EU bereitgestellt oder genutzt wird — unabhängig davon, wo Sie ansässig sind.

Der Check

Frage 1: Bringen Sie ein KI-System unter Ihrem eigenen Namen oder Ihrer eigenen Marke in Verkehr oder in Betrieb — oder haben Sie ein System selbst entwickelt?

  • Ja → siehe Frage 2.
  • Nein, Sie setzen ein fremdes System unverändert ein → Ergebnis A: Sie sind hier vermutlich Deployer, nicht Provider. Wechseln Sie zum Deployer-Check. Der Provider-Check endet hier.
  • Unsicher → klären Sie zuerst die Rolle, bevor Sie fortfahren.

Frage 2: Haben Sie ein bereits bestehendes KI-System wesentlich verändert oder für einen anderen als den ursprünglich vorgesehenen Zweck angepasst?

  • Ja → Befund: Sie können dadurch selbst zum Provider dieses veränderten Systems werden, auch wenn ein anderer es ursprünglich gebaut hat. Weiter mit Frage 3.
  • Nein, es ist Ihre Eigenentwicklung → siehe Frage 3.

Frage 3: Handelt es sich um ein Hochrisiko-System nach Annex I oder Annex III?

  • Ja → siehe Frage 4.
  • Nein → springen Sie zu Frage 9.
  • Unsicher → behandeln Sie es vorerst als Hochrisiko und fahren Sie mit Frage 4 fort. Eine zu vorsichtige Einstufung kostet Aufwand, eine zu leichtfertige kostet mehr.

Frage 4: Betreiben Sie ein Qualitätsmanagementsystem, das den Entwicklungs- und Bereitstellungsprozess des Systems dokumentiert abbildet?

  • Ja, dokumentiert und gelebt → siehe Frage 5.
  • Prozesse existieren, sind aber nicht als QMS dokumentiert → Befund: Lücke 1. Weiter mit Frage 5.
  • Nein → Befund: Lücke 1 (kritisch). Weiter mit Frage 5.

Frage 5: Existiert eine technische Dokumentation, die Zweckbestimmung, Architektur, Trainings- und Testdaten, Risikomanagement und getroffene Maßnahmen nachvollziehbar beschreibt?

  • Ja, vollständig und aktuell → siehe Frage 6.
  • Teilweise, in verstreuten Artefakten → Befund: Lücke 2. Weiter mit Frage 6.
  • Nein → Befund: Lücke 2 (kritisch). Weiter mit Frage 6.

Frage 6: Führt Ihr System automatisch Protokolle (Logs) über seinen Betrieb, und ist die technische Voraussetzung dafür in der Konzeption angelegt?

  • Ja, Logging ist vorgesehen und dokumentiert → siehe Frage 7.
  • Logs entstehen, sind aber nicht systematisch konzipiert → Befund: Lücke 3. Weiter mit Frage 7.
  • Nein → Befund: Lücke 3 (kritisch). Weiter mit Frage 7.

Frage 7: Haben Sie ein Konformitätsbewertungsverfahren durchlaufen oder eingeplant, und ist die Frage nach CE-Kennzeichnung und behördlicher Registrierung geklärt?

  • Ja, Verfahren, Kennzeichnung und Registrierung sind geklärt oder eingeplant → siehe Frage 8.
  • In Bearbeitung, ohne belastbaren Plan → Befund: Lücke 4. Weiter mit Frage 8.
  • Nein, bisher nicht betrachtet → Befund: Lücke 4 (kritisch). Weiter mit Frage 8.

Frage 8: Haben Sie eine Human-Oversight-Fähigkeit und eine dem Zweck angemessene Genauigkeit, Robustheit und Cybersicherheit in das System eingebaut und belegt?

  • Ja, konzipiert und getestet → siehe Frage 9.
  • Vorhanden, aber nicht systematisch getestet oder belegt → Befund: Lücke 5. Weiter mit Frage 9.
  • Nein → Befund: Lücke 5 (kritisch). Weiter mit Frage 9.

Frage 9: Interagiert Ihr System unmittelbar mit natürlichen Personen oder erzeugt es Inhalte — etwa als Chatbot, durch generierte Texte, Bilder, Audio oder Video?

  • Ja → Befund: Transparenzpflichten einschlägig. Sie müssen dafür sorgen, dass Betroffene erkennen können, dass sie mit einem KI-System interagieren beziehungsweise dass Inhalte künstlich erzeugt oder manipuliert wurden. Details klärt der Transparenz-Check. Weiter mit Frage 10.
  • Nein → siehe Frage 10.

Frage 10: Haben Sie ein Verfahren, um nach dem Inverkehrbringen Vorfälle zu beobachten, zu bewerten und bei schwerwiegenden Vorfällen zu reagieren?

  • Ja, Post-Market-Monitoring ist etabliert → siehe Frage 11.
  • Ansätze vorhanden, aber kein definierter Prozess → Befund: Lücke 6. Weiter mit Frage 11.
  • Nein → Befund: Lücke 6 (kritisch). Weiter mit Frage 11.

Frage 11: Könnten Sie heute, ohne Vorlauf, gegenüber einer Aufsichtsbehörde die Erfüllung der obigen Punkte mit datierten Dokumenten belegen?

  • Ja, mit Dokumenten und Zeitstempeln → Ergebnis D.
  • Teilweise, mit Rekonstruktionsaufwand → Ergebnis C.
  • Nein → Ergebnis B.

Auswertung

Ergebnis A: Sie sind für dieses System kein Provider. Sobald Sie es wesentlich verändern, anpassen oder unter eigenem Namen bereitstellen, wiederholen Sie den Check.

Ergebnis B: Sie stellen ein System bereit, dessen Pflichterfüllung Sie nicht belegen können. Unabhängig davon, wie sorgfältig Ihre Entwicklung tatsächlich ist — im Enforcement-Fall zählt der Nachweis, nicht die Absicht. Bei Providern wiegt das besonders schwer, weil die Pflichtenkette länger und die Dokumentationslast höher ist als beim Deployer.

Ergebnis C: Die Substanz ist vorhanden, die Evidenz ist verstreut. Der Aufwand liegt weniger im Aufbau als im Zusammenführen, Versionieren und Aktuell-Halten über den Lebenszyklus.

Ergebnis D: Sie sind nachweisfähig. Prüfen Sie in diesem Fall vor allem die Fortlauffähigkeit: Provider-Pflichten enden nicht mit dem Inverkehrbringen, sondern begleiten das System, solange es am Markt ist.

Jede notierte Lücke benennt eine konkrete Pflicht, die derzeit nicht belegbar erfüllt ist. Als kritisch markierte Lücken sollten Sie priorisieren — insbesondere Qualitätsmanagement, technische Dokumentation und Konformitätsbewertung, weil auf ihnen die übrigen Nachweise aufbauen.

Nächste Schritte

  • Lücken 1 bis 5 schließen Sie am schnellsten mit vorbereiteten Vorlagen — QMS-Grundgerüst, technische Dokumentation und Human-Oversight-Beschreibung finden Sie im Compliance-Toolkit auf ki-hochrisiko.de.
  • Wenn Frage 3 unsicher blieb, klären Sie zuerst die Einstufung: Der Risikostufen-Deep-Dive auf ki-risikostufe.de ordnet die vier Klassen ein.
  • Setzen Sie einen Zieltermin. Das Enforcement-Datum ist der 02.12.2027; die Provider-Nachweiskette rückwirkend aufzubauen ist deutlich teurer, als sie ab jetzt strukturiert mitlaufen zu lassen. Den Gesamtrahmen der Pflichten ordnet der Leitfaden auf eu-ai-verordnung.de ein.

Was dieser Check NICHT leistet

Dieser Self-Check ist eine strukturierte Orientierungshilfe, keine Rechtsberatung. Welche Provider-Pflichten im Einzelfall greifen, hängt von der konkreten Einstufung des Systems, vom Einsatzkontext und von weiteren Rechtsgrundlagen ab — etwa Produkt-, Datenschutz- und Sektorrecht, die dieser Fragebogen bewusst ausklammert. Auch die genaue Ausgestaltung des Konformitätsbewertungsverfahrens und die Frage, ob eine benannte Stelle einzubinden ist, werden hier nicht abschließend geprüft. Nutzen Sie das Ergebnis, um Ihren Status einzuordnen und das Gespräch mit Fachleuten vorzubereiten — nicht als verbindliche Bewertung.

Wenn dieser Check Sie zur Erkenntnis bringt, dass strukturierte Trust-Infrastructure nötig ist: AEGIRA AI Navigator deckt diese Self-Assessments operativ ab — aegira.ai.