Alle Artikel
KI-Verordnung2. April 202612 min

Provider vs. Deployer: Welche Pflichten habe ich unter der KI-Verordnung?

Anbieter oder Betreiber? Die KI-Verordnung unterscheidet strikt - mit unterschiedlichen Pflichten, Kosten und Risiken. So finden Sie heraus, welche Rolle Sie haben.

Warum die Unterscheidung so wichtig ist

Die KI-Verordnung (Verordnung (EU) 2024/1689) ist seit dem 1. August 2024 in Kraft. Die Pflichten für Hochrisiko-KI-Systeme nach Anhang III greifen ab dem 2. August 2026. Wer dagegen verstößt, riskiert Bußgelder von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes (Art. 99 Abs. 3).

Aber bevor Sie anfangen, Pflichten abzuarbeiten, müssen Sie eine Frage beantworten: Sind Sie Provider oder Deployer?

Die Antwort bestimmt alles. Ein Provider muss ein Risikomanagementsystem aufbauen, eine Konformitätsbewertung durchführen, technische Dokumentation erstellen und ein Qualitätsmanagementsystem betreiben. Ein Deployer muss das System gemäß der Gebrauchsanweisung einsetzen, die menschliche Aufsicht sicherstellen und bestimmte Aufzeichnungspflichten erfüllen. Der Aufwand unterscheidet sich um Größenordnungen.

Das Problem: Viele Unternehmen wissen nicht, auf welcher Seite sie stehen. Und manche sind Provider, ohne es zu ahnen.

Wann Sie Provider sind (Art. 3 Nr. 3)

Provider ("Anbieter") ist, wer ein KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt. Die Definition in Art. 3 Nr. 3 ist bewusst weit gefasst. Entscheidend ist nicht, ob Sie den Code selbst geschrieben haben. Entscheidend ist, wer das System auf den Markt bringt und dafür die Verantwortung übernimmt.

Typische Provider-Konstellationen

Sie entwickeln ein KI-System selbst. Ihr Data-Science-Team trainiert ein Modell für die interne Kreditrisikobewertung. Auch wenn Sie das System nur intern einsetzen: Sobald es ein Hochrisiko-System ist (Kreditwürdigkeitsprüfung fällt unter Anhang III Nr. 5 Buchstabe b), sind Sie Provider.

Sie lassen entwickeln und bringen es unter Ihrem Namen auf den Markt. Ein externer Dienstleister baut für Sie ein KI-gestütztes Bewerbermanagement-Tool. Auf der Oberfläche steht Ihr Logo, Ihre Kunden kaufen es von Ihnen. Sie sind Provider - nicht der Dienstleister.

Sie vertreiben ein White-Label-Produkt unter eigener Marke. Der Hersteller hat das System gebaut, aber nach außen treten Sie als Anbieter auf. Art. 3 Nr. 3 knüpft an den Namen und die Marke an - Sie sind Provider.

Wann Sie Deployer sind (Art. 3 Nr. 4)

Deployer ("Betreiber") ist, wer ein KI-System unter eigener Verantwortung einsetzt. Die Definition in Art. 3 Nr. 4 schließt ausdrücklich den Einsatz im Rahmen einer beruflichen Tätigkeit ein. Privatpersonen, die eine KI-App auf dem Handy nutzen, sind keine Deployer im Sinne der Verordnung.

Typische Deployer-Konstellationen

Sie kaufen ein fertiges KI-System und setzen es ein. Ihr Unternehmen lizenziert ein KI-gestütztes Tool zur Betrugserkennung von einem spezialisierten Anbieter. Sie konfigurieren es für Ihre Daten, aber Sie verändern das Modell nicht. Sie sind Deployer.

Sie nutzen eine SaaS-Lösung mit KI-Funktionen. Ihr HR-Tool hat eine KI-gestützte Vorauswahl von Bewerbungen integriert. Sie nutzen die Funktion so, wie der Anbieter sie bereitstellt. Sie sind Deployer.

