Haeufige Fehler bei Anbieterpflichten, die SaaS-Teams immer noch machen

Der haeufigste Fehler bei Anbieterpflichten besteht darin, den EU AI Act als juristisches Etikett statt als operativen Workflow zu behandeln. SaaS-Teams muessen wissen, ob sie als Anbieter handeln, welches KI-Asset und welche Risikospur betroffen sind, wer die Nachweise verantwortet und welche Produkt-Gates vor Release oder Kundenzusage abgeschlossen sein muessen.

Anbieterpflichten koennen relevant werden, wenn ein SaaS-Unternehmen ein KI-System entwickelt, entwickeln laesst, unter eigenem Namen auf den EU-Markt bringt, ein anderes System wesentlich veraendert, den Verwendungszweck so aendert, dass Hochrisiko-Status entsteht, oder ein General-Purpose-AI-Modell bereitstellt. Das Problem ist selten fehlendes Bewusstsein. Das Problem ist, dass die Begriffe nicht mit Release-Entscheidungen, Vertriebsclaims, Nachweisablage und Verantwortlichkeiten verbunden werden.

Fehler 1: Annehmen, dass immer der Modellanbieter verantwortlich ist

Viele Teams starten mit der Lieferantenfrage. Wenn ein externer Anbieter das Modell liefert, scheint die Verantwortung dort zu liegen. Das kann relevant sein, ersetzt aber keine Rollenpruefung. Ein SaaS-Unternehmen kann ein Drittmodell nutzen und trotzdem Anbieter des KI-Systems sein, das es Kunden anbietet, wenn es Zweck, Kundenerlebnis, Produktvermarktung oder Konfiguration kontrolliert.

Artikel 25 ist hier besonders wichtig. Ein Distributor, Importeur, Betreiber oder sonstiger Dritter kann als Anbieter eines Hochrisiko-KI-Systems gelten, wenn er seinen Namen oder seine Marke darauf setzt, es wesentlich veraendert oder den Zweck so aendert, dass es hochriskant wird. Das betrifft Teams, die KI-Funktionen white-labeln, einbetten, feinabstimmen, neu verpacken oder als eigenes SaaS-Feature verkaufen.

Die Abhilfe ist eine Rollenpruefung pro Workflow. Dokumentieren Sie KI-Asset, Zweck, Product Owner, Lieferantenabhaengigkeit, Kundenkontext, Aenderungsgrad und Schlussfolgerung. "Vendor AI verwendet" ist keine Anbieterentscheidung.

Fehler 2: Ein KI-Inventar ohne Rollenfelder fuehren

Ein Inventar mit KI-Tools ist nuetzlich, beantwortet Anbieterpflichten aber nicht allein. Ohne Felder fuer Anbieter, Betreiber, Importeur, Distributor, Produkthersteller oder GPAI-Modellanbieter sieht das Team nicht, welche Pflichten welchem Workflow zugeordnet sind.

Das wird in Kundenpruefungen schmerzhaft. Vertrieb verweist auf AI-Act-Kontrollen, Security auf Vendor-Frageboegen, Product auf Feature-Dokumentation und Legal auf eine Risikonotiz. Wenn das Inventar aber Rolle, Klassifikation, Owner, Nachweisort und Reassessment-Trigger nicht zeigt, kann niemand schnell erklaeren, wofuer das Unternehmen verantwortlich ist.

Fuegen Sie Rollen- und Nachweisfelder hinzu: System- oder Modellname, Zweck, Nutzergruppe, Markt- oder Kundenkontext, Rollenentscheidung, Risikoklassifikation, anwendbare Pflichten, Nachweis-Owner, Dokumentationsort, Status der Kundenunterlagen, Monitoring-Owner und Trigger fuer Neubewertung.

Fehler 3: Artikel 16 als spaetere Checkliste behandeln

Bei Hochrisiko-KI-Systemen umfasst Artikel 16 Pflichten wie Konformitaet mit den Hochrisiko-Anforderungen, Qualitaetsmanagementsystem, Dokumentation, Protokolle unter Kontrolle des Anbieters, Konformitaetsbewertung vor Marktbereitstellung oder Inbetriebnahme, EU-Konformitaetserklaerung, CE-Kennzeichnung wo erforderlich, Registrierung, Korrekturmassnahmen, Zusammenarbeit mit Behoerden und Barrierefreiheitsanforderungen.

Teams geraten in Schwierigkeiten, wenn sie diese Liste erst kurz vor Launch abarbeiten. Viele Nachweise entstehen aus Design- und Lieferentscheidungen: Risikomanagement, Data Governance, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersecurity, Logging, technische Dokumentation und Kundenanweisungen.

Uebersetzen Sie Artikel 16 in Produkt-Gates. Discovery fragt, ob das Feature KI-basiert ist und ob ein Hochrisiko-Kontext moeglich ist. Design Review erfasst Zweck, Datenfluesse, Modellquelle, Aufsicht, Logging, Tests und Grenzen. Vendor Review sammelt Downstream-Dokumentation. Release Readiness bestaetigt Nachweise, Kundenanweisungen, Monitoring und Eskalation.

Fehler 4: Systemanbieterpflichten mit GPAI-Modellpflichten vermischen

Pflichten fuer General-Purpose-AI-Modelle sind eine eigene Spur. Artikel 53 betrifft Anbieter solcher Modelle und umfasst technische Dokumentation, Informationen fuer nachgelagerte KI-Systemanbieter, Copyright-Policy, eine oeffentliche Zusammenfassung der Trainingsinhalte, Zusammenarbeit mit Behoerden sowie Codes of Practice oder harmonisierte Standards. Einige Open-Source-Ausnahmen koennen greifen, aber nicht fuer GPAI-Modelle mit systemischem Risiko.

