GPAI unter dem EU AI Act: Pflichten für Allzweck-KI

Die meisten Beiträge zum EU AI Act ordnen Systeme nach Anwendung ein: Recruiting, Credit Scoring, Medizinprodukte. Eine eigene Regelungsebene folgt aber einer anderen Logik. Allzweck-KI — General Purpose AI, kurz GPAI — wird nicht nach dem Einsatzzweck reguliert, sondern nach dem Modell selbst. Große Sprach- und Foundation-Modelle, die in unzählige nachgelagerte Anwendungen eingebettet werden, bekommen in Kapitel V der Verordnung (EU) 2024/1689 einen eigenen Pflichtenrahmen. Wer ein solches Modell anbietet oder integriert, sollte die Trennung zwischen GPAI-Pflichten und Hochrisiko-Pflichten genau verstehen — sie greifen parallel, nicht alternativ.

Dieser Beitrag ordnet, was die Verordnung unter Allzweck-KI versteht, welche Pflichten alle GPAI-Provider treffen, wann die schärfere Stufe „systemisches Risiko" greift — und warum der Forcing Event am 02.12.2027 (Digital Omnibus) auch für die GPAI-Schiene den Maßstab setzt, an dem sich Nachweisbarkeit messen lassen muss.

Was die Verordnung unter Allzweck-KI versteht

Der EU AI Act definiert ein GPAI-Modell als ein Modell, das eine erhebliche allgemeine Verwendbarkeit aufweist und eine breite Palette unterschiedlicher Aufgaben kompetent erfüllen kann — unabhängig davon, wie es am Markt platziert wird. Entscheidend ist die generische Fähigkeit, nicht der konkrete Use-Case. Ein Foundation-Modell, das gleichermaßen Texte zusammenfasst, Code generiert und Bilder beschreibt, ist genau deshalb GPAI, weil es nicht auf eine Aufgabe festgelegt ist.

Wichtig ist die begriffliche Schichtung. Die Verordnung unterscheidet das GPAI-Modell vom GPAI-System, das auf diesem Modell aufsetzt. Das Modell ist die trainierte Komponente; das System ist das Produkt, mit dem Endnutzer interagieren. Diese Trennung hat praktische Folgen: Der Modell-Provider trägt die Pflichten aus Kapitel V, während ein nachgelagerter Anbieter, der das Modell in eine Hochrisiko-Anwendung integriert, zusätzlich die Pflichten aus Kapitel III übernimmt. Beide Ebenen sind nicht austauschbar — sie addieren sich entlang der Wertschöpfungskette.

Diese Logik erklärt, warum Allzweck-KI nicht sauber in das klassische Risikostufen-Schema des EU AI Act passt. Sie ist eine Querschnittskategorie, die quer zur Einteilung in verbotene, hochriskante und transparenzpflichtige Systeme verläuft. Wie sich die Risikostufen der Verordnung im Detail aufbauen, ordnet die Microsite ki-risikostufe.de — GPAI ergänzt dieses Schema um eine modellbezogene Ebene.

Die Grundpflichten aller GPAI-Provider nach Art. 53

Für jeden Provider eines GPAI-Modells gilt zunächst ein Grundkatalog aus Artikel 53, unabhängig von der Modellgröße. Vier Pflichten stehen im Zentrum.

Erstens eine technische Dokumentation des Modells, die Trainings- und Testverfahren sowie die Ergebnisse der Evaluierung umfasst und der zuständigen Behörde auf Anfrage bereitgestellt werden kann. Zweitens Informationen für nachgelagerte Anbieter: Wer ein GPAI-Modell in eigene Systeme integriert, muss genug über Fähigkeiten und Grenzen erfahren, um seine eigenen Pflichten erfüllen zu können. Drittens eine Strategie zur Einhaltung des Urheberrechts der Union, insbesondere mit Blick auf den Text- und Data-Mining-Vorbehalt aus der Richtlinie (EU) 2019/790. Viertens eine hinreichend detaillierte Zusammenfassung der für das Training verwendeten Inhalte, veröffentlicht nach einem von der Verordnung vorgesehenen Muster.

Diese Pflichten verschieben den Maßstab spürbar. Es genügt nicht, ein leistungsfähiges Modell anzubieten — der Provider muss belegen können, wie es entstanden ist und womit es trainiert wurde. Die Trust-Logik, die AEGIRA für KI insgesamt vertritt, gilt hier in Reinform: Nicht das Versprechen zählt, sondern die nachweisbare Evidenz hinter dem Modell.