Sie setzen ein Open-Source-Modell unverändert ein. Sie laden ein vortrainiertes Modell herunter und setzen es für einen vom Modellhersteller vorgesehenen Zweck ein, ohne es zu modifizieren. Sie sind Deployer.

Die Falle: Wann ein Deployer zum Provider wird (Art. 25)

Art. 25 ist die Vorschrift, die in der Praxis die meisten Probleme verursachen wird. Sie regelt, wann ein Deployer die vollen Provider-Pflichten übernehmen muss. Drei Szenarien:

1. Sie bringen das System unter eigenem Namen oder eigener Marke in Verkehr (Art. 25 Abs. 1 Buchstabe a)

Sie kaufen ein KI-System, kleben Ihr Logo drauf und verkaufen es weiter. Klassisches Rebranding. Ab diesem Moment sind Sie Provider mit allen Pflichten. Der ursprüngliche Hersteller bleibt daneben bestehen, aber Sie können sich nicht mehr auf seine Konformitätserklärung allein verlassen.

2. Sie ändern die Zweckbestimmung eines Hochrisiko-Systems (Art. 25 Abs. 1 Buchstabe b)

Der Anbieter hat das System für einen bestimmten Zweck entwickelt und dokumentiert. Sie setzen es für etwas anderes ein. Beispiel: Ein System zur Analyse von Kundenverhalten wird für die Bewertung von Mitarbeitern umfunktioniert. Die ursprüngliche Konformitätsbewertung deckt diesen Einsatzzweck nicht ab. Sie werden Provider für den neuen Zweck.

3. Sie nehmen eine wesentliche Veränderung vor (Art. 25 Abs. 1 Buchstabe c)

"Wesentliche Veränderung" ist in Art. 3 Nr. 23 definiert: eine Änderung, die vom Anbieter in der ursprünglichen Konformitätsbewertung nicht vorgesehen war und die Konformität des Systems mit den Anforderungen beeinflussen kann oder die Zweckbestimmung ändert.

In der Praxis heißt das: Wenn Sie ein Hochrisiko-System so verändern, dass die ursprüngliche Risikobewertung nicht mehr greift, sind Sie Provider für die veränderte Version. Das betrifft insbesondere das Nachtrainieren mit eigenen Daten, wenn dadurch das Systemverhalten signifikant verändert wird.

Die Schwelle liegt nicht bei jeder kleinen Konfigurationsänderung. Aber sie liegt niedriger, als viele denken. Wer ein vortrainiertes Modell mit eigenen Datensätzen feinabstimmt und dadurch das Verhalten in einer Weise verändert, die der ursprüngliche Anbieter nicht vorgesehen hat, sollte davon ausgehen, dass Art. 25 greift.

Provider-Pflichten im Detail

Wer als Provider eines Hochrisiko-KI-Systems eingestuft wird, muss ab dem 2. August 2026 (Anhang III) bzw. ab dem 2. August 2027 (Anhang I) ein umfassendes Pflichtenprogramm erfüllen. Hier die vollständige Checkliste:

Risikomanagementsystem (Art. 9) Ein kontinuierlicher, iterativer Prozess über den gesamten Lebenszyklus des Systems. Identifikation und Analyse bekannter und vorhersehbarer Risiken, Bewertung möglicher Fehlanwendungen, Umsetzung geeigneter Risikominderungsmaßnahmen.

Daten-Governance (Art. 10) Trainings-, Validierungs- und Testdaten müssen nach bestimmten Qualitätskriterien aufbereitet werden. Dazu gehören Relevanz, Repräsentativität, Fehlerfreiheit und Vollständigkeit. Bei Hochrisiko-Systemen, die mit Daten trainiert werden, müssen die Datensätze statistisch geeignet sein.

