Anbieterpflichten: Praxisleitfaden fuer SaaS-Teams

Anbieterpflichten nach dem EU AI Act werden relevant, wenn ein SaaS-Unternehmen ein KI-System oder ein General-Purpose-AI-Modell entwickelt, unter eigenem Namen vermarktet, wesentlich veraendert oder auf dem EU-Markt bereitstellt. Entscheidend ist nicht nur, wer den Modellcode geschrieben hat. Relevant ist, wer den Zweck definiert, das System unter eigener Marke anbietet, die Kundenerfahrung kontrolliert oder ein fremdes System so veraendert, dass neue Pflichten entstehen.

Die erste Aufgabe ist eine Rollenbewertung pro Workflow. Ein Unternehmen kann in einem internen Tool Betreiber sein, bei einer kundensichtbaren Funktion Anbieter, bei einem API-Modell GPAI-Modellanbieter und nach Artikel 25 sogar neuer Anbieter, wenn es ein System rebrandet, wesentlich modifiziert oder den Zweck in Richtung High-Risk aendert.

Welche Pflichtspur gilt

Fuer High-Risk-AI-Systeme buendelt Artikel 16 Pflichten wie Konformitaet mit den Anforderungen, Quality Management System, technische Dokumentation, Logs, Konformitaetsbewertung, EU Declaration of Conformity, CE-Kennzeichnung, Registrierung, Korrekturmassnahmen, Behoerdenkooperation und Accessibility.

Artikel 25 ist wichtig fuer die AI-Wertschoepfungskette. Wer ein System unter eigenem Namen anbietet, wesentlich modifiziert oder den vorgesehenen Zweck aendert, kann selbst Anbieter werden. Das betrifft SaaS-Teams, die AI-Funktionen white-labeln, einbetten, feinabstimmen, verpacken oder stark konfigurieren.

Fuer General-Purpose-AI-Modelle gilt eine andere Spur. Artikel 53 betrifft technische Dokumentation, Informationen fuer nachgelagerte Anbieter, Copyright-Policy, oeffentliche Trainingsdaten-Zusammenfassung und Kooperation mit Behoerden.

Was zuerst dokumentiert wird

Der Minimum-Record sollte AI Asset, Zweck, Rolle, Risikospur, ausgeloeste Pflichten und Nachweise enthalten. Erfassen Sie Owner, Reviewer, Dokumentationsort, Risk-Management-Datei, Testnachweise, Data-Governance-Notizen, Vendor-Dokumente, Konformitaetsstatus, Release Ticket, Monitoring Plan, Incident Process, Kundendokumentation und Reassessment-Ausloeser.

In Produkt-Gates einbauen

Provider Work darf nicht neben Delivery liegen. In Product Discovery wird gefragt, ob die Funktion AI nutzt und unter eigener Marke angeboten wird. In Architecture Review werden Modellquellen, Datenfluesse, Logging, Human Oversight und Monitoring geprueft. In Vendor Review werden nachgelagerte Dokumente gesammelt. In Release Readiness wird bestaetigt, ob Kundendokumentation, technische Dokumentation und Evidence vollstaendig sind.

Haeufige Fehler

Der groesste Fehler ist die Annahme, dass immer der Modellvendor Anbieter ist. Weitere Fehler sind Inventare ohne Rollenfelder, technische Dokumentation erst in der Launch-Woche, fehlende Downstream-Information fuer Kunden und keine Trigger fuer wesentliche Aenderungen.

FAQ

Wozu dienen Anbieterpflichten praktisch?

Sie stellen sicher, dass die Organisation, die ein AI-System oder GPAI-Modell entwickelt, vermarktet, veraendert oder bereitstellt, Design, Dokumentation, Bewertung, Monitoring und Support nachweisen kann.

Wann gelten sie fuer SaaS-Teams?

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

Was zuerst aendern?

Starten Sie mit Rollenbewertung und Klassifizierung. Danach werden Pflichten, Evidenz, Owner und Reassessment-Trigger mit Produkt- und Release-Arbeit verbunden.