Für Provider, die ihr Modell unter einer freien und quelloffenen Lizenz bereitstellen, sieht die Verordnung gewisse Erleichterungen vor — etwa bei technischer Dokumentation. Die Pflichten zum Urheberrecht und zur Trainingsdaten-Zusammenfassung bleiben allerdings bestehen. Open-Source entbindet nicht von Transparenz über die Datengrundlage.

Wann systemisches Risiko greift — Art. 51 und 55

Oberhalb des Grundkatalogs setzt eine zweite, deutlich schärfere Stufe an: GPAI-Modelle mit systemischem Risiko. Artikel 51 legt die Klassifizierung fest. Ein Modell gilt als systemisch riskant, wenn es über besonders weitreichende Fähigkeiten verfügt — wofür die Verordnung eine technische Vermutung definiert: Wird für das Training eine kumulierte Rechenleistung von mehr als 10^25 FLOP (Gleitkommaoperationen) eingesetzt, wird systemisches Risiko vermutet. Daneben kann auch die Kommission ein Modell auf Grundlage qualitativer Kriterien als systemisch riskant einstufen.

Für diese Modelle kommen über Artikel 55 zusätzliche Pflichten hinzu. Provider müssen Modellevaluierungen nach standardisierten Protokollen durchführen, einschließlich adversarialer Tests, um systemische Risiken zu identifizieren und zu mindern. Sie müssen mögliche systemische Risiken auf Unionsebene bewerten und dokumentieren, schwerwiegende Vorfälle und mögliche Abhilfemaßnahmen verfolgen und an das AI Office sowie nationale Behörden melden. Hinzu kommt ein angemessenes Niveau an Cybersicherheit für Modell und physische Infrastruktur.

Die Asymmetrie ist gewollt. Ein kleines, spezialisiertes Modell trägt den Grundkatalog; ein Modell an der Spitze der Fähigkeitsskala trägt einen erweiterten Pflichtenkranz, weil sein potenzieller gesellschaftlicher Einfluss größer ist. Diese Staffelung entspricht der allgemeinen Architektur des EU AI Act, der Pflichtentiefe konsequent an Risiko koppelt.

Code of Practice und die Rolle des AI Office

Wie GPAI-Provider ihre Pflichten konkret erfüllen, konkretisiert ein Verhaltenskodex nach Artikel 56. Dieser Code of Practice ist das zentrale Instrument, mit dem die Verordnung die abstrakten Pflichten aus Art. 53 und 55 in handhabbare Praxis übersetzt — bis harmonisierte Normen vorliegen. Die Einhaltung des Kodex ist freiwillig, schafft aber eine Vermutung der Konformität; wer ihm nicht folgt, muss die Pflichterfüllung auf anderem Weg nachweisen.

Zuständig für die Aufsicht über GPAI-Modelle ist das AI Office innerhalb der Europäischen Kommission. Anders als bei den meisten Pflichten des EU AI Act, die national vollzogen werden, ist die GPAI-Aufsicht zentralisiert. Das hat einen praktischen Effekt: Für Modell-Provider entsteht ein einheitlicher Ansprechpartner auf Unionsebene, statt 27 nationaler Auslegungslinien.

Was Provider und Integratoren jetzt belastbar machen sollten

Aus der GPAI-Schiene lassen sich drei Konsequenzen ableiten, die unabhängig von der Modellgröße tragen. Erstens muss die Provenance der Trainingsdaten dokumentiert und zusammenfassbar sein — nicht erst auf Anfrage einer Behörde, sondern als laufend gepflegtes Artefakt. Zweitens braucht jede Integration eines GPAI-Modells in eine eigene Anwendung eine klare Rollenklärung: Wer ist Modell-Provider, wer nachgelagerter Anbieter, und welche Pflichten wandern entlang dieser Kette? Drittens sollten Modellevaluierungen und Vorfallprozesse so aufgesetzt sein, dass ihre Ergebnisse prüfbar sind — Evidenz statt Selbstauskunft.

Genau hier verläuft die Trennlinie zwischen Compliance als Dokumentenstapel und Trust-Infrastructure als belastbarer Nachweiskette. Der EU AI Act verlangt für Allzweck-KI nicht, dass ein Modell risikofrei ist — ein solches Versprechen wäre unseriös. Er verlangt, dass Fähigkeiten, Grenzen, Datengrundlage und Risikobehandlung nachvollziehbar belegt werden können. Bis zum Forcing Event am 02.12.2027 ist das die eigentliche Aufgabe: aus einem leistungsfähigen Modell ein nachweisbar verantwortetes Modell zu machen.

Mehr zur AEGIRA Trust-Platform und dazu, wie sich Modell-Evidenz audit-ready strukturieren lässt: aegira.ai.