Anbieterpflichten operationalisieren, ohne die Produktentwicklung zu bremsen

Anbieterpflichten sollten ein Lieferworkflow sein, keine spaete juristische Nachkontrolle. Nach dem EU AI Act kann Anbieterstatus relevant werden, wenn ein SaaS-Unternehmen ein KI-System entwickelt, entwickeln laesst, unter eigenem Namen auf den EU-Markt bringt, ein Hochrisiko-System wesentlich veraendert, den vorgesehenen Zweck aendert oder ein General-Purpose-AI-Modell bereitstellt. Die operative Frage lautet deshalb nicht nur, ob das Unternehmen Anbieter ist. Die Frage lautet, welche Produktentscheidungen, Nachweise, Kontrollen und Kundeninformationen vor dem Launch vorhanden sein muessen.

Beginnen Sie pro KI-Workflow mit einer kurzen Rollenentscheidung. Ein Unternehmen kann fuer ein internes Support-Tool Betreiber sein, fuer ein kundenseitiges Scoring-Modul Anbieter und fuer eine Modell-API GPAI-Modellanbieter. Halten Sie fest, welches KI-Asset betroffen ist, wer den vorgesehenen Zweck bestimmt, unter welchem Namen die Funktion vermarktet wird, ob wesentliche Aenderungen vorgenommen werden und welcher Ausloeser eine Neubewertung startet.

Artikel 16 wird praktisch, wenn er in Produkt-Gates uebersetzt wird. In der Discovery prueft das Team, ob die Funktion KI nutzt und ob ein Hochrisiko-Kontext moeglich ist. Im Architekturreview dokumentiert es Datenfluesse, Modellquelle, menschliche Aufsicht, Logging, Genauigkeit, Robustheit und Cybersecurity-Annahmen. Im Vendor-Review sammelt es Downstream-Dokumentation und Sicherheitsnachweise. Vor dem Release bestaetigt es technische Dokumentation, Testnachweise, Kundenanweisungen, Monitoring und Freigabe.

Artikel 25 gehoert in Beschaffung und Produktplanung. Wer ein Vendor-System white-labelt, wesentlich konfiguriert, fine-tuned oder unter eigener Marke verkauft, kann providerseitige Verantwortung ausloesen. Fragen Sie deshalb frueh: Sieht der Kunde den Vendor oder nur Ihr Produkt? Aendert sich der vorgesehene Zweck? Aendern sich Schwellenwerte, Automationsgrad, Datenquellen oder Nutzungskontext? Reichen die Vendor-Dokumente fuer eigene Pflichten?

Ein Provider-Obligations-Record sollte ein Arbeitsartefakt sein. Er verweist auf AI-Inventar, Produkt-Ticket, Vendor-Review und Launch-Checkliste. Mindestens sollte er Asset, Zweck, Nutzer, Rollenentscheidung, Risikoklassifizierung, ausgeloeste Pflichten, Dokumentationsort, Testnachweise, Kundeninformationen, Monitoring, Incident-Route und Neubewertungsausloeser enthalten. So wird aus Compliance kein statisches Dokument, sondern eine nachvollziehbare Betriebsroutine.

GPAI-Modellpflichten gehoeren auf eine eigene Spur. Artikel 53 betrifft unter anderem technische Dokumentation, Informationen fuer nachgelagerte Anbieter, Copyright-Policy, Trainingsinhaltszusammenfassung und Zusammenarbeit mit Behoerden. Ein SaaS-Feature, das ein Drittmodell nutzt, macht das Unternehmen nicht automatisch zum GPAI-Modellanbieter; es kann aber Anbieter des angebotenen KI-Systems sein.

Kundendokumentation ist Teil der Release-Bereitschaft. Kunden brauchen Zweck, Grenzen, menschliche Aufsicht, Datenverarbeitung, Monitoring, Supportwege und Aenderungsinformationen. Diese Aussagen muessen zur Rollen- und Risikobewertung passen. Definieren Sie zudem Neubewertungsausloeser: neuer Zweck, neue Kundengruppe, neuer Hochrisiko-Kontext, wesentliche Modellveraenderung, weniger menschliche Pruefung, neue Vendor-Dokumente oder Vorfaelle.

Der schnellste Start ist ein einseitiger Record fuer eine reale KI-Funktion. Danach werden die Fragen in Discovery, Architekturreview, Vendor-Review, Release-Freigabe und Change Management eingebaut. So entfernt das Team Unsicherheit frueh, statt kurz vor Launch Nachweise nachzubauen.

FAQ

Wozu dienen Anbieterpflichten praktisch?

Sie machen Rollenentscheidung, Klassifizierung, technische Dokumentation, Nachweise, Kundenanweisungen, Monitoring, Korrekturmassnahmen und Neubewertung im Produktprozess sichtbar.

Wann koennen Anbieterpflichten fuer SaaS-Teams gelten?

Sie koennen gelten, wenn ein Team ein KI-System entwickelt oder entwickeln laesst, es unter eigenem Namen vermarktet, ein Hochrisiko-System wesentlich veraendert, den Zweck aendert oder ein GPAI-Modell bereitstellt.

Was sollte zuerst dokumentiert werden?

Starten Sie mit einem Record je KI-Workflow: Asset, Zweck, Rollenentscheidung, Risikoklassifizierung, Pflichten, Nachweis-Owner, Dokumentationsort, Launch-Blocker, Kundenanweisungen und Neubewertungsausloeser.