Art. 25 EU AI Act: Wann der Betreiber zum Anbieter wird

Die meisten Unternehmen ordnen sich im EU AI Act schnell und mit einer gewissen Erleichterung ein: Wir entwickeln keine KI, wir setzen sie ein — also sind wir Betreiber (Deployer), nicht Anbieter (Provider). Die Betreiberpflichten aus Artikel 26 sind überschaubar, der schwere Pflichtenkatalog aus Artikel 16 liegt beim Hersteller. Diese Einordnung ist richtig — bis zu dem Moment, in dem sie es nicht mehr ist. Artikel 25 der EU-KI-Verordnung (VO (EU) 2024/1689) beschreibt genau die Konstellationen, in denen ein Betreiber, Händler, Einführer oder sonstiger Dritter rechtlich zum Anbieter wird — ohne je eine Zeile Modellcode geschrieben zu haben.

Das ist keine akademische Randfrage. Ein Rollenwechsel nach Artikel 25 zieht den vollständigen Anbieterpflichtenkatalog nach sich: Qualitätsmanagementsystem, technische Dokumentation, Risikomanagement, Konformitätsbewertung, CE-Kennzeichnung, Registrierung in der EU-Datenbank. Wer diesen Wechsel unbemerkt vollzieht, steht am Enforcement-Datum am 02.12.2027 mit einem Pflichtenpaket da, das er nie eingeplant hat.

Die drei Auslöser des Rollenwechsels

Artikel 25 Absatz 1 nennt drei Tatbestände. Jeder einzelne genügt.

Erstens: das eigene Label. Wer ein bereits in Verkehr gebrachtes oder in Betrieb genommenes Hochrisiko-KI-System unter dem eigenen Namen oder der eigenen Marke anbietet, gilt als dessen Anbieter. Der klassische Fall ist das White-Labeling: Ein Beratungshaus lizenziert eine fremde Scoring-Engine und vertreibt sie als eigenes Produkt. Nach außen erscheint nur die eigene Marke — und damit trifft die Verordnung die eigene Organisation. Vertragliche Vereinbarungen mit dem ursprünglichen Hersteller können die interne Lastenverteilung regeln, sie ändern aber nichts an der regulatorischen Adressierung.

Zweitens: die wesentliche Änderung. Wer ein Hochrisiko-KI-System so verändert, dass es eine „wesentliche Änderung" im Sinne von Artikel 3 Nr. 23 erfährt und weiterhin hochrisiko bleibt, wird zum Anbieter. Wesentlich ist eine Änderung, die bei der ursprünglichen Konformitätsbewertung nicht vorgesehen oder geplant war und die entweder die Konformität mit den Anforderungen aus Kapitel III Abschnitt 2 beeinflusst oder die Zweckbestimmung verändert. Der Maßstab ist also nicht der technische Aufwand, sondern die Frage: Deckt die vorhandene Konformitätsbewertung diesen Zustand noch ab? Ein Feintuning auf eigene Daten, ein ausgetauschter Schwellenwert in der Entscheidungslogik, ein neu zugeschaltetes Modul — all das kann diese Schwelle reißen, obwohl es im Projektplan wie eine Konfigurationsaufgabe aussieht.

Drittens: die Umwidmung. Der praktisch heikelste Fall. Wer die Zweckbestimmung eines KI-Systems ändert — ausdrücklich auch die eines Allzweck-KI-Systems —, das bislang nicht als Hochrisiko eingestuft war, und es dadurch zu einem Hochrisiko-System macht, wird zum Anbieter dieses Systems. Ein allgemeines Sprachmodell ist als solches kein Hochrisiko-System. Wird es in einen Prozess eingebaut, der Bewerbungen vorsortiert oder Kreditanträge bewertet, entsteht ein Anwendungsfall nach Anhang III — und der Rollenwechsel findet bei demjenigen statt, der diese Zweckbestimmung gesetzt hat. Das ist in aller Regel das einsetzende Unternehmen, nicht der Modellhersteller.

Was mit dem ursprünglichen Anbieter passiert

Artikel 25 Absatz 2 zieht die Konsequenz: Der Anbieter, der das System zuerst in Verkehr gebracht hat, gilt für dieses konkrete System nicht mehr als Anbieter. Die Rolle wandert, sie verdoppelt sich nicht.

Damit der neue Anbieter seine Pflichten überhaupt erfüllen kann, verpflichtet die Verordnung den ursprünglichen Anbieter zu enger Zusammenarbeit: Er stellt die erforderlichen Informationen bereit und gewährt den vernünftigerweise zu erwartenden technischen Zugang sowie sonstige Unterstützung. Diese Pflicht entfällt allerdings, wenn der ursprüngliche Anbieter klar festgelegt hat, dass sein System nicht in ein Hochrisiko-KI-System umgewandelt werden darf. Genau diese Klausel taucht inzwischen regelmäßig in Nutzungsbedingungen von Modell- und Plattformanbietern auf. Wer sie überliest und den Anwendungsfall trotzdem baut, wird zum Anbieter — und steht ohne den Zugang zu Trainingsdaten, Evaluationsergebnissen und Architekturdokumentation da, den die technische Dokumentation nach Artikel 11 verlangt.

Ein Sonderfall steht in Absatz 3: Ist das Hochrisiko-KI-System eine Sicherheitskomponente eines Produkts nach Anhang I Abschnitt A, gilt der Produkthersteller als Anbieter. Hier bleibt die Verantwortung dort, wo auch die produktrechtliche Konformitätsbewertung stattfindet.

Die Vertragspflicht aus Absatz 4

Artikel 25 Absatz 4 richtet sich an die Lieferkette unterhalb des Anbieters. Dritte, die Werkzeuge, Dienste, Komponenten oder Prozesse liefern, die in ein Hochrisiko-KI-System eingebaut werden, müssen mit dem Anbieter schriftlich vereinbaren, welche Informationen, Fähigkeiten, technischen Zugänge und Unterstützungsleistungen nach dem allgemein anerkannten Stand der Technik nötig sind, damit der Anbieter seine Pflichten vollständig erfüllen kann. Ausgenommen sind Dritte, die Werkzeuge unter freier und quelloffener Lizenz bereitstellen — nicht jedoch Allzweck-KI-Modelle. Das Büro für Künstliche Intelligenz kann hierfür freiwillige Musterklauseln entwickeln.

Für die Praxis heißt das: Die Rollenfrage gehört in die Beschaffung, nicht in die nachgelagerte Rechtsprüfung. Wer Komponenten einkauft, sollte im Vertrag festhalten, welche Nachweise mitgeliefert werden und ab welcher Änderungstiefe die Rolle kippt.

Wie man den Rollenwechsel früh erkennt

Der gefährliche Punkt an Artikel 25 ist, dass der Auslöser fast nie als regulatorisches Ereignis auftritt. Er erscheint als Sprint-Ticket, als Prompt-Anpassung, als neuer Anwendungsfall im Fachbereich. Erkennbar wird er nur, wenn drei Dinge dokumentiert und laufend gepflegt sind:

• Zweckbestimmung je System. Nicht der technische Name des Systems, sondern der tatsächliche Einsatzzweck — festgehalten, versioniert und mit einem Verantwortlichen versehen.
• Änderungshistorie mit Nachweis. Jede Änderung an Modell, Daten, Schwellenwerten oder vorgelagerter Logik mit Zeitpunkt, Urheber und Begründung. Erst diese Spur macht im Nachhinein prüfbar, ob eine Änderung wesentlich im Sinne von Artikel 3 Nr. 23 war.
• Lieferantenlage. Welche Nutzungsbedingungen und vertraglichen Zusagen gelten, insbesondere ob der Vorlieferant eine Hochrisiko-Umwandlung ausgeschlossen hat.

Genau das ist der Unterschied zwischen einer einmaligen Einordnung und belastbarer Governance: Die Rollenfrage ist kein Zustand, sondern eine fortlaufend zu überwachende Eigenschaft des Systems. Welche Pflichten mit dem Rollenwechsel konkret zulaufen, hängt an der Einstufung selbst — dazu vertiefend hochrisiko-ki.com.

Nachweisbares Vertrauen entsteht dort, wo Zweckbestimmung, Änderungen und Lieferantenzusagen lückenlos belegt sind — nicht dort, wo die Rollenfrage einmalig beantwortet und danach nicht mehr angefasst wurde. Mehr zur AEGIRA Trust-Platform: aegira.ai.