Provider und Deployer im EU AI Act: Wer haftet wofür?

Der EU AI Act regelt nicht nur, welche KI-Systeme zulässig sind, sondern auch wer für welche Pflichten einsteht. Die zentrale Trennung im Verordnungstext ist die zwischen Provider (Anbieter) und Deployer (Betreiber). Diese Rollen klingen technisch, sind in der Praxis aber der häufigste Konfliktpunkt zwischen Einkauf, Recht und IT — vor allem bei Hochrisiko-KI. Wer die Rollen verwechselt oder die Pflichtenteilung nicht sauber dokumentiert, riskiert nicht nur Bußgelder, sondern auch Streit in Lieferketten, in denen mehrere Unternehmen am selben Modell arbeiten. Die folgende Einordnung greift den Stand der Verordnung (EU) 2024/1689 mit den Klarstellungen des Digital Omnibus und ordnet die Pflichten für DE, EU27-Rest, UK und CH praxisnah ein.

Wer ist Provider, wer ist Deployer?

Die Begriffe sind in Art. 3 EU AI Act definiert. Provider ist, wer ein KI-System entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt. Deployer ist demgegenüber jede natürliche oder juristische Person, die ein KI-System unter eigener Verantwortung verwendet, sofern sie nicht im Rahmen einer persönlichen, nicht beruflichen Tätigkeit handelt. Auf den ersten Blick ist die Trennung klar: Wer baut, ist Provider. Wer benutzt, ist Deployer.

In der Praxis liegt die Komplexität in den Mischrollen. Ein Unternehmen, das ein zugekauftes Modell substanziell modifiziert, in eine eigene Marke einbettet oder den Zweck wesentlich verändert, wird unter Art. 25 selbst zum Provider — auch wenn es technisch nur ein Foundation Model nachgeschärft hat. Wer ein Hochrisiko-KI-System unter eigenem Namen anbietet, übernimmt damit die volle Providerpflicht, unabhängig davon, wer das Modell ursprünglich trainiert hat. Diese Umqualifikation ist der häufigste übersehene Pfad in der Pflichtenkette.

Die Providerpflichten im Überblick

Provider von Hochrisiko-KI-Systemen trifft das technisch und organisatorisch anspruchsvollere Pflichtenbündel. Art. 16 fasst die Kernpflichten zusammen: Konformitätsbewertung vor Markteintritt, technische Dokumentation gemäß Anhang IV, Risikomanagement gemäß Art. 9, Daten-Governance gemäß Art. 10, Protokollierung gemäß Art. 12, Transparenzpflichten gemäß Art. 13, menschliche Aufsicht gemäß Art. 14 sowie Genauigkeit, Robustheit und Cybersicherheit gemäß Art. 15. Hinzu kommen die Registrierung in der EU-Datenbank nach Art. 49, ein Qualitätsmanagementsystem nach Art. 17 und die CE-Kennzeichnung nach Art. 48.

Praktisch heißt das: Ein Provider muss zu jedem Zeitpunkt belegen können, dass das System die Anforderungen der Anhänge III und IV erfüllt, dass das Risikomanagement nicht punktuell, sondern als kontinuierlicher Prozess geführt wird und dass jede wesentliche Änderung am System dokumentiert, bewertet und gegebenenfalls neu zertifiziert wird. Die Last der Evidenz liegt vollständig beim Provider. Deployer dürfen sich auf die mitgelieferten Informationen verlassen, aber nicht blind: Wer offensichtliche Mängel ignoriert, verliert den Vertrauensschutz.

Die Deployerpflichten im Überblick

Deployerpflichten sind in Art. 26 gebündelt. Sie sind schmaler als die Providerpflichten, aber nicht weniger anspruchsvoll. Deployer müssen das System entsprechend der Bedienungsanleitung einsetzen, die menschliche Aufsicht sicherstellen, Input-Daten in dem Maße kontrollieren, in dem ihre Kontrolle möglich ist, das System auf Funktionieren überwachen, Logs aufbewahren und Vorfälle melden. Bei Hochrisiko-KI in Beschäftigungskontexten kommt nach Art. 26 Abs. 7 die Pflicht hinzu, betroffene Arbeitnehmer und ihre Vertretungen vor der Inbetriebnahme zu informieren. Bei öffentlicher Verwaltung und einigen weiteren Hochrisiko-Anwendungen ist nach Art. 27 eine Fundamental Rights Impact Assessment Pflicht.

