Der Nutzer möchte den Anbieter im Kontext des EU AI Act verstehen und dies auf praktische Arbeit in KI-Governance oder Compliance anwenden.
Verwenden Sie Anbieter für den Akteur, der ein KI-System oder GPAI-Modell unter eigenem Namen entwickelt, auf den Markt bringt oder in Betrieb nimmt; Betreiber ist der Akteur, der ein KI-System unter seiner Verantwortung nutzt.
Anbieter und Betreiber sind unterschiedliche Akteursrollen nach dem EU AI Act. Ein Anbieter ist der Akteur, der ein KI-System oder GPAI-Modell unter eigenem Namen oder eigener Marke entwickelt, entwickeln lässt, auf den Markt bringt oder in Betrieb nimmt. Ein Betreiber ist der Akteur, der ein KI-System unter seiner Verantwortung nutzt, ausgenommen rein persönliche nichtberufliche Tätigkeiten. Der Unterschied ist daher nicht einfach „Lieferant gegen Kunde“, denn ein Kunde kann Anbieter werden, wenn er ein System wesentlich verändert, umbrandet oder den vorgesehenen Zweck in regulierungsrelevanter Weise ändert. Die zentral verknüpften Atlas-Konzepte sind provider, deployer und ai-system. Anbieterpflichten konzentrieren sich meist auf Design, Compliance-Nachweise, Inverkehrbringen, Dokumentation und Marktüberwachung nach dem Inverkehrbringen. Betreiberpflichten konzentrieren sich meist auf verantwortliche Nutzung, Befolgung von Anweisungen, menschliche Aufsicht, operatives Monitoring, Qualität der Eingabedaten, soweit relevant, und Eskalation, wenn das System Risiken erzeugt. In gemischten Lieferketten kann eine Organisation für verschiedene Systeme, Versionen oder Einsatzkontexte sogar unterschiedliche Rollen innehaben.
Man kann Anbieter und Betreiber als Unterschied zwischen dem Bereitstellen eines Werkzeugs und der Nutzung dieses Werkzeugs am Arbeitsplatz verstehen. Ein Unternehmen, das eine sicherheitskritische Maschine herstellt und verkauft, ist für Design und Produkt-Compliance verantwortlich. Eine Fabrik, die die Maschine kauft und betreibt, ist dafür verantwortlich, sie korrekt zu nutzen, Mitarbeitende zu schulen, Anweisungen zu befolgen und Probleme zu überwachen. Bei KI ist es ähnlich. Der Anbieter muss in der Regel nachweisen, dass das System rechtmäßig gebaut und bereitgestellt wurde; der Betreiber muss meist nachweisen, dass es im realen Betriebskontext verantwortungsvoll genutzt wird. Beide Rollen sind wichtig, und selbst ein sicheres System kann scheitern, wenn es im falschen Kontext betrieben wird.
Analogie
Maschinenhersteller gegenüber Fabrikbetreiber: Der eine liefert das System, der andere nutzt es unter realen Arbeitsbedingungen.
Diese Unterscheidung ist wichtig, weil Compliance mit dem AI Act scheitert, wenn Pflichten der falschen Partei zugeordnet werden. Eine anbieterlastige Aufgabe wie technische Dokumentation oder Konformitätsbewertung kann nicht einfach auf einen Betreiber verschoben werden, dem Designnachweise fehlen. Eine betreiberlastige Aufgabe wie lokale menschliche Aufsicht oder Monitoring in einem Arbeitsprozess kann nicht allein durch den Anbieter gelöst werden. Auch der Zeitplan zählt: Pflichten zu verbotenen Praktiken und KI-Kompetenz gelten bereits seit dem 2. Februar 2025, GPAI-Pflichten gelten seit dem 2. August 2025, und Transparenzregeln sind ab dem 2. August 2026 vorgesehen. Die Rollenzuordnung muss daher vor Verträgen, Markteinführung oder operativem Rollout erfolgen. In der Beschaffung ist dies besonders wichtig, weil fehlende Lieferantennachweise ebenso wie fehlende lokale Aufsicht die Freigabe verzögern können.
Dringlichkeit
Eine falsche Rollenzuordnung kann dazu führen, dass beide Parteien glauben, die jeweils andere Seite besitze eine erforderliche Kontrolle; dadurch entsteht eine Prüfungs- und Durchsetzungslücke.
Die praktische Pflicht besteht darin, für jedes KI-System eine Rollenkarte zu erstellen und anschließend Kontrollen dem richtigen Akteur zuzuordnen. Anbieter sollten vorgesehenen Zweck, Risikoklassifizierung, Systemdesign, Tests, Anweisungen, erforderliche Konformitätsnachweise, Marktüberwachung nach dem Inverkehrbringen und Korrekturmaßnahmen dokumentieren. Betreiber sollten dokumentieren, wie das System genutzt wird, wer es beaufsichtigt, welche Anweisungen befolgt werden, welche Eingabedaten kontrolliert werden, wie Nutzer geschult werden und wie Vorfälle oder Fehlfunktionen eskaliert werden. Verträge sollten diese Aufteilung unterstützen, indem sie Informationsflüsse, Prüfungsunterstützung, Zusammenarbeit bei Vorfällen und Änderungsmitteilungen verlangen. Die Rollenkarte sollte erneut geprüft werden, wenn das System umgebrandet, wesentlich verändert, in ein anderes Produkt integriert oder für einen neuen Zweck genutzt wird.
Die größten Fehler entstehen, wenn die Rollenaufteilung als kommerzielles Etikett statt als rechtliche und operative Analyse behandelt wird. Ein Unternehmen kann im Vertrag Kunde sein und dennoch anbieterähnliche Verantwortung übernehmen, wenn es den Zweck des KI-Systems ändert oder es weiter bereitstellt.
Fehler 1: Jeden SaaS-Kunden als Betreiber zu bezeichnen, ignoriert Fälle, in denen der Kunde das System umbrandet, weiterverkauft oder wesentlich verändert.
Fehler 2: Die Annahme, Anbieterdokumentation ersetze lokale Betreiberaufsicht, lässt menschliche Prüfung, Mitarbeiterschulung und Monitoring im realen Einsatz undokumentiert.
Der zentrale Atlas-Vergleich ist provider-vs-deployer. Verwandte Begriffe sind provider, deployer, ai-system, downstream-provider, intended-purpose, conformity-assessment und documentation. Diese Seite sollte außerdem auf die Frage-Seiten zu Anbieter und Konformitätsbewertung verlinken. Sie gibt Lesern einen klaren Weg von der Rollentheorie zur Sammlung von Nachweisen, zu Verträgen und zu operativen Governance-Verantwortlichkeiten. Außerdem unterstützt sie eine saubere interne Verlinkung von Rollenbezeichnungen zu Kontrollen.