Wann Anbieterpflichten gelten und was als Naechstes zu tun ist

Anbieterpflichten gelten, wenn ein SaaS-Unternehmen nach dem EU AI Act fuer ein KI-System oder ein General-Purpose-AI-Modell verantwortlich ist. Entscheidend ist nicht nur, wer den Modellcode geschrieben hat. Relevant ist, ob das Unternehmen das System entwickelt, entwickeln laesst, unter eigenem Namen anbietet, auf den EU-Markt bringt, ein High-Risk-System wesentlich veraendert, den Zweck aendert oder selbst ein GPAI-Modell bereitstellt.

Der naechste Schritt ist operativ: Legen Sie einen Anbieterpflichten-Record fuer den AI-Workflow an. Dokumentieren Sie AI Asset, vorgesehenen Zweck, Rolle, Risikospur, ausgeloeste Pflichten, Evidence Owner und Launch-Gate.

Warum das praktisch wichtig ist

Anbieterpflichten bestimmen, wer nachweisen muss, dass ein AI-System entworfen, dokumentiert, bewertet, ueberwacht und unterstuetzt wird. Fuer High-Risk-Systeme nennt Artikel 16 unter anderem Quality Management, technische Dokumentation, Logs, Konformitaetsbewertung, EU Declaration of Conformity, CE-Kennzeichnung, Registrierung, Korrekturmassnahmen und Behoerdenkooperation.

Bei SaaS entsteht die Frage oft mitten in der Produktarbeit: ein AI Scoring Feature, ein eingebettetes Drittmodell, ein rebrandetes Modul, eine neue Zweckbestimmung oder eine API fuer ein feinabgestimmtes Modell. Diese Faelle brauchen eine Rollenbewertung pro Workflow.

Wann die Pflichten gelten

Pruefen Sie zuerst die Rollen. Dasselbe Unternehmen kann Betreiber eines internen Tools, Anbieter einer kundensichtbaren Funktion, Distributor eines eingebetteten Moduls und GPAI-Modellanbieter fuer eine API sein. Eine pauschale Aussage wie "wir nutzen Vendor AI" reicht fuer Launch-Entscheidungen nicht aus.

Typische Trigger sind kundensichtbare AI-Funktionen, White-Label-Module, Ranking oder Scoring, automatisierte Empfehlungen, AI in High-Risk-Kontexten, wesentliche Modellaenderungen, neue Datenquellen, neue Kundensegmente und geaenderte Produktversprechen.

Was zuerst dokumentiert wird

Der Minimum-Record sollte sechs Fragen beantworten: Was ist das AI Asset? Was ist der vorgesehene Zweck? Welche Rolle spielt das Unternehmen? Welche Pflichtspur gilt? Welche Nachweise sind erforderlich? Wann muss neu bewertet werden?

Zu den Nachweisen gehoeren technische Dokumentation, Risk-Management-Records, Data-Governance-Notizen, Tests, Logging-Entscheidungen, Human Oversight, Kundendokumentation, Vendor-Unterlagen, Monitoring und Release-Freigaben.

In Delivery einbauen

Provider Work gehoert in Product Discovery, Architecture Review, Vendor Review, Release Readiness und Post-Launch Monitoring. Product beschreibt den Use Case. Engineering liefert technische Fakten. Legal oder Compliance bewertet Rolle und Pflichten. Security prueft Kontrollen und Incident-Wege. Customer Teams nutzen freigegebene Erklaerungen.

Haeufige Fehler

Der erste Fehler ist die Annahme, dass immer der Modellvendor Anbieter ist. Weitere Fehler sind AI-Inventare ohne Rollenfelder, Anbieterpflichten als einmalige Rechtsantwort, verlorene Downstream-Informationen fuer Kunden und Evidence, die nicht mit Release-Arbeit verbunden ist.

FAQ

Wozu dienen Anbieterpflichten praktisch?

Sie klaeren, wer fuer ein AI-System oder GPAI-Modell verantwortlich ist, und verbinden diese Rolle mit Dokumentation, Risikokontrollen, Kundeninformationen, Monitoring und Nachweisen.

Wann gelten sie fuer SaaS-Teams?

Wenn das Team ein AI-System entwickelt, entwickeln laesst, unter eigenem Namen anbietet, auf den EU-Markt bringt, ein High-Risk-System wesentlich aendert, den Zweck aendert oder ein GPAI-Modell bereitstellt.

Was sollte zuerst geaendert werden?

Starten Sie mit einem Anbieterpflichten-Record fuer AI Asset, Zweck, Rolle, Risikospur, Pflichten, Evidence Owner, Dokumentationsort, Launch-Gate und Reassessment-Trigger.