Technische Dokumentation (Art. 11) Vor dem Inverkehrbringen muss eine technische Dokumentation erstellt werden, die den Nachweis der Konformität ermöglicht. Anhang IV listet die konkreten Inhalte auf: allgemeine Beschreibung, Designspezifikationen, Monitoring, Risikomanagement, Änderungsprotokoll.

Aufzeichnungspflichten / Logging (Art. 12) Hochrisiko-KI-Systeme müssen technisch in der Lage sein, Ereignisse automatisch aufzuzeichnen (Logs). Die Logs müssen die Rückverfolgbarkeit des Systemverhaltens ermöglichen. Mindestanforderungen definiert Art. 12 Abs. 2.

Transparenz und Gebrauchsanweisung (Art. 13) Das System muss so gestaltet sein, dass Deployer es angemessen verstehen und nutzen können. Die Gebrauchsanweisung muss unter anderem Zweckbestimmung, Leistungskennzahlen, bekannte Einschränkungen und Maßnahmen zur menschlichen Aufsicht enthalten.

Menschliche Aufsicht (Art. 14) Das System muss so konzipiert sein, dass natürliche Personen es wirksam überwachen können. Die Aufsichtsmaßnahmen müssen dem Risiko, dem Autonomiegrad und dem Einsatzkontext angemessen sein.

Genauigkeit, Robustheit und Cybersicherheit (Art. 15) Hochrisiko-Systeme müssen ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen und während ihres gesamten Lebenszyklus aufrechterhalten. Leistungskennzahlen müssen in der Gebrauchsanweisung angegeben werden.

Qualitätsmanagementsystem (Art. 17) Provider müssen ein dokumentiertes Qualitätsmanagementsystem einrichten. Dieses umfasst unter anderem: Strategien zur Einhaltung der Verordnung, Techniken und Verfahren für Design und Entwicklung, Verfahren für das Datenmanagement, Risikomanagement, Post-Market-Monitoring und Korrekturmaßnahmen.

Konformitätsbewertung (Art. 43) Vor dem Inverkehrbringen muss eine Konformitätsbewertung durchgeführt werden. Je nach Systemtyp reicht eine interne Kontrolle (Anhang VI) oder es ist die Einschaltung einer benannten Stelle (Anhang VII) erforderlich. Biometrische Identifizierung erfordert in der Regel eine externe Bewertung.

EU-Konformitätserklärung und CE-Kennzeichnung (Art. 47, 48, 49) Nach erfolgreicher Konformitätsbewertung stellt der Provider eine EU-Konformitätserklärung aus und bringt die CE-Kennzeichnung am System an. Die Konformitätserklärung muss die in Anhang V genannten Informationen enthalten.

Registrierung (Art. 49) Hochrisiko-KI-Systeme müssen vor dem Inverkehrbringen in der EU-Datenbank registriert werden. Ohne Registrierung kein rechtmäßiges Inverkehrbringen.

Deployer-Pflichten im Detail

Die Deployer-Pflichten sind deutlich schlanker, aber keineswegs trivial. Die Kernvorschriften finden sich in Art. 26 und 27.

Einsatz gemäß Gebrauchsanweisung (Art. 26 Abs. 1) Deployer müssen das System so einsetzen, wie es die Gebrauchsanweisung des Providers vorsieht. Das klingt banal, hat aber praktische Konsequenzen: Wer ein System außerhalb der dokumentierten Parameter einsetzt, verstößt gegen seine Deployer-Pflichten und kann sich im Schadensfall nicht auf den Provider berufen.

Menschliche Aufsicht (Art. 26 Abs. 2) Die Personen, die die menschliche Aufsicht ausüben, müssen die nötige Kompetenz, Ausbildung und Befugnis haben. Der Deployer muss sicherstellen, dass diese Personen tatsächlich in der Lage sind, die Aufsichtsfunktion wahrzunehmen.

Eingabedaten (Art. 26 Abs. 4) Soweit der Deployer Kontrolle über die Eingabedaten hat, muss er sicherstellen, dass diese für die Zweckbestimmung des Systems relevant und hinreichend repräsentativ sind.

Monitoring und Meldepflichten (Art. 26 Abs. 5) Deployer müssen den Betrieb des Systems überwachen. Stellen sie ein Risiko im Sinne von Art. 79 fest, müssen sie den Provider und die zuständige Marktüberwachungsbehörde informieren. Bei schwerwiegenden Vorfällen besteht eine direkte Meldepflicht.

Aufbewahrung der Logs (Art. 26 Abs. 6) Deployer müssen die vom System automatisch erzeugten Protokolle aufbewahren - mindestens sechs Monate, sofern keine anderen Rechtsvorschriften längere Fristen vorsehen.

Datenschutz-Folgenabschätzung (Art. 26 Abs. 9, Art. 27) Für bestimmte Hochrisiko-Systeme (insbesondere solche nach Anhang III Nr. 1-8) muss der Deployer vor dem Einsatz eine Grundrechte-Folgenabschätzung durchführen (Art. 27). Diese geht über eine DSGVO-DSFA hinaus und umfasst die spezifischen Auswirkungen des KI-Systems auf betroffene Personen.

Informationspflichten gegenüber Betroffenen (Art. 26 Abs. 11, 12) Deployer, die im Bereich der öffentlichen Verwaltung oder für bestimmte Hochrisiko-Systeme (Anhang III Nr. 1, 6, 7, 8) tätig sind, müssen die Nutzung des KI-Systems öffentlich registrieren. Bei Emotionserkennungs- oder biometrischen Kategorisierungssystemen müssen betroffene Personen informiert werden.

KI-Kompetenz (Art. 4) Seit dem 2. Februar 2025 gilt für alle KI-Systeme - nicht nur Hochrisiko-Systeme - die Pflicht zur KI-Kompetenz. Deployer müssen sicherstellen, dass ihr Personal, das KI-Systeme betreibt und nutzt, über ein ausreichendes Maß an KI-Kompetenz verfügt.

Praxisszenarien

"Wir nutzen das Recruiting-Tool von Anbieter X" Sie setzen ein fertiges KI-System eines externen Anbieters für die Vorauswahl von Bewerbungen ein, ohne es zu verändern. Recruiting-Tools fallen unter Anhang III Nr. 4. Sie sind Deployer. Ihre Pflichten: Einsatz gemäß Gebrauchsanweisung, menschliche Aufsicht durch geschultes Personal, Eingabedatenqualität, Log-Aufbewahrung, Grundrechte-Folgenabschätzung vor Einsatzbeginn. Der Provider ist verantwortlich für die Konformitätsbewertung, technische Dokumentation und das Risikomanagementsystem.

"Wir haben ein LLM feinabgestimmt" Sie nehmen ein vortrainiertes Large Language Model und trainieren es mit eigenen Daten nach, um es für einen spezifischen Hochrisiko-Einsatz (z.B. Unterstützung bei Kreditentscheidungen) zu nutzen. Das Fine-Tuning verändert das Modellverhalten für einen Zweck, den der ursprüngliche Modellanbieter nicht spezifisch vorgesehen hat. Sie haben eine wesentliche Veränderung im Sinne von Art. 3 Nr. 23 vorgenommen. Ergebnis: Sie werden Provider nach Art. 25 - mit allen Pflichten, einschließlich Konformitätsbewertung und technischer Dokumentation für das modifizierte System.

"Wir haben unser eigenes System gebaut" Ihr Unternehmen hat intern ein KI-System zur Bonitätsbewertung entwickelt und setzt es selbst ein. Sie sind Provider und Deployer zugleich. Sie müssen beide Pflichtenkataloge erfüllen. Dass das System nie den internen Bereich verlässt, ändert daran nichts - Art. 3 Nr. 3 erfasst auch das Inbetriebnehmen für eigene Zwecke.

"Wir vertreiben ein White-Label-Produkt" Ein Softwarehersteller hat ein KI-System zur Dokumentenanalyse entwickelt. Sie lizenzieren es, integrieren es in Ihre Plattform und vertreiben es unter Ihrem Markennamen an Ihre Kunden. Nach Art. 25 Abs. 1 Buchstabe a sind Sie Provider. Die Konformitätserklärung des Herstellers reicht nicht. Sie müssen eine eigene Konformitätsbewertung durchführen oder vertraglich sicherstellen, dass der ursprüngliche Hersteller dies in einer Weise tut, die Ihren Markteintritt abdeckt. In der Praxis brauchen Sie einen wasserdichten Vertrag mit dem Hersteller, der Verantwortlichkeiten, Informationspflichten und Haftungsfragen regelt.

Was Sie jetzt tun sollten

Die Pflichten für Hochrisiko-KI-Systeme nach Anhang III gelten ab dem 2. August 2026. Das klingt nach viel Zeit. Es ist wenig.

Schritt 1: Inventarisieren Sie Ihre KI-Systeme Erstellen Sie ein vollständiges Inventar aller KI-Systeme in Ihrem Unternehmen. Nicht nur die offensichtlichen, auch die, die in SaaS-Tools, eingekauften Plattformen und internen Prototypen stecken.

Schritt 2: Klassifizieren Sie Ihre Rolle pro System Für jedes System: Sind Sie Provider, Deployer oder beides? Prüfen Sie insbesondere die Art. 25-Szenarien. Haben Sie Systeme modifiziert, umgewidmet oder unter eigener Marke vertrieben?

Schritt 3: Prüfen Sie die Risikoeinstufung Fällt das System unter Anhang III? Unter Anhang I? Unter die verbotenen Praktiken nach Art. 5 (die seit dem 2. Februar 2025 gelten)? Die Risikoeinstufung bestimmt den Pflichtenkatalog.

Schritt 4: Identifizieren Sie Ihre Lücken Vergleichen Sie Ihren Ist-Zustand mit den Anforderungen. Provider brauchen ein Risikomanagementsystem, technische Dokumentation, ein Qualitätsmanagementsystem. Deployer brauchen geschultes Aufsichtspersonal, Log-Aufbewahrung, Grundrechte-Folgenabschätzungen. Was fehlt?

Schritt 5: Verträge prüfen Wenn Sie als Deployer auf Provider angewiesen sind: Stellen die bestehenden Verträge sicher, dass Sie Ihre Pflichten erfüllen können? Erhalten Sie die Gebrauchsanweisung, die Leistungskennzahlen, die Informationen zur Zweckbestimmung? Wenn nicht, müssen die Verträge nachverhandelt werden.

Die KI-Verordnung bestraft vor allem diejenigen, die zu spät anfangen. Bei Verstößen gegen die Hochrisiko-Pflichten drohen Bußgelder von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes (Art. 99 Abs. 3). Bei Verstößen gegen die verbotenen Praktiken sogar bis zu 35 Millionen Euro oder 7 % (Art. 99 Abs. 2). Falsche oder unvollständige Angaben gegenüber Behörden kosten bis zu 7,5 Millionen Euro oder 1 % (Art. 99 Abs. 4).

Der erste Schritt ist immer derselbe: Wissen, wo Sie stehen. Alles andere folgt daraus.

WP

Autor

Werner Plutat

Legal Engineer x AI

The Legal Engineer's Daily Brief

KI, Legal Tech & Automatisierung - 3x pro Woche.

Abonnieren

Dieses Thema betrifft Ihr Unternehmen?

Lassen Sie uns in 30 Minuten klären, wie Sie die Anforderungen konkret umsetzen - mit funktionierender Technologie statt Foliensätzen.

Erstgespräch vereinbaren