Die schwierigste Deployerpflicht ist die Aufsichts- und Überwachungspflicht im laufenden Betrieb. Wer ein Hochrisiko-System einsetzt, muss organisatorisch sicherstellen, dass die menschliche Aufsicht nicht nur formal benannt, sondern operativ wirksam ist: ausreichend qualifiziertes Personal, klare Eskalationswege, dokumentierte Eingriffsmöglichkeiten. Audits prüfen genau dieses Zusammenspiel — und finden hier regelmäßig die größten Lücken.

Wo die Rollen verschwimmen

Drei Konstellationen sorgen in der Praxis für Streit. Erstens das White-Labeling: Wer ein Modell unter eigener Marke anbietet, wird zum Provider, auch wenn die technische Substanz von einem Dritten kommt. Zweitens das substanzielle Fine-Tuning: Wer ein Foundation Model so anpasst, dass sich Zweck oder Risiko verschieben, wechselt in die Providerrolle. Drittens der Eigenbau im Konzern: Eine Konzerngesellschaft, die für andere Konzerngesellschaften ein System bereitstellt, kann formal Provider sein, auch wenn intern keine Marktbeziehung besteht. In allen drei Fällen entscheidet die funktionale Betrachtung, nicht die Vertragsbezeichnung.

Für Unternehmen in DE und CH ist diese Klärung doppelt wichtig. Schweizer Unternehmen, die KI in EU-Märkte verkaufen, fallen über die Marktortregel des EU AI Act in den Anwendungsbereich, sobald ihre Outputs in der EU verwendet werden. Britische Anbieter trifft dieselbe Logik, ergänzt durch das eigene UK-Regime der Sektorregulatoren. Wer im EU27-Rest sitzt, hat dieselben Pflichten wie ein deutsches Unternehmen, bekommt aber je nach Mitgliedstaat unterschiedliche Marktaufsichtsbehörden zugewiesen.

Evidenz statt Selbstauskunft

Die Pflichtenteilung wird in Audits nicht über Erklärungen, sondern über Evidenz geprüft. Provider müssen belegen, dass technische Dokumentation, Risikomanagement und Post-Market-Monitoring lückenlos laufen. Deployer müssen belegen, dass sie die Provider-Informationen verstanden, die menschliche Aufsicht organisatorisch verankert und Vorfälle nachvollziehbar verarbeitet haben. Beide Seiten müssen zudem dokumentieren, wie sie miteinander kommunizieren — denn ohne nachvollziehbaren Informationsfluss zwischen Provider und Deployer kann keine Seite die eigene Pflicht vollständig erfüllen.

Genau hier setzt eine Trust-Infrastructure an. Sie macht die Schnittstelle zwischen Provider und Deployer prüffähig: Welche Version eines Modells wird betrieben? Welche Veränderung hat der Provider wann mitgeteilt? Welche Reaktion hat der Deployer dokumentiert? Welche Eskalation hat die menschliche Aufsicht ausgelöst? Solche Fragen sind die Substanz jedes ernsthaften AI-Act-Audits — und sie lassen sich nicht ex post rekonstruieren, sondern müssen laufend erzeugt werden.

Was bis zum 02.12.2027 zu tun ist

Bis zum 02.12.2027 — dem in der durch den Digital Omnibus klargestellten Fassung maßgeblichen Anwendbarkeitsdatum für die Kernpflichten bei Hochrisiko-KI — müssen sowohl Provider als auch Deployer ihre Pflichtenkette vollständig klären und prüffähig hinterlegen. Drei Schritte sind unausweichlich: erstens eine saubere Rollenzuordnung pro KI-System inklusive der Mischrollen aus Art. 25, zweitens eine Lücken­analyse gegen Art. 16 (Provider) bzw. Art. 26 (Deployer), drittens der Aufbau einer dauerhaft prüffähigen Evidenz für jede einzelne Pflicht. Wer diese Schritte erst kurz vor dem Stichtag angeht, wird die Tiefe der Anforderungen unterschätzen.

Mehr zur AEGIRA Trust-Platform und zur Pflichten-Modellierung zwischen Provider und Deployer: aegira.ai.