Ein Produktfeature auf Basis eines Drittmodells macht das SaaS-Unternehmen nicht automatisch zum GPAI-Modellanbieter. Zugleich beseitigt ein Drittmodell nicht die Moeglichkeit, dass das Unternehmen Anbieter des verkauften KI-Systems ist. Die Rolle haengt vom Asset, Angebot, Zweck und Kontrollgrad ab.

Halten Sie zwei Spuren getrennt: Bietet das Unternehmen ein KI-System an Kunden an, und welche Risikokategorie gilt? Bietet es ein General-Purpose-AI-Modell oder eine Modell-API an? So landet nicht die falsche Checkliste beim falschen Asset.

Fehler 5: Kundenunterlagen erst erstellen, wenn Sales fragt

Anbieterpflichten werden kommerziell, sobald Unternehmenskunden wissen wollen, was das KI-Feature tut, wofuer es gedacht ist, welche Grenzen gelten, wie menschliche Aufsicht funktioniert, wie Aenderungen ueberwacht werden und welche Informationen der Kunde fuer eigene Pflichten braucht.

Wenn Kundenunterlagen erst nach Vertriebsclaims entstehen, muessen Product Copy, Vertragsantworten, Help-Center-Texte, Security-Frageboegen und Rechtsanalyse unter Druck abgeglichen werden. So versprechen Teams leicht einen zu breiten Zweck oder Kontrollen, die nicht belegt sind.

Machen Sie Kundenunterlagen zu einem Release-Artefakt: Zweck, Grenzen, erlaubte und nicht erlaubte Nutzung, erwartete menschliche Aufsicht, Monitoring, Kundenverantwortung, Aenderungskommunikation und Supportwege.

Fehler 6: Nachweise ueber Tools verlieren

Nachweise entstehen in Tickets, Architekturunterlagen, Vendor-Portalen, Repositories, Testergebnissen, Model Cards, Risikobewertungen, Release-Freigaben, Help-Center-Entwuerfen, Monitoring-Dashboards, Incident Records und Kundencommitments. Ohne Karte kann die Organisation die Arbeit erledigt haben und sie trotzdem nicht beweisen.

Fuehren Sie deshalb einen Anbieterpflichten-Record, der auf die aktuelle Quelle der Wahrheit verweist. Er dupliziert nicht jedes Artefakt, sondern verbindet Rollenpruefung, Klassifikation, technische Dokumentation, Vendor-Informationen, Kundenanweisungen, Monitoring, Korrekturmassnahmen und Reassessment-Trigger.

Fehler 7: Wesentliche Aenderungen und Zweckwechsel ignorieren

KI-Systeme veraendern sich nach dem Launch. Teams fuegen Datenquellen hinzu, aendern Schwellenwerte, tauschen Anbieter, reduzieren menschliche Kontrolle oder machen aus einer assistiven Ausgabe eine staerker automatisierte Empfehlung. Solche Aenderungen koennen Rolle, Risiko und Nachweise beeinflussen.

Definieren Sie Trigger vor dem Launch. Oeffnen Sie den Record wieder, wenn sich Zweck, Kundensegment, Automatisierungsgrad, Modellverhalten, Vendor-Dokumentation oder regulierte Nutzung aendern oder ein Incident zeigt, dass Annahmen unvollstaendig waren.

Was als Naechstes zu tun ist

Waehlen Sie einen KI-Workflow, der kurz vor Launch steht, bereits in Kundenpruefung ist oder unklare Antworten erzeugt. Erstellen Sie einen einseitigen Anbieterpflichten-Record mit KI-Asset, Zweck, Rollenentscheidung, Klassifikation, Vendor-Abhaengigkeit, Pflichten, Nachweis-Owner, Dokumentationsort, Kundenanweisungen, Monitoring, Korrekturmassnahmen und Reassessment-Triggern.

Verbinden Sie diesen Record mit normaler Produktlieferung: Provider-Status in Discovery, Klassifikation im Design Review, Downstream-Dokumentation im Vendor Review, Kundenanweisungen in Release Readiness und Reassessment im Change Management.

FAQ

Was sollten Teams ueber Anbieterpflichten verstehen?

Teams sollten verstehen, wann Anbieterpflichten gelten koennen, welche Produkt- oder Modellrolle das Unternehmen spielt, welche operativen Aenderungen erforderlich sind und welche Nachweise den laufenden Workflow belegen.

Warum sind Anbieterpflichten praktisch wichtig?

Sie bestimmen, wie Teams KI-Risiken eingrenzen, Verantwortung zuweisen, Entscheidungen dokumentieren, Kundenanweisungen erstellen, Aenderungen ueberwachen und Kunden-, Behoerden- oder Auditfragen beantworten.

Was ist der groesste Fehler?

Der groesste Fehler ist, Anbieterpflichten als einmalige Rechtsauslegung zu behandeln statt als wiederholbaren Workflow mit Ownern, Triggern, Nachweisen, Kundenunterlagen, Monitoring und Eskalation.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 16: Obligations of providers of high-risk AI systems.
• European Commission AI Act Service Desk, Article 25: Responsibilities along the AI value chain.
• European Commission AI Act Service Desk, Article 53: Obligations for providers of general-purpose AI models.