Der Nutzer möchte die Rolle des Anbieters im Kontext des EU AI Act verstehen und sie auf praktische Arbeit in KI-Governance oder Compliance anwenden.
Ein Anbieter ist eine Person, Organisation, Behörde, Agentur oder sonstige Stelle, die ein KI-System oder ein KI-Modell mit allgemeinem Verwendungszweck entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke auf den Markt bringt oder in Betrieb nimmt.
Nach dem EU AI Act ist ein Anbieter der Akteur, der ein KI-System oder ein KI-Modell mit allgemeinem Verwendungszweck entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke auf den Markt bringt oder in Betrieb nimmt. Die Rolle ist nicht auf Unternehmen beschränkt, die jede Codezeile selbst schreiben. Ein Unternehmen kann Anbieter werden, wenn es ein KI-System verpackt, brandet, wesentlich verändert oder als eigenes reguliertes Produkt beziehungsweise eigene regulierte Dienstleistung bereitstellt. Die zentralen Atlas-Konzepte sind provider, deployer, downstream-provider und intended-purpose. Der Anbieterstatus ist wichtig, weil die anspruchsvollsten Pflichten der Verordnung häufig den Akteur treffen, der für Design, Inverkehrbringen oder Systemkontrolle verantwortlich ist. Bei Hochrisiko-KI-Systemen wird vom Anbieter normalerweise erwartet, dass er die Compliance-Nachweise erstellt, bevor das System Nutzer erreicht. Bei GPAI-Modellen können Anbieterpflichten auch Modellentwickler treffen, deren Modelle von vielen nachgelagerten Systemen genutzt werden. Die Rolle sollte daher anhand von Verträgen, Branding, Kontrolle über den Zweck, Änderungsrechten und Verantwortung für Compliance-Nachweise geprüft werden.
Man kann sich einen Anbieter wie das Unternehmen vorstellen, dessen Name auf einem regulierten Produkt steht. Wenn eine Firma ein Medizinprodukt entwickelt, es unter ihrer Marke verkauft und Kunden mitteilt, wofür es bestimmt ist, werden Aufsichtsbehörden bei der Produkt-Compliance meist zuerst auf diese Firma schauen. Bei KI funktioniert es ähnlich. Der Anbieter ist nicht immer die Person, die im täglichen Betrieb auf den Knopf drückt; es ist der Akteur, der das System unter seinem Namen verfügbar macht, den vorgesehenen Zweck kontrolliert oder bewirkt, dass es in Betrieb genommen wird. Der Betreiber ist näher an der Organisation, die das Tool im operativen Alltag verwendet. Deshalb sollte die Bezeichnung der tatsächlichen Produktrolle folgen und nicht nur dem kommerziellen Titel im Vertrag.
Analogie
Ein Markenhersteller: Der Name auf dem Produkt zeigt häufig an, wer nachweisen muss, dass das Produkt rechtmäßig entwickelt und bereitgestellt wurde.
Die Anbieterklassifizierung ist wichtig, weil sie bestimmt, wer die schwerste Compliance-Last trägt. Wenn Ihre Organisation Anbieter ist, muss sie möglicherweise Risikomanagement, Designkontrollen, technische Dokumentation, Konformitätsbewertung, Gebrauchsanweisungen, Qualitätsmanagement, Monitoring, Korrekturmaßnahmen und Zusammenarbeit mit Behörden übernehmen. Besonders hoch ist das Risiko für Unternehmen, die Drittmodelle anpassen, KI-Tools als White-Label anbieten oder KI in Produkte integrieren, die unter der eigenen Marke verkauft werden. Wird die Rollenprüfung bis zur Vertragsunterzeichnung oder Markteinführung verschoben, kann die Organisation feststellen, dass Lieferantendokumente unvollständig sind und interne Nachweise nie gesammelt wurden. Eine frühe Rollenzuordnung hilft außerdem zu entscheiden, welche Informationen von vorgelagerten Lieferanten angefordert werden müssen, bevor Entwicklungs- und Beschaffungsentscheidungen schwer rückgängig zu machen sind.
Dringlichkeit
Eine falsche Anbieter-/Betreiberannahme kann kurz vor Markteinführung oder Kundendue-Diligence eine späte Compliance-Lücke erzeugen.
Ein Anbieter sollte die Rollenklassifizierung als Produkt-Governance-Entscheidung behandeln, nicht als Etikett, das die Rechtsabteilung am Ende ergänzt. Der Anbieter muss den vorgesehenen Zweck definieren, vorhersehbaren Fehlgebrauch verstehen, die Risikokategorie des Systems bestimmen und Nachweise führen, dass anwendbare Pflichten erfüllt wurden. Bei Hochrisiko-KI bedeutet das in der Regel einen qualitätsgesteuerten Prozess für Design, Tests, Dokumentation, Protokollierung, menschliche Aufsicht, Cybersicherheit, Marktüberwachung nach dem Inverkehrbringen und Behandlung schwerwiegender Vorfälle. Wenn die Organisation auf ein Drittmodell oder eine Komponente eines Dritten angewiesen ist, benötigt sie dennoch ausreichend vorgelagerte Informationen, um ihre eigenen Pflichten zu erfüllen. Diese Nachweise sollten mit Release-Gates, Lieferantenmanagement und Change-Control-Verfahren verknüpft sein, damit Verantwortlichkeit über die Zeit klar bleibt.
Die Anbieterrolle wird oft missverstanden, weil Teams sie mit Software-Urheberschaft gleichsetzen. Im EU AI Act können Kontrolle, Branding, Inverkehrbringen und vorgesehener Zweck ebenso wichtig sein wie die Frage, wer das Modell oder die Oberfläche ursprünglich programmiert hat.
Fehler 1: Die Annahme, ein externer Lieferant sei immer der Anbieter, führt dazu, dass ein Markenreseller oder Integrator eigene Pflichten übersieht.
Fehler 2: Wenn der vorgesehene Zweck eines KI-Systems geändert wird, ohne den Rollenstatus neu zu prüfen, kann eine betreiberähnliche Nutzung in Anbieter-Verantwortung umschlagen.
Diese Seite sollte provider mit deployer, downstream-provider und intended-purpose verbinden. Der Vergleich provider-vs-deployer ist die zentrale nächste Lektüre, während provider-vs-downstream-provider Verantwortungsverschiebungen entlang der KI-Lieferkette erklärt. Zusammen helfen diese Links Lesern, von der rechtlichen Definition zu Lieferkettenverantwortung, Rollenänderungen und praktischen Dokumentationspflichten zu gelangen. Außerdem unterstützen sie eine saubere interne Verlinkung von Definitionen zu Umsetzungsentscheidungen.