GPAI-Pflichten unter dem EU AI Act: Was jeder Anbieter von Foundation Models und jeder nachgelagerte Nutzer wissen muss

Wenn Ihr Unternehmen ChatGPT, Claude, Gemini, Llama, Mistral, Stable Diffusion oder ein anderes Foundation Model nutzt, ob über eine API, eine feingetunte Variante oder als Baustein in Ihrem eigenen Produkt, dann gelten die Pflichten des EU AI Act für KI-Modelle mit allgemeinem Verwendungszweck (GPAI) für Ihre Lieferkette. Diese Pflichten sind seit dem 2. August 2025 durchsetzbar und damit eine der frühesten geltenden Anforderungen unter dem AI Act. Anders als die Regeln für Hochrisiko-Systeme, die auf konkrete Anwendungsfälle zielen, knüpfen die GPAI-Pflichten am Modell selbst an, unabhängig davon, wie es letztlich eingesetzt wird, und folgen dem Modell vom ursprünglichen Trainer bis zum finalen Betreiber.

Dieser Leitfaden behandelt, wer als GPAI-Anbieter gilt, was diese Anbieter tun müssen, wann die Regeln zum systemischen Risiko greifen, wie der Code of Practice die Compliance prägt und was nachgelagerte Unternehmen verstehen müssen.

• Ein KI-Modell mit allgemeinem Verwendungszweck ist jedes KI-Modell, das eine breite Palette von Aufgaben erledigen kann, einschließlich Modellen, die mit großen Datenmengen und selbstüberwachtem Lernen im großen Maßstab trainiert wurden. GPT-4, Claude, Gemini, Llama, Mistral und Stable Diffusion gelten alle als GPAI.
• Die GPAI-Pflichten sind seit dem 2. August 2025 durchsetzbar, früher als die meisten anderen Anforderungen des AI Act.
• Alle GPAI-Anbieter müssen Artikel 53 einhalten: technische Dokumentation, Einhaltung des Urheberrechts sowie Transparenz- und Informationspflichten gegenüber nachgelagerten Nutzern.
• Modelle, die mit Rechenleistung über 10²⁵ Gleitkommaoperationen (FLOP) trainiert wurden, gelten als vermutlich systemrisikobehaftet und unterliegen zusätzlichen Pflichten nach Artikel 55: adversarielles Testen, Cybersicherheitsmaßnahmen, Meldung von Vorfällen und Modellbewertungen.
• Der GPAI Code of Practice, veröffentlicht am 10. Juli 2025 und gebilligt am 1. August 2025, ist der zentrale Maßstab für die Compliance.
• Open-Source-GPAI-Modelle erhalten eine begrenzte Ausnahme von einigen Dokumentations- und Transparenzpflichten, nicht aber von den Urheberrechtspflichten oder den Regeln zum systemischen Risiko.
• Wird ein GPAI-Modell in ein Hochrisiko-KI-System eingebunden, muss der Hochrisiko-Anbieter die vollständige Einhaltung sowohl der GPAI- als auch der Hochrisiko-Anforderungen sicherstellen.
• Sanktionen bei GPAI-Verstößen erreichen 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes, durchgesetzt direkt durch das AI Office der Europäischen Kommission.
• Klassifizieren Sie Ihre KI-Systeme jetzt, um zu verstehen, welche Pflichten gelten.

Was ist ein KI-Modell mit allgemeinem Verwendungszweck?

Der AI Act definiert ein KI-Modell mit allgemeinem Verwendungszweck in Artikel 3 als ein KI-Modell, das, auch wenn es mit großen Datenmengen und selbstüberwachtem Lernen im großen Maßstab trainiert wurde, eine erhebliche Allgemeinheit aufweist, eine breite Palette unterschiedlicher Aufgaben kompetent erfüllen kann und sich in eine Vielzahl nachgelagerter Systeme oder Anwendungen einbinden lässt.

Wesentliche Merkmale

Drei Merkmale unterscheiden ein GPAI-Modell von einem engen KI-System mit einem einzigen Zweck:

1. Erhebliche Allgemeinheit: Das Modell ist nicht für eine bestimmte Aufgabe ausgelegt. Es kann Übersetzung, Zusammenfassung, Codegenerierung, Klassifizierung, Schlussfolgern und mehr bewältigen, ohne für jede Aufgabe neu trainiert zu werden.

2. Selbstüberwachtes Training im großen Maßstab: Die meisten in Frage kommenden Modelle werden mit großen, vielfältigen Datensätzen mittels unüberwachten oder selbstüberwachten Lernmethoden trainiert. Das ist das Kennzeichen des Foundation-Model-Paradigmas.

3. Integrierbarkeit: Das Modell lässt sich in viele verschiedene nachgelagerte Anwendungen, Produkte und Systeme einbetten. Ein Modell, das nur innerhalb einer proprietären Anwendung funktioniert, kann trotzdem als GPAI gelten, aber Integrierbarkeit ist ein starkes Indiz.

Welche Modelle fallen darunter?

Die Definition erfasst die großen Modelle, die die aktuelle Landschaft dominieren:

Die Definition erfasst auch generative KI-Modelle ausdrücklich: Selbst wenn ein Modell allein als "Tool zur Content-Erstellung" vermarktet wird, fällt es unter das GPAI-Regime, sofern es die Kriterien Allgemeinheit und Maßstab erfüllt. Die Definition gilt unabhängig davon, wie das Modell in Verkehr gebracht wird: als API, Plattform, herunterladbare Gewichte oder eingebettet in ein Produkt.

Wer gilt als GPAI-Anbieter?

Nach dem AI Act ist der Anbieter eines GPAI-Modells die natürliche oder juristische Person, die ein KI-Modell mit allgemeinem Verwendungszweck entwickelt oder entwickeln lässt und in Verkehr bringt. "Inverkehrbringen" umfasst, das Modell entgeltlich oder unentgeltlich nachgelagerten Unternehmen, Entwicklern oder der Öffentlichkeit verfügbar zu machen.

Anbieter vs. nachgelagerter Anbieter vs. Betreiber

Die GPAI-Lieferkette umfasst oft mehrere Ebenen:

1. Vorgelagerter GPAI-Anbieter: Das Unternehmen, das das Basismodell trainiert und verfügbar macht (z. B. OpenAI, Anthropic, Meta, Google). Diese Stelle trägt die zentralen Pflichten aus Artikel 53 und, wo einschlägig, die Pflichten zum systemischen Risiko aus Artikel 55.

2. Nachgelagerter Anbieter: Ein Unternehmen, das ein GPAI-Modell nimmt, es feintunt, verändert oder in sein eigenes KI-System einbindet und dieses veränderte Modell oder System dann unter eigenem Namen in Verkehr bringt. Diese Stelle kann selbst zum GPAI-Anbieter werden, besonders wenn die Veränderung wesentlich ist. Eine tiefere Aufschlüsselung, wie Rollenwechsel funktionieren, finden Sie unter Pflichten von Anbieter vs. Betreiber.

3. Betreiber: Ein Unternehmen, das ein GPAI-gestütztes System in eigener Verantwortung nutzt, es aber nicht in Verkehr bringt. Betreiber sind keine GPAI-Anbieter, haben aber eigene Pflichten, besonders wenn das System als Hochrisiko gilt.

Die entscheidende Frage: Wann wird ein nachgelagertes Unternehmen zum Anbieter?

Ein Unternehmen wird zum GPAI-Anbieter, wenn es:

• Eine wesentlich veränderte Version des Modells unter eigenem Namen oder eigener Marke in Verkehr bringt
• Ein Modell feintunt und die feingetunte Variante als eigenständiges Produkt oder eigenständigen Dienst verfügbar macht
• Ein GPAI-Modell in ein System einbindet und dieses System als neues KI-System in Verkehr bringt

Ein Unternehmen wird nicht allein dadurch zum GPAI-Anbieter, dass es:

• Ein GPAI-Modell über eine API für seinen eigenen internen Betrieb nutzt
• Ein GPAI-Modell innerhalb der Organisation einsetzt, ohne es Dritten verfügbar zu machen
• Prompts auf Anwendungsebene, UI-Wrapper oder Workflow-Automatisierung um ein bestehendes Modell herum hinzufügt, ohne das Modell selbst zu verändern

Erwägungen zu Open-Source-Modellen

Der AI Act sieht eine begrenzte Ausnahme für GPAI-Modelle vor, die unter einer freien und quelloffenen Lizenz veröffentlicht werden. Unter dieser Ausnahme sind Open-Source-GPAI-Anbieter von bestimmten Dokumentations- und Informationsweitergabepflichten befreit, aber nur wenn folgende Bedingungen erfüllt sind:

• Die Modellparameter (Gewichte, Angaben zur Architektur, Nutzungsinformationen) sind öffentlich verfügbar
• Das Modell ist nicht als systemrisikobehaftet eingestuft

Ist ein Modell zwar Open Source, überschreitet aber die Rechenleistungsschwelle von 10²⁵ FLOP oder wird es von der Kommission als systemrisikobehaftet eingestuft, greift die Ausnahme nicht, und der volle Satz an GPAI-Pflichten, einschließlich der Pflichten zum systemischen Risiko, gilt vollständig.

Wichtig: Die Open-Source-Ausnahme deckt niemals die Einhaltung des Urheberrechts ab. Alle GPAI-Anbieter, ob Open Source oder nicht, müssen die urheberrechtsbezogenen Pflichten einhalten.

Pflichten für alle GPAI-Anbieter (Artikel 53)

Artikel 53 begründet drei Säulen von Pflichten, die für jeden GPAI-Anbieter gelten, unabhängig von der Risikoeinstufung des Modells. Diese Pflichten sollen sicherstellen, dass nachgelagerte Anbieter, Betreiber und Behörden die Informationen erhalten, die sie zur Einhaltung ihrer eigenen Anforderungen brauchen.

Dokumentationsanforderungen

GPAI-Anbieter müssen eine technische Dokumentation des Modells erstellen und aktuell halten, einschließlich des Trainings- und Testprozesses und der Ergebnisse der Bewertung. Die Dokumentation muss mindestens enthalten:

• Eine allgemeine Beschreibung des Modells, einschließlich der vorgesehenen Aufgaben, des Veröffentlichungsdatums, der Modalitäten (Text, Bild, Audio usw.) und der Architektur
• Eine Beschreibung der Trainingsdaten: Quellen, Umfang, Methodik der Kuratierung, Techniken der Datenaufbereitung und, wo einschlägig, Labeling-Verfahren
• Die für das Training genutzten Rechenressourcen (einschließlich FLOP), die Trainingsmethodik und wesentliche Designentscheidungen
• Informationen zu Fähigkeiten und Grenzen des Modells, einschließlich vernünftigerweise vorhersehbarer Risiken und der Maßnahmen dagegen
• Eine Bewertungszusammenfassung zu Leistungsbenchmarks, Testmethodik und bekannten Fehlermodi

Diese Dokumentation muss dem AI Office auf Anfrage vorgelegt werden und aktuell gehalten werden, während das Modell aktualisiert oder verändert wird. Der Dokumentationsstandard entspricht weitgehend den Anforderungen an die technische Dokumentation nach Anhang IV für Hochrisiko-Systeme, ist aber auf die Modell- statt auf die Systemebene zugeschnitten.

Einhaltung des Urheberrechts

Alle GPAI-Anbieter müssen eine Strategie zur Einhaltung des EU-Urheberrechts umsetzen, konkret der Urheberrechtsrichtlinie (Richtlinie 2019/790). Diese Pflicht hat zwei operative Bestandteile:

1. Mechanismus zum Rechtevorbehalt: Anbieter müssen die von Rechteinhabern nach Artikel 4(3) der Urheberrechtsrichtlinie erklärten Rechtevorbehalte erkennen und einhalten, insbesondere das Opt-out für Text und Data Mining. Das bedeutet, ein System umzusetzen, das maschinenlesbare Opt-out-Signale (etwa robots.txt-Anweisungen, Meta-Tags oder andere standardisierte Mechanismen) erkennt und respektiert, mit denen Rechteinhaber ihre Inhalte vom KI-Training ausnehmen.

2. Transparenz zu Trainingsdaten: Anbieter müssen eine hinreichend detaillierte Zusammenfassung der zum Training des GPAI-Modells verwendeten Inhalte erstellen und öffentlich verfügbar machen. Das AI Office hat eine Vorlage für diese Zusammenfassung veröffentlicht. Die Zusammenfassung muss es Parteien mit berechtigten Interessen, einschließlich Rechteinhabern, ermöglichen, ihre Rechte zu verstehen und wahrzunehmen.

Diese Pflicht gilt gleichermaßen für Open-Source- und proprietäre Modelle. Es gibt keine Ausnahme für Open-Source-Anbieter, wenn es um die Einhaltung des Urheberrechts geht. Angesichts der laufenden Rechtsstreitigkeiten und der regulatorischen Aufmerksamkeit rund um den Umgang mit Trainingsdaten ist das einer der risikoreichsten Compliance-Bereiche für GPAI-Anbieter weltweit.

Transparenz und Informationen für nachgelagerte Nutzer

GPAI-Anbieter müssen nachgelagerten Anbietern, die das Modell in ihre eigenen Systeme oder Produkte einbinden, Folgendes verfügbar machen:

• Die oben beschriebene technische Dokumentation (oder eine aussagekräftige Zusammenfassung davon)
• Informationen, die es nachgelagerten Anbietern ermöglichen, ihre eigenen AI-Act-Pflichten zu erfüllen, einschließlich der Informationen, die für die Dokumentation von Hochrisiko-Systemen, die Transparenzpflichten nach Artikel 50 (siehe auch den praktischen Leitfaden zu Artikel 50) und das Risikomanagement nötig sind
• Eine klare Beschreibung der Fähigkeiten, Grenzen und bekannten Risiken des Modells
• Informationen über Änderungen am Modell, die die Compliance nachgelagerter Nutzer beeinflussen könnten

Das ist das verbindende Gewebe der Lieferkette im AI Act. In der Praxis müssen GPAI-Anbieter strukturierte Frameworks zur Informationsweitergabe aufbauen: Model Cards, API-Dokumentation, Sicherheitsberichte und Prozesse zur Änderungsbenachrichtigung.

Für Unternehmen, die auf Foundation Models aufbauen, bestimmt die Qualität der vorgelagerten Transparenzangaben unmittelbar Ihre eigene Compliance-Position. Kann Ihr GPAI-Anbieter die nötigen Informationen nicht liefern, entsteht eine Lücke, die kein noch so großer interner Aufwand füllen kann. Die Sorgfaltsprüfung der Lieferkette, also zu verifizieren, dass Ihr Modellanbieter seine Pflichten aus Artikel 53 erfüllt, ist ein entscheidender erster Schritt.

Systemisches Risiko: zusätzliche Pflichten (Artikel 55)

Der AI Act erkennt an, dass manche Modelle aufgrund ihres Maßstabs, ihrer Fähigkeiten und ihrer Reichweite Risiken bergen, die über einzelne Anwendungsfälle hinaus die Gesellschaft, die öffentliche Sicherheit, die Grundrechte oder die EU-Wirtschaft betreffen. Diese werden als GPAI-Modelle mit systemischem Risiko eingestuft.

Was löst die Einstufung als systemisches Risiko aus?

Es gibt zwei Wege zur Einstufung als systemisches Risiko:

Weg 1, Rechenleistungsschwelle: Ein GPAI-Modell gilt vermutlich als systemrisikobehaftet, wenn die kumulierte Rechenleistung für sein Training 10²⁵ Gleitkommaoperationen (FLOP) überschreitet. Das ist eine klare Grenze: Wer die Schwelle überschreitet, für den gilt die Vermutung. Anfang 2026 erfasst diese Schwelle die meisten Frontier-Modelle von OpenAI, Anthropic, Google DeepMind und Meta, während die meisten kleineren, spezialisierten oder feingetunten Modelle ausgenommen sind.

Weg 2, Einstufung durch die Kommission: Die Europäische Kommission kann ein GPAI-Modell auf Basis der Kriterien in Anhang XIII als systemrisikobehaftet einstufen, selbst wenn die Rechenleistungsschwelle nicht erreicht ist. Zu den Kriterien zählen die Zahl der Endnutzer, der Grad an Autonomie, die Marktdurchdringung, die Einbindung in kritische Infrastruktur und das Missbrauchspotenzial. So ist ein weit verbreitetes Modell nicht allein deshalb ausgenommen, weil es effizient trainiert wurde.

GPAI-Anbieter müssen die Kommission benachrichtigen, wenn ihr Modell eines der beiden Kriterien erfüllt. Die Meldepflicht liegt beim Anbieter, es gibt kein externes Screening-Verfahren, das Sie automatisch erfasst. Eine unterlassene Meldung ist selbst ein Compliance-Verstoß.

Zusätzliche Pflichten für Modelle mit systemischem Risiko

Über alle Pflichten aus Artikel 53 hinaus müssen Anbieter von GPAI-Modellen mit systemischem Risiko auch Artikel 55 einhalten:

Für Frontier-KI-Labore formalisieren diese Pflichten Praktiken, die viele bereits freiwillig umsetzen, nun aber mit regulatorischem Nachdruck und Durchsetzungsfolgen.

Der GPAI Code of Practice

Der GPAI Code of Practice wurde am 10. Juli 2025 veröffentlicht und am 1. August 2025 von der Europäischen Kommission gebilligt, einen Tag bevor die GPAI-Pflichten durchsetzbar wurden. Er ist das mit Abstand wichtigste Compliance-Dokument für GPAI-Anbieter und übersetzt die abstrakten Pflichten der Artikel 53 und 55 in konkrete, umsetzbare Maßnahmen.

Rechtlicher Status

Der Code of Practice ist freiwillig, aber die Befolgung begründet eine Vermutung der Konformität mit den entsprechenden Pflichten. Sie können die Vorgaben einhalten, indem Sie dem Code folgen, oder die Konformität auf andere Weise nachweisen, aber die Last, die Gleichwertigkeit zu belegen, liegt bei Ihnen. In der Praxis wird das AI Office den Code als Ausgangsbasis heranziehen, wenn es die Compliance bewertet. Ohne klare, dokumentierte Begründung davon abzuweichen, ist ein Risiko.

Aufbau und Inhalt

Der Code of Practice ist in drei Kapitel gegliedert:

Kapitel 1, Transparenzpflichten: Detaillierte Vorgaben für die technische Dokumentation, die Informationsweitergabe an nachgelagerte Nutzer und die Zusammenfassungen zu Trainingsdaten, die Artikel 53 verlangt. Enthält Vorlagen für Model Cards, Zusammenfassungen zur Datenherkunft und Angaben zu Fähigkeiten.

Kapitel 2, Urheberrechtspflichten: Praktische Hinweise zur Umsetzung des Mechanismus zum Rechtevorbehalt, zum Erkennen und Respektieren von Opt-out-Signalen und zur Veröffentlichung der Zusammenfassung zu Trainingsdaten. Behandelt die Schnittstelle zu den Text- und Data-Mining-Ausnahmen der Urheberrechtsrichtlinie.

Kapitel 3, Sicherheitspflichten bei systemischem Risiko: Vorgaben für Modellbewertungsprotokolle, Methoden des adversariellen Testens, Cybersicherheits-Grundlinien und Verfahren zur Vorfallmeldung für Modelle, die nach Artikel 55 als systemrisikobehaftet eingestuft sind.

Wie Sie den Code für die Compliance nutzen

Für Unternehmen, die den GPAI-Pflichten unterliegen: Ordnen Sie Ihre Pflichten aus den Artikeln 53 und 55 den entsprechenden Kapiteln des Code zu, setzen Sie die konkreten Maßnahmen um, dokumentieren Sie Ihre Befolgung, und wo Sie abweichen, dokumentieren Sie Ihre alternativen Maßnahmen und deren Begründung. Für nachgelagerte Anbieter und Betreiber dient der Code als Referenzpunkt, um die Compliance vorgelagerter Anbieter zu bewerten: Behauptet ein Anbieter Konformität, kann aber die Befolgung der Maßnahmen des Code nicht belegen, ist das ein Warnsignal in der Sorgfaltsprüfung.

Zeitplan und Übergangsfristen

Die GPAI-Pflichten nach Artikel 51 und den folgenden Bestimmungen folgen einem eigenen Durchsetzungszeitplan innerhalb des breiteren Umsetzungsplans des AI Act:

Was "bereits bestehend" bedeutet

• Modelle, die nach dem 2. August 2025 in Verkehr gebracht wurden: Müssen alle geltenden GPAI-Pflichten sofort einhalten. Keine Übergangsfrist.
• Modelle, die vor dem 2. August 2025 in Verkehr gebracht wurden: Profitieren von einer zweijährigen Übergangsfrist bis zum 2. August 2027. Anbieter müssen auf die Compliance hinarbeiten, unterliegen aber während des Übergangs keiner Durchsetzung.

Wichtige Feinheit: Wird ein bereits bestehendes Modell nach dem 2. August 2025 wesentlich verändert, kann es als neu in Verkehr gebrachtes Modell behandelt werden, was eine sofortige Compliance-Pflicht auslöst. Umfangreiches erneutes Training, Architekturänderungen oder Erweiterungen der Fähigkeiten fallen wahrscheinlich darunter.

Durchsetzungsbefugnisse der Kommission

Das AI Office ist der alleinige Vollzugsträger der GPAI-Pflichten, die nationalen Behörden setzen die GPAI-Regeln nicht durch. Die Durchsetzungsbefugnisse des AI Office werden am 2. August 2026 voll wirksam, es kann aber bereits vorbereitende Untersuchungen durchführen und Leitlinien herausgeben.

Compliance-Szenarien aus der Praxis

Welche Pflichten gelten, hängt davon ab, wo Sie genau in der GPAI-Lieferkette stehen. Die folgenden Szenarien zeigen, wie die Regeln in der Praxis wirken.

Praxisbeispiel: Ein Startup, das Llama für die juristische Recherche feintunt. LexAI, ein Startup aus Paris, nimmt Metas Llama 3 (Open Weight) und feintunt es mit europäischer Rechtsprechung, Gesetzesdatenbanken und juristischen Kommentaren. LexAI macht das feingetunte Modell als SaaS-Produkt für Kanzleien unter der Marke "LexAI" verfügbar. LexAI wird zum GPAI-Anbieter, weil es ein verändertes Modell unter eigenem Namen in Verkehr bringt. LexAI muss alle Pflichten aus Artikel 53 einhalten: technische Dokumentation zum Fine-Tuning-Prozess und zu den juristischen Trainingsdaten, Einhaltung des Urheberrechts mit dem Nachweis, dass die Trainingsdaten rechtmäßig beschafft wurden, und Transparenz gegenüber nachgelagerten Nutzern über die Grenzen und die abgedeckten Rechtsräume des Modells. LexAI wird wahrscheinlich kein systemisches Risiko auslösen, die Rechenleistung für das Fine-Tuning liegt weit unter 10²⁵ FLOP. LexAI profitiert jedoch von Metas vorgelagerter Compliance für das Basismodell Llama. LexAI sollte außerdem prüfen, ob das Endprodukt die Hochrisiko-Einstufung nach Artikel 6 auslöst, wenn es für Rechtsberatung oder Gerichtseingaben genutzt wird.

Praxisbeispiel: Ein Unternehmen, das GPT-4 über eine API im Kundenservice einsetzt. NordicBank, eine skandinavische Bank, bindet OpenAIs GPT-4 über eine API in ihren Kundenservice-Chatbot ein. NordicBank verändert das Modell nicht, sie nutzt Prompt Engineering und Retrieval-Augmented Generation (RAG) auf der Anwendungsebene. NordicBank ist Betreiber, kein GPAI-Anbieter. OpenAI trägt die Pflichten aus Artikel 53 und Artikel 55 für GPT-4. NordicBanks Pflichten liegen auf Betreiber-Ebene: menschliche Aufsicht sicherstellen, Kunden darüber informieren, dass sie mit KI interagieren (Transparenz nach Artikel 50), Logs aufbewahren und auf Probleme achten. NordicBank muss jedoch weiterhin verifizieren, dass OpenAI die nach Artikel 53 erforderlichen Informationen für nachgelagerte Nutzer bereitstellt. Wird der Chatbot zur Bewertung der Kreditwürdigkeit oder für finanzielle Entscheidungen genutzt, muss NordicBank ihn möglicherweise als Hochrisiko-KI-System behandeln, was Anbieterpflichten für das integrierte System auslöst.

Praxisbeispiel: Ein Unternehmen, das ein proprietäres Foundation Model trainiert. SovereignAI, ein Berliner Unternehmen, trainiert ein proprietäres multimodales Foundation Model von Grund auf mit 5 × 10²⁵ FLOP und bietet es über eine API Unternehmenskunden aus Gesundheitswesen, Finanzbranche und öffentlicher Hand an. SovereignAI ist ein vorgelagerter GPAI-Anbieter und unterliegt sowohl Artikel 53 als auch Artikel 55. Die Rechenleistungsschwelle ist klar überschritten, das Modell gilt also als vermutlich systemrisikobehaftet. SovereignAI muss: (1) eine umfassende technische Dokumentation erstellen, einschließlich Herkunft der Trainingsdaten und Details zur Architektur; (2) Einhaltung des Urheberrechts mit Erkennung von Rechtevorbehalten und einer öffentlichen Zusammenfassung der Trainingsdaten umsetzen; (3) nachgelagerten Kunden die Informationen bereitstellen, die sie zur Erfüllung ihrer eigenen Pflichten brauchen; (4) Modellbewertungen und adversarielles Testen durchführen; (5) Cybersicherheitsschutz umsetzen; und (6) die Meldung schwerwiegender Vorfälle an das AI Office einrichten. SovereignAI muss zudem die Kommission über die Einstufung des Modells als systemrisikobehaftet benachrichtigen. Angesichts des Einsatzes im Gesundheitswesen und im öffentlichen Sektor sollte SovereignAI mit erhöhter Aufmerksamkeit sowohl des AI Office als auch der sektorspezifischen Behörden rechnen.

Wie GPAI-Pflichten mit den Hochrisiko-Regeln zusammenwirken

Einer der komplexesten Aspekte der Architektur des AI Act ist das Zusammenspiel zwischen den Pflichten für GPAI-Modelle und den Anforderungen für Hochrisiko-KI-Systeme. Das sind zwei getrennte regulatorische Stränge, die zusammenlaufen, wenn ein GPAI-Modell in ein Hochrisiko-System eingebunden wird.

Das Zwei-Ebenen-Compliance-Modell

Der AI Act arbeitet nach dem Prinzip der gestuften Verantwortung:

• Modellebene: Der GPAI-Anbieter ist für die Pflichten auf Modellebene verantwortlich (Dokumentation, Urheberrecht, Transparenz und, wo einschlägig, Pflichten zum systemischen Risiko) nach den Artikeln 53 und 55.
• Systemebene: Der Anbieter des KI-Systems, das das GPAI-Modell einbindet, ist für die Pflichten auf Systemebene verantwortlich (Risikomanagement, Daten-Governance, Genauigkeit, Robustheit, menschliche Aufsicht, Konformitätsbewertung) nach den Hochrisiko-Regeln.

Diese Ebenen sind kumulativ, nicht alternativ. Ein Hochrisiko-System, das auf einem GPAI-Modell aufbaut, muss beide Anforderungssätze erfüllen.

Praktische Folgen für nachgelagerte Anbieter

Wenn Sie ein GPAI-Modell in ein System einbinden, das als Hochrisiko gilt, müssen Sie:

1. Vorgelagerte Dokumentation einholen: Anfordern und verifizieren, dass der GPAI-Anbieter seine Pflichten aus Artikel 53 erfüllt hat. Die Dokumentation des GPAI-Anbieters bildet die Grundlage Ihrer eigenen technischen Dokumentation für das System.

2. Risikomanagement auf Systemebene durchführen: Die Modellbewertungen des GPAI-Anbieters ersetzen nicht Ihre eigene Risikobewertung auf Systemebene. Sie müssen die Risiken bewerten, die sich aus dem konkreten Anwendungsfall, dem Einsatzkontext und dem Zusammenspiel mit anderen Systemkomponenten ergeben.

3. Konformitätsbewertung durchführen: Ihr System muss das passende Verfahren zur Konformitätsbewertung durchlaufen. Der Compliance-Status des GPAI-Modells befreit Sie nicht von dieser Pflicht.

4. Laufende Beobachtung aufrechterhalten: Sie sind für die Marktbeobachtung des Systems verantwortlich, einschließlich der Beobachtung von Problemen, die aus der GPAI-Modellebene stammen, etwa Modell-Drift, emergente Verhaltensweisen oder Fähigkeiten, die der vorgelagerte Anbieter nicht dokumentiert hat.

5. Update-Risiken steuern: Aktualisiert der GPAI-Anbieter das zugrunde liegende Modell, müssen Sie bewerten, ob das Update den Compliance-Status Ihres Systems beeinflusst. Das ist besonders bei API-basierten Integrationen relevant, wo Modell-Updates ohne ausdrückliche Zustimmung erfolgen können.

Wer haftet?

Der GPAI-Anbieter haftet für Fehler auf Modellebene (z. B. unzureichende Kuratierung der Trainingsdaten). Der System-Anbieter haftet für Fehler auf Systemebene (z. B. das Versäumnis, Schutzvorkehrungen für den konkreten Anwendungsfall umzusetzen). Dieses gestufte Modell schafft Anreize für belastbare vertragliche Regelungen, einschließlich SLA-gestützter Informationsweitergabe, Änderungsbenachrichtigung und Koordinierung der Vorfallbehandlung. Eine ausführliche Compliance-Checkliste für beide Ebenen finden Sie in der EU-AI-Act-Compliance-Checkliste.

Sanktionen bei Nichteinhaltung

GPAI-Verstöße fallen unter das Sanktionsregime des AI Act, das in Artikel 99 festgelegt ist. Die konkrete Sanktionsstufe für GPAI-Verstöße ist:

Bis zu 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes (je nachdem, was für große Organisationen höher ist; und was für KMU und Startups niedriger ist).

Das ist dieselbe Sanktionsstufe, die für Verstöße gegen die Hochrisiko-Regeln und für Verstöße gegen die Transparenzpflichten gilt. Es ist die mittlere Stufe der dreistufigen Sanktionsstruktur des AI Act:

Eine vollständige Aufschlüsselung, wie Bußgelder berechnet werden, einschließlich des KMU-Anpassungsmechanismus und des Vergleichs mit den DSGVO-Sanktionen, finden Sie im Leitfaden zu den EU-AI-Act-Sanktionen.

Besonderheiten der Durchsetzung bei GPAI

GPAI-Pflichten werden ausschließlich von der Europäischen Kommission über das AI Office durchgesetzt, einer einzigen Behörde für die gesamte EU, was regulatorische Arbitrage ausschließt. Das AI Office kann Dokumentation anfordern, Untersuchungen durchführen, Bußgelder verhängen und Abhilfemaßnahmen verlangen, einschließlich der Beschränkung oder Rücknahme eines Modells vom Markt. Die Durchsetzungsbefugnisse werden am 2. August 2026 voll wirksam.

Häufig gestellte Fragen

Werde ich zum GPAI-Anbieter, wenn ich die ChatGPT-API nutze?

Nein. Wenn Sie GPT-4 oder ein anderes GPAI-Modell über eine API ansprechen und es innerhalb Ihres eigenen Betriebs nutzen, um einen Chatbot zu betreiben, Inhalte zu erzeugen oder Workflows zu automatisieren, sind Sie Betreiber, kein GPAI-Anbieter. OpenAI bleibt der GPAI-Anbieter und trägt die Pflichten aus Artikel 53 und Artikel 55. Ihre Pflichten liegen auf Betreiber-Ebene: menschliche Aufsicht, Transparenz gegenüber Endnutzern, Aufbewahrung von Logs und Beobachtung. Bauen Sie jedoch ein eigenständiges Produkt oder einen eigenständigen Dienst, den Sie Dritten unter eigener Marke verkaufen, besonders wenn Sie das Modell feintunen oder wesentlich verändern, nähern Sie sich womöglich dem Anbieterstatus. Die entscheidende Frage ist, ob Sie ein Modell oder System unter eigenem Namen in Verkehr bringen.

Sind Open-Source-Modelle vollständig von den GPAI-Pflichten befreit?

Nein. Open-Source-GPAI-Modelle erhalten eine begrenzte Ausnahme von bestimmten Dokumentations- und Informationsweitergabepflichten. Die Ausnahme gilt nicht für die Urheberrechtspflichten, alle GPAI-Anbieter müssen unabhängig von der Lizenzierung die Urheberrechtsregeln einhalten. Noch wichtiger: Die Open-Source-Ausnahme gilt nicht, wenn das Modell als systemrisikobehaftet eingestuft ist (entweder weil es die Rechenleistungsschwelle von 10²⁵ FLOP überschreitet oder weil die Kommission es so einstuft). Metas Llama 3 etwa ist Open Weight, überschreitet aber wahrscheinlich die Rechenleistungsschwelle, muss also den vollen Satz an GPAI-Pflichten einschließlich der Pflichten zum systemischen Risiko einhalten.

Welche Dokumentation brauche ich als GPAI-Anbieter?

Mindestens: (1) technische Dokumentation zu Architektur, Trainingsprozess, Datenquellen, Rechenleistung, Bewertungen, Fähigkeiten und Grenzen; (2) eine öffentlich verfügbare Zusammenfassung der Trainingsdaten im Format des AI Office; (3) eine dokumentierte Strategie zur Einhaltung des Urheberrechts mit Erkennung von Rechtevorbehalten; und (4) Informationspakete für nachgelagerte Integratoren. Sind Sie als systemrisikobehaftet eingestuft, kommen Berichte zur Modellbewertung, Ergebnisse des adversariellen Testens, Cybersicherheitsdokumentation und ein Verfahren zur Vorfallmeldung hinzu. Der Code of Practice stellt für jedes davon Vorlagen bereit.

Werde ich durch das Fine-Tuning eines Modells zum GPAI-Anbieter?

Das hängt davon ab, was Sie mit dem Ergebnis machen. Wenn Sie ein Modell feintunen und es ausschließlich innerhalb Ihrer eigenen Organisation nutzen, für internen Betrieb, Forschung oder Analyse, sind Sie Betreiber, kein Anbieter. Wenn Sie ein Modell feintunen und es dann Dritten verfügbar machen, ob über eine API, ein herunterladbares Paket oder eingebettet in ein Produkt, werden Sie zum GPAI-Anbieter für das feingetunte Modell. Ihre Pflichten aus Artikel 53 würden sich auf die Fine-Tuning-Ebene konzentrieren: welche Daten Sie genutzt haben, wie Sie das feingetunte Modell bewertet haben, welche Fähigkeiten und Grenzen sich geändert haben. Sie müssten nicht das gesamte Basismodell erneut dokumentieren, müssen aber sicherstellen, dass die Dokumentation des vorgelagerten Anbieters für das Basismodell verfügbar ist.

Wie funktioniert die Schwelle von 10²⁵ FLOP in der Praxis?

Die Schwelle erfasst die kumulierte Rechenleistung, die für das Training des Modells genutzt wurde, gemessen in Gleitkommaoperationen. Es ist eine klare Grenze: Überschreitet Ihr Trainingslauf (einschließlich jedes Pre-Trainings, fortgesetzten Trainings oder umfangreichen Fine-Tunings, das funktional dem Training gleichkommt) 10²⁵ FLOP, gilt das Modell als vermutlich systemrisikobehaftet. Der Anbieter kann versuchen, diese Vermutung zu widerlegen, indem er der Kommission hinreichend substantiierte Argumente vorlegt, aber die Beweislast liegt beim Anbieter und die Hürde ist hoch. In der Praxis erfasst die Schwelle die aktuellen Frontier-Modelle (der GPT-4-Klasse und darüber), während die meisten kleineren Modelle, domänenspezifischen Modelle und typischen Fine-Tuning-Läufe ausgenommen sind. Die Kommission hat die Befugnis, diese Schwelle anzupassen, wenn sich die Hardware-Fähigkeiten weiterentwickeln.

Was, wenn mein GPAI-Anbieter sich weigert, Dokumentation zu teilen?

Das ist ein echtes Compliance-Risiko. Wenn Ihr vorgelagerter GPAI-Anbieter die nach Artikel 53 erforderliche Dokumentation nicht liefern kann oder will, entsteht eine Lücke in Ihrer eigenen Compliance-Kette, besonders wenn Sie ein Hochrisiko-KI-System auf dem Modell aufbauen. Sie sollten: (1) Ihre Anfragen und die Antworten des Anbieters dokumentieren, um die Sorgfaltsprüfung zu belegen; (2) alternative Anbieter prüfen, die konforme Dokumentation bieten; (3) bewerten, ob die Lücke für Ihre eigenen Pflichten wesentlich ist; und (4) erwägen, das AI Office einzuschalten, das GPAI-Anbieter zur Herausgabe der erforderlichen Informationen zwingen kann. Der AI Act ist so gestaltet, dass vorgelagerte Nichteinhaltung nicht automatisch auf Betreiber durchschlägt, aber nur wenn Sie angemessene Schritte zur Beschaffung der Informationen nachweisen. Beginnen Sie mit dem kostenlosen Tool zur AI-Act-Risikoklassifizierung, um zu verstehen, welche Pflichten gelten.

Die GPAI-Pflichten sind kein Zukunftsthema, sie sind geltendes Recht mit realen Durchsetzungsfolgen. Ob Sie Frontier-Modelle trainieren, Open-Source-Modelle feintunen oder Anwendungen auf Foundation-Model-APIs bauen, Ihre Position in der GPAI-Lieferkette zu verstehen, ist der erste Schritt zur Compliance. Bestimmen Sie Ihre Rolle, bewerten Sie Ihre Pflichten, verifizieren Sie Ihre vorgelagerten Anbieter und dokumentieren Sie alles.

Bewerten Sie Ihre AI-Act-Pflichten jetzt →