Drei Wochen vor dem Launch stellt die Juristin Ihres Teams die eine Frage, die Sie bisher für reine Formsache gehalten haben: “Sind wir Betreiber oder Anbieter?”
Das Bauchgefühl sagt: Betreiber. Anthropic, OpenAI oder wer auch immer Ihr Modellanbieter ist, hat das Modell gebaut. Sie haben lediglich einen System-Prompt geschrieben, Retrieval angebunden und Leitplanken ergänzt. Sie nutzen doch nur, was andere gebaut haben.
Das Bauchgefühl kann täuschen. Der EU AI Act hat dazu eine ganz konkrete Klausel.
Artikel 25 macht Sie unbemerkt zum Anbieter
Artikel 25(1) des Acts beschreibt drei Wege, auf denen ein Unternehmen, das als etwas anderes als ein Anbieter gestartet ist, zu einem wird: (a) Sie setzen Ihren Namen auf ein fremdes System, (b) Sie verändern es wesentlich, oder (c) Sie richten ein GPAI-Modell auf einen Hochrisiko-Einsatz aus. Der dritte Weg erwischt die meisten Teams, die auf einer Modell-API aufbauen. Weg (c) hängt an der Zweckbestimmung: Ein GPAI-Anbieter fasst die Zweckbestimmung seines Modells in der Regel sehr breit und deutlich außerhalb des Hochrisiko-Bereichs. Das Modell auf einen Hochrisiko-Einsatz auszurichten, ist also genau jene Änderung der Zweckbestimmung, die Artikel 25(1)(c) erfasst. Sie nehmen ein GPAI-Modell, das für sich genommen nicht hochriskant ist, und richten es auf einen Anwendungsfall aus, der es ist. Ab diesem Moment sind Sie der Anbieter eines KI-Systems. Anhang IV — die Pflicht zur technischen Dokumentation — ist jetzt Ihre Aufgabe: an Sie adressiert, von Ihnen zu erstellen.
Die meisten Teams, die 2026 KI im Unternehmen ausliefern, haben diese Klausel nie gelesen. Sie bringen etwas auf den Markt, das Lebensläufe vorsortiert, über Leistungsansprüche entscheidet oder Kreditanträge vorqualifiziert — und halten sich für Integratoren. Sie sind Anbieter. Es hat ihnen nur niemand gesagt.
Das falsche Denkmodell
Die meisten Teams gehen die KI-Compliance-Dokumentation mit der Frage an: “Was tut unser System, und wie beschreiben wir es?” Diese Formulierung unterstellt, das KI-System sei eine einzige Sache, end-to-end in einer Hand. Unter der Verordnung stapeln sich die Pflichten fast nie so.
Es gibt mindestens drei verschiedene Rollen, in denen Sie stecken können:
- Betreiber. Sie nutzen ein Hochrisiko-KI-System in eigener Verantwortung — typischerweise eines, das ein Anbieter gebaut und in Verkehr gebracht hat, auch wenn der seltsamste Fall weiter unten zeigt, dass das nicht zwingend ist. Ihre Pflichten stehen in Artikel 26: bestimmungsgemäß nutzen, überwachen, protokollieren, Betroffene informieren. Und wenn Sie eine öffentliche Stelle sind, eine private Einrichtung mit öffentlichem Auftrag oder Betreiber in einer der wenigen Anhang-III-Kategorien (Kreditwürdigkeit, Preisbildung in der Lebens- und Krankenversicherung), schulden Sie zusätzlich eine Grundrechte-Folgenabschätzung. Anhang IV erstellen Sie nicht.
- Anbieter eines KI-Systems auf Basis eines GPAI-Modells. Sie haben ein GPAI-Modell zu einem System verbaut, das durch seinen Einsatz hochriskant ist. Sie erstellen Anhang IV. Für die Modellebene verweisen Sie auf die Artikel-53-Dokumentation des GPAI-Anbieters; die Systemebene füllen Sie selbst.
- Anbieter über Artikel 25(1)(c). Sie haben etwas gekauft oder integriert, das in der Hand des Verkäufers nicht hochriskant war, es aber auf einen Hochrisiko-Einsatz ausgerichtet — und die Verordnung behandelt Sie nun als Anbieter dieses Systems. Dieselbe Anhang-IV-Pflicht wie oben, nur über einen anderen Weg.
(Es gibt auch den Grundfall — ein Hochrisiko-System komplett selbst zu bauen, ohne fremdes Modell darunter —, der Sie auf dem gewöhnlichen Weg zum Anbieter macht. Nur ist das nicht der Weg, der Teams erwischt, die auf einer Modell-API aufsetzen.)
Zwei der drei Rollen nehmen Sie für Anhang IV in die Pflicht. Die meisten Teams verorten sich in der ersten und erstarren, sobald das Formular nach Trainingsdaten fragt, die sie gar nicht haben. Sie haben sich falsch eingeordnet.
Die Rolle ist nicht die einzige Achse, auf der sich Pflichten stapeln. Auch die Risikoklassifizierungen schließen einander nicht aus: Ein System kann hochriskant sein und zugleich Transparenzpflichten aus Artikel 50 tragen; Art. 50(6) stellt ausdrücklich klar, dass diese Pflichten unbeschadet der Hochrisiko-Anforderungen gelten. Die Verordnung schichtet Pflichten übereinander; sie sortiert Sie nicht in ein einziges Fach. Die Risikostufen als Entweder-oder zu lesen, ist derselbe Fehler wie die falsche Rolleneinordnung — und genauso leicht gemacht.
Die Falle des Artikel 25(1)(c), in einfacheren Worten
Die Klausel klingt abstrakt; der Auslöser ist es nicht. Angenommen, Sie sind eine Krankenversicherung. Sie betreiben auf einer LLM-API einen Service-Chatbot, der Fragen zum Versicherungsschutz beantwortet. Mitten im Quartal fragt das Produktteam, ob er Interessenten nicht auch eine vorläufige Beitragsschätzung aus deren eigenen Angaben geben könne. Zwei Prompts und ein Lookup. Fertig.
Damit haben Sie die Zweckbestimmung eines GPAI-Modells geändert und es auf Risikobewertung und Preisbildung in der Krankenversicherung gerichtet — ein klarer Hochrisiko-Einsatz nach Anhang III (§5(c)). Artikel 25(1)(c) greift. Sie sind der Anbieter eines Hochrisiko-KI-Systems. Sie schulden Anhang IV. An Ihrem Code hat sich nichts geändert. An Ihrer Rolle unter der Verordnung schon.
Der seltsamste Fall: Sie sind Anbieter und Betreiber zugleich
Wenden Sie dieselbe Logik nun auf ein Werkzeug an, das Sie ausschließlich für den internen Gebrauch bauen. Sie haben das System geschrieben, auf eine Hochrisiko-Funktion gerichtet und nie etwas verkauft oder verteilt. Das Bauchgefühl sagt: “Wir haben nichts ausgeliefert, also erreicht uns der Act nicht.” Es ist genau umgekehrt. “Inbetriebnahme” umfasst per Definition auch die Bereitstellung für den Eigengebrauch. Etwas im eigenen Haus zu bauen, ist ein Auslöser, keine Ausnahme.
Sie sind also beides zugleich: der Anbieter des Systems (Anhang IV gehört Ihnen) und sein Betreiber (auch die Pflichten aus Artikel 26 — Überwachung, Protokollierung, Aufsicht — sind Ihre). Ein Unternehmen, ein System, beide Rechtsrollen, beide Pflichtenstapel. Der Modellanbieter sitzt weiterhin vorgelagert und behält seine eigenen Pflichten; Artikel 25 verteilt die Verantwortung entlang der Kette, statt sie bei Ihnen abzuladen. Doch für das System, das Sie ausgerichtet haben, tragen Sie beide Hüte gleichzeitig.
Und wenn Sie eine öffentliche Stelle sind oder in eine erfasste Kategorie fallen, schuldet Ihr Betreiber-Ich eine Grundrechte-Folgenabschätzung für genau das System, das Ihr Anbieter-Ich gerade dokumentiert hat — zwei Abschätzungen, ein Werkzeug, ein Unternehmen. Die Unterlagen des Modellanbieters schützen vor keiner von beiden.
Was Anhang IV wirklich von Ihnen will
Sobald Sie akzeptieren, dass Sie der Anbieter sind, wirkt das Anhang-IV-Formular nicht mehr fremd. Es verlangt von Ihnen — der Stelle, die dieses Ding auf eine Hochrisiko-Funktion gerichtet hat — zu erklären, was Sie ausgerichtet haben, wie Sie es getestet haben, wie Sie es im Blick behalten und wie jemand außer Ihnen das alles nachprüfen könnte.
Die Form der Antwort ist immer dieselbe: Für die Modellebene verweisen Sie auf die Dokumentation des Modellanbieters, darauf erklären und testen Sie, was Sie selbst gebaut haben. Und wenn die Dokumentation des Anbieters Lücken hat, müssen Sie das Modell weder rückentwickeln noch erfinden, was er nie offengelegt hat. Was Ihr System verteidigbar macht, sind Ihre eigenen Tests und Ihre Risikobewertung, zugeschnitten auf Ihren Anwendungsfall; vorgelagerte Lücken zu füllen ist nicht Ihre Aufgabe.
Anhang IV einmal unter der Anbieter-Perspektive durchgespielt, an einem konkreten Beispiel — ein Assistent zur Lebenslauf-Vorauswahl für ein mittelgroßes HR-Tech-Unternehmen, gebaut auf einer GPAI-API, mit Retrieval über das Kompetenzmodell des Unternehmens und einem System-Prompt, der die Bewertungskriterien durchsetzt:
| Anhang-IV-Abschnitt | GPAI-Modellanbieter liefert (referenziert) | Anbieter des KI-Systems liefert (Ihre Verantwortung) |
|---|---|---|
| §1 Allgemeine Beschreibung | Modellkarte des GPAI-Anbieters | Zweckbestimmung Ihrer Hochrisiko-Ausrichtung, Einsatzkontext, Nutzergruppen, Grenzen |
| §2 Entwicklung und Daten | Trainingsdaten-Dokumentation des Anbieters nach Art. 53 | Ihr System-Prompt, Retrieval-Korpus samt Herkunft, Leitplanken-Konfiguration, die Ausrichtungsentscheidung selbst |
| §3 Risikomanagement | — | Risikoregister für Ihren Einsatz, identifizierte Fehlermodi (Bias auf geschützten Merkmalen, Halluzination bei Grenzfällen), Gegenmaßnahmen |
| §4 Leistungskennzahlen | Allgemeine Benchmarks des Anbieters (referenziert) | Ihre Evaluierungsergebnisse für Ihren Anwendungsfall, gegen Ihre Akzeptanzkriterien. Das ist der tragende Abschnitt. |
| §5 Menschliche Aufsicht | — | Wo Menschen prüfen, was sie übersteuern können, wie markierte Ausgaben sichtbar werden |
| §6 Cybersicherheit | API-Sicherheitslage des Anbieters | Ihre Zugangskontrollen, Secret-Management, Netzwerkkontrollen, Audit-Trail |
| §7 Qualitätsmanagement | — | Ihr Änderungsmanagement, Deployment-Verfahren, Versionshistorie von Prompts und Korpora |
Beim Abschnitt zu den Leistungskennzahlen (§4) zahlt sich die Perspektive aus. Als Anbieter behaupten Sie, das System sei für den ausgerichteten Hochrisiko-Einsatz hinreichend leistungsfähig. Der einzige ehrliche Nachweis dafür sind Evaluierungsergebnisse auf Ihren Daten, Ihren Prompts, Ihren Korpora, Ihren Akzeptanzkriterien. Die allgemeinen Benchmarks des GPAI-Anbieters können diese Frage nicht für Sie beantworten. Sie waren nie der richtige Maßstab.
Erst die Rolle, dann die Evidenz
Aus der Vorrangstellung der Rollenfrage folgen zwei Dinge. Erstens: Der Rest der Dokumentation ergibt sich aus dieser einen Einordnung — die meisten Werkzeuge fragen noch “Beschreiben Sie Ihr System”, obwohl sie fragen sollten “Auf welchem Anbieter- oder Betreiber-Weg sind Sie?”. Zweitens: Evaluierungsnachweise sind kein separater Arbeitsstrang mehr — §4 von Anhang IV ist schlicht Ihre Erfolgsraten und Ihre Judge-Bewertungen je Kriterium.
Und dieselbe Nachweisbasis bedient mehrere Frameworks. Die Governance nach ISO 42001 stellt anbietergeprägte Fragen zu genau diesem ausgerichteten System. Die Beschaffungsprüfung Ihrer Unternehmenskunden stellt dieselben Fragen in anderem Format. Sobald Sie getrennt haben, was Sie ausgerichtet und was Ihr GPAI-Anbieter trainiert hat, beantworten Sie mehrere Frameworks aus einem einzigen Satz an Eingaben.
Auf der diesjährigen Konferenz “AI Act Now” in Deutschland signalisierten Vertreter der BNetzA eine “comply or explain”-Haltung: Prüfungen sehen sich zuerst die technische Dokumentation an und greifen erst dann zu Laufzeittests, wenn die Unterlagen Zweifel wecken. Die Frage wird nicht lauten “Haben Sie verantwortungsvoll trainiert?” — dass Sie das nicht getan haben, ist bekannt. Sie lautet: “Haben Sie es für diesen Einsatz ausgerichtet und getestet, und können Sie mir das zeigen?”
Dieser Beitrag konzentriert sich auf den Weg über Art. 25(1)(c). Die übrigen Auslöser des Artikel 25 und die GPAI-Anbieter-Seite funktionieren ähnlich, bleiben hier aber außen vor.
Wenn Sie Artikel 25(1)(c) zum ersten Mal lesen und Ihren eigenen Einsatz darin wiedererkennen, wird der Rest von Anhang IV leichter. Das Formular hat immer die richtigen Fragen gestellt. Nur nicht an den, für den Sie sich gehalten haben.
Wo elluminate ins Spiel kommt
Der Compliance-Dokumentationsassistent von elluminate, den wir kürzlich als Beta gestartet haben, setzt die Anbieter-Perspektive end-to-end um — und beginnt mit genau der Frage, um die es in diesem Beitrag geht. Zuerst klärt er Ihre Rolle (Anbieter, Betreiber oder beides) und beschneidet die Dokumentation entsprechend: Ein Betreiber füllt die Anhang-IV-Abschnitte nie aus, ein Anbieter schon. Dabei nimmt er Ihnen die Antwort, die man am leichtesten falsch gibt, nicht einfach ab: Geben Sie an, Sie seien Betreiber und hätten ein vorgelagertes Modell für einen Hochrisiko-Einsatz verändert, setzt er die Artikel-25(1)(c)-Markierung und weist darauf hin, dass Sie tatsächlich Anbieter sein könnten. Die Entscheidung treffen Sie. Von da an halten zwei Dinge die Dokumentation ehrlich. Jeder Abschnittskopf zeigt seine Rechtsgrundlage als Chip: AI-Act-Pflicht für die Anhang-IV-Arbeit, Ergänzend, über den AI Act hinaus für die Module, die die Verordnung gar nicht verlangt (etwa eine BSI-Schutzbedarfsanalyse), damit sich nichts als harte Pflicht ausgibt, was keine ist. Und wenn der Assistent ein §4-Leistungsfeld aus einem Evaluierungslauf befüllt, hält er die Quelle neben dem Wert fest (Experiment-ID, Paket, Zeitstempel), sodass der Nachweis am Anspruch hängen bleibt. Jede verbleibende Lücke wird markiert, nicht versteckt.
Wenn Ihr Team ein System ausgeliefert hat — oder kurz davorsteht —, das ein GPAI-Modell auf etwas ausrichtet, das nach einem Anhang-III-Anwendungsfall aussieht, setzen wir uns mit Ihnen zusammen und gehen Anhang IV gemeinsam durch. Rund dreißig Minuten. Wir klären zuerst die Rolle und gehen dann Abschnitt für Abschnitt vor: was Sie vorgelagert referenzieren, was Sie selbst ausgerichtet haben, wo die operativen Lücken liegen und wo Ihre Evaluierungsnachweise schon mehr von §4 abdecken, als Ihnen bewusst war.
