Ungewollt zum KI-Provider werden
Die meisten Unternehmen, die KI nutzen, sind Deployer. Sie setzen fertige Systeme ein und tragen die entsprechenden Deployer-Pflichten. Die umfangreicheren Provider-Pflichten treffen sie nicht. Das ist die Theorie. In der Praxis kann ein Deployer jedoch schneller zum Provider werden als gedacht, oft ohne es zu bemerken.
Drei Wege vom Deployer zum Provider
Artikel 25 des EU AI Act definiert drei Szenarien, in denen ein Deployer zum Provider eines Hochrisiko-Systems wird und damit alle Provider-Pflichten übernimmt: Konformitätsbewertung, technische Dokumentation, CE-Kennzeichnung, Qualitätsmanagementsystem.
Das erste Szenario betrifft die Markennutzung. Wer ein bereits auf dem Markt befindliches Hochrisiko-KI-System unter eigenem Namen oder eigener Marke vertreibt, wird zum Provider. Das ist nachvollziehbar und in der Regel eine bewusste Entscheidung.
Das zweite Szenario betrifft wesentliche Modifikationen. Wer ein Hochrisiko-System so verändert, dass es nicht mehr der ursprünglichen Konformitätsbewertung entspricht oder einen neuen Verwendungszweck erhält, wird zum Provider. Auch das ist meist eine aktive Entscheidung, etwa beim Fine-Tuning mit eigenen Daten.
Das dritte Szenario ist das problematische: Wer die Zweckbestimmung eines KI-Systems so verändert, dass aus einem unkritischen System ein Hochrisiko-System wird, wird ebenfalls zum Provider. Und hier liegt die Falle.
Das GPAI-Problem
Die meisten Unternehmen nutzen heute Systeme mit allgemeinem Verwendungszweck. ChatGPT, Claude, Copilot und ähnliche Tools sind bewusst nicht für spezifische Anwendungsfälle vorgesehen. Ihre Zweckbestimmung ist breit: Textgenerierung, Analyse, Assistenz. Kein Hochrisiko.
Was passiert, wenn ein Mitarbeiter so ein System für Bewerberbewertungen nutzt? Oder für Leistungsbeurteilungen? Oder um Kreditanfragen vorzubewerten? Der Anwendungsfall fällt unter Annex III, also Hochrisiko. Das System war dafür nicht vorgesehen. Die Zweckbestimmung wurde faktisch geändert.
Die Verordnung spricht von Modifikation der Zweckbestimmung, definiert aber nicht präzise, was als Modifikation gilt. Reicht die bloße Nutzung? Oder braucht es aktive Anpassungen wie System-Prompts, Knowledge-Bases, Workflow-Integrationen? Die Leitlinien der EU-Kommission dazu stehen noch aus.
Warum das gefährlich ist
Die ersten beiden Szenarien sind steuerbar. Niemand setzt versehentlich seine Marke auf ein fremdes KI-System. Niemand trainiert versehentlich ein Modell neu. Das dritte Szenario ist anders. Es kann schleichend passieren, dezentral, ohne dass die Compliance-Verantwortlichen davon erfahren.
Ein Team im HR experimentiert mit ChatGPT für Vorauswahl. Ein Sachbearbeiter nutzt ein KI-Tool zur Risikobewertung von Kundenanfragen. Ein Abteilungsleiter baut einen internen Assistenten für Leistungsfeedback. Jeder einzelne Fall könnte den Schwenk vom Deployer zum Provider auslösen.
Die Konsequenzen sind erheblich. Provider-Pflichten für Hochrisiko-Systeme sind umfangreich: Risikomanagementsystem, technische Dokumentation, Konformitätsbewertung, EU-Datenbank-Registrierung, Post-Market-Monitoring. Der Aufwand ist ein Vielfaches dessen, was Deployer leisten müssen. Und das Unternehmen weiß möglicherweise nicht einmal, dass es diese Pflichten hat.
Die Provider-AGB-Falle
Die Anbieter der großen GPAI-Systeme wissen um dieses Risiko. In ihren Nutzungsbedingungen schließen sie Hochrisiko-Anwendungen oft explizit aus. Microsoft untersagt in seinen Enterprise-AI-Bedingungen Anwendungen mit erheblichen Auswirkungen auf Beschäftigung, Finanzen oder Grundrechte ohne angemessene menschliche Aufsicht. Google schließt klinische Anwendungen und medizinische Beratung aus.
Das verschärft die Situation. Wenn der ursprüngliche Provider klar kommuniziert hat, dass sein System nicht für Hochrisiko-Zwecke gedacht ist, hat er nach Artikel 25 möglicherweise keine Pflicht, dem ungewollten neuen Provider Dokumentation oder Unterstützung zu liefern. Das Unternehmen steht allein da.
Was KMU tun sollten
Der erste Schritt ist Bewusstsein. Mitarbeiter müssen wissen, welche Anwendungsfälle unter Annex III fallen. Das ist Teil der KI-Kompetenz nach Artikel 4. Wer nicht weiß, was Hochrisiko bedeutet, kann nicht erkennen, wann eine Nutzung problematisch wird.
Der zweite Schritt sind klare interne Richtlinien. Welche KI-Tools sind für welche Zwecke freigegeben? Wo sind die Grenzen? Ein explizites Verbot, allgemeine KI-Systeme für HR-Entscheidungen, Kreditbewertungen oder ähnliche Hochrisiko-Bereiche zu nutzen, schafft Klarheit.
Der dritte Schritt ist die richtige Toolauswahl. Für Hochrisiko-Anwendungen sollten Systeme eingesetzt werden, die explizit dafür vorgesehen und vom Anbieter entsprechend bewertet sind. Ein HR-Tool, das als Hochrisiko-System zertifiziert ist, macht das nutzende Unternehmen zum Deployer mit überschaubaren Pflichten. Ein Allzweck-Chatbot, der für dieselbe Aufgabe zweckentfremdet wird, macht es möglicherweise zum Provider.
Die Logik dahinter
Der EU AI Act folgt einem nachvollziehbaren Prinzip: Hochrisiko-Anwendungen erfordern spezialisierte, geprüfte Systeme. Die Verordnung will verhindern, dass Unternehmen Allzweck-KI für kritische Entscheidungen einsetzen, ohne dass jemand die Verantwortung für Qualität und Sicherheit übernimmt.
Wenn kein Provider diese Verantwortung trägt, weil das System nicht für diesen Zweck gedacht war, fällt sie an denjenigen, der es dennoch so einsetzt. Das ist die innere Logik von Artikel 25. Nicht Strafe, sondern Verantwortungszuweisung.
Für Unternehmen bedeutet das: Die Freiheit, KI-Tools flexibel einzusetzen, hat Grenzen. Wer diese Grenzen kennt und respektiert, bleibt Deployer. Wer sie ignoriert, wird ungewollt Provider und steht vor einem Compliance-Aufwand, der die ursprüngliche Zeitersparnis um ein Vielfaches übersteigt.
Über den Autor
Jochen Stier ist AI Compliance Experte mit über 20 Jahren Erfahrung in Prozessmanagement und IT Service Management. Er unterstützt deutsche KMUs dabei, die Anforderungen des EU AI Act systematisch und pragmatisch umzusetzen. Sein 5-Phasen Framework NADOVO verbindet regulatorische Anforderungen mit praktischer Umsetzbarkeit, ohne Enterprise-Budgets oder komplexe Tools.
Weiterführende Informationen:
