GPAI-Pflichten ab August 2026: Wann der On-Premise-Betrieb eines Open-Source-LLM zum Anbieter macht

Open-Source-Modelle sind für den deutschen Mittelstand die naheliegende Antwort auf KI: Sie laufen On-Premise, die Daten bleiben im Haus, und es fallen keine laufenden Cloud-Lizenzkosten an. Doch mit dem EU AI Act kommt eine Frage auf den Tisch, die viele unterschätzen: Wer ein offenes Modell wie Llama oder Mistral herunterlädt, anpasst und betreibt, kann unter Umständen selbst zum regulierten GPAI-Anbieter werden – mit eigenen Dokumentationspflichten.

Ab dem 2. August 2026 beginnt das EU AI Office mit der aktiven Durchsetzung gegen Anbieter von General-Purpose-AI-Modellen. In diesem Artikel klären wir, wo die Grenze zwischen privilegiertem Betreiber und pflichtigem Anbieter verläuft, welche Dokumentation Anbieter vorhalten müssen – und warum gerade der On-Premise-Betrieb die Compliance oft erleichtert statt erschwert.

Was ein GPAI-Modell ist

GPAI steht für „General-Purpose AI" – ein KI-Modell mit breitem, allgemeinem Verwendungszweck. Gemeint sind die grossen Sprachmodelle und Foundation Models, die nicht für eine einzelne Aufgabe trainiert wurden, sondern für ein weites Spektrum: Textgenerierung, Zusammenfassung, Übersetzung, Codeerzeugung. Ein Large Language Model wie Llama 4, Mistral Large oder GPT ist das klassische Beispiel eines GPAI-Modells.

Der EU AI Act unterscheidet bei jeder KI-Komponente zwischen zwei zentralen Rollen, und genau diese Unterscheidung entscheidet über Ihre Pflichten:

• Anbieter (Provider): Wer ein GPAI-Modell entwickelt oder entwickeln lässt und unter eigenem Namen in Verkehr bringt. Anbieter tragen die Hauptlast der Dokumentations- und Transparenzpflichten.
• Betreiber (Deployer): Wer ein KI-System unter eigener Verantwortung einsetzt – etwa intern für die eigene Belegschaft. Betreiber haben deutlich leichtere Pflichten, vor allem im Bereich der Nutzungstransparenz.

Die spannende Frage für den Mittelstand lautet: Wann kippt die eigene Rolle vom harmlosen Betreiber in die des dokumentationspflichtigen Anbieters? Ab dem 2. August 2026 ist das keine theoretische Frage mehr – dann startet die aktive Durchsetzung durch das EU AI Office. Wer die Geschäftsführer-Verantwortung dahinter verstehen will, findet die Details in unserem EU AI Act Hub.

Die Open-Source-Privilegierung nach Art. 53 Abs. 2

Der EU AI Act erkennt an, dass offene Modelle ein öffentliches Gut sind und Innovation fördern. Deshalb gibt es eine Privilegierung: Anbieter von GPAI-Modellen, die unter einer freien und Open-Source-Lizenz bereitgestellt werden und deren Parameter, Gewichte und Architektur öffentlich zugänglich sind, sind nach Art. 53 Abs. 2 von einem Teil der Dokumentations- und Transparenzpflichten befreit – solange das Modell keine systemischen Risiken birgt.

Diese Privilegierung ist der Grund, warum offene Modelle wie Llama oder Mistral für den Mittelstand so attraktiv sind. Doch sie hat eine entscheidende Grenze: Sie schützt nicht jeden, der das Modell anfasst, und sie gilt nicht unbegrenzt weiter, sobald aus dem offenen Modell ein kommerzielles Produkt wird.

Für die rein interne Nutzung im eigenen Unternehmen bleibt das Privileg dagegen in aller Regel bestehen. Genau hier liegt die gute Nachricht für die meisten On-Premise-Szenarien im Mittelstand: Solange Sie das Modell für sich selbst betreiben und nicht am Markt anbieten, bewegen Sie sich im privilegierten Bereich.

Wann Sie zum Anbieter werden

Ob Sie Betreiber bleiben oder Anbieter werden, hängt nicht davon ab, dass Sie ein Modell anpassen, sondern wofür. Drei typische Szenarien lassen sich klar unterscheiden:

Szenario 1: Internes Nutzen ohne Anpassung

Sie laden Llama oder Mistral herunter und betreiben es On-Premise für Ihre Belegschaft – als Chatassistent, für Textentwürfe oder als LLM-Backend einer internen Anwendung. Hier sind Sie Betreiber, die Privilegierung greift vollständig.

Szenario 2: Fine-Tuning für den Eigenbedarf

Sie passen das Modell per Fine-Tuning oder Instruction-Tuning auf Ihre Fachsprache, Ihre Dokumente oder Ihren Tonfall an – aber nutzen das Ergebnis weiterhin nur intern. Auch hier bleiben Sie in aller Regel privilegierter Betreiber. Die blosse Modifikation für den Eigenbedarf macht Sie noch nicht zum Anbieter.

Szenario 3: Kommerzielles Anbieten als Dienst

Sie nehmen ein angepasstes Open-Source-Basismodell und bieten es Dritten als kommerziellen Dienst an – etwa als KI-API, als SaaS-Produkt oder als Teil einer verkauften Softwarelösung. Mit diesem Schritt entfällt das Privileg, und Sie werden typischerweise selbst zum GPAI-Anbieter mit eigenen Dokumentationspflichten.

Szenario	Rolle	Pflichten
Internes Nutzen ohne Anpassung	Betreiber (privilegiert)	Nutzungstransparenz, Governance – keine GPAI-Anbieterdoku
Fine-Tuning für den Eigenbedarf	Betreiber (privilegiert)	Interne Dokumentation der Anpassung empfohlen, kein Anbieter-Status
Kommerziell als Dienst angeboten	Anbieter (pflichtig)	Volle technische Doku, Trainingsdaten-Zusammenfassung, Bereitstellung an nachgelagerte Entwickler

Welche Dokumentation Anbieter vorhalten müssen

Wer die Anbieter-Schwelle überschreitet, übernimmt einen klar definierten Katalog an Pflichten. GPAI-Anbieter müssen eine umfassende technische Dokumentation vorhalten und sie nachgelagerten Entwicklern – also Unternehmen, die auf dem Modell aufbauen – bereitstellen, damit diese ihrerseits ihre Pflichten erfüllen können.

Im Kern geht es um die Nachvollziehbarkeit, wie das Modell entstanden ist und welche Risiken es birgt. Hinzu kommt eine öffentliche Zusammenfassung der Trainingsdaten nach dem Template des AI Office. Die folgende Übersicht fasst die zentralen Anforderungen zusammen:

Dokumentationsanforderung	Inhalt
Trainingsmethoden	Trainingsverfahren, Trainingsschritte, eingesetzte Optimierungs- und Tuning-Methoden
Verwendete Daten	Herkunft und Art der Trainingsdaten, öffentliche Zusammenfassung nach AI-Office-Template
Rechenressourcen	Eingesetzte Rechenleistung, Energie- und Hardware-Aufwand des Trainings
Architektur	Modellaufbau, Parameteranzahl, Modalitäten und Schnittstellen – Teil der Model Card
Risikobewertung	Bekannte Einschränkungen, Risiken und Massnahmen zu deren Minderung

Diese Dokumentation ist kein einmaliges Dokument, sondern muss aktuell gehalten und nachgelagerten Entwicklern auf Anfrage zur Verfügung gestellt werden. Wer ein offenes Modell wesentlich modifiziert und kommerziell anbietet, erbt damit faktisch die Pflicht, auch die Herkunft des Basismodells und die eigenen Anpassungen nachvollziehbar zu dokumentieren.

Den eigenen GPAI-Lieferanten prüfen

Selbst wenn Sie sicher im privilegierten Betreiber-Status bleiben, ist eine Frage hochrelevant: Welches GPAI-Modell setzen Sie ein, und wie gut ist dessen Anbieter dokumentiert? Denn als nachgelagertes Unternehmen bauen Sie auf die Angaben Ihres Modell-Lieferanten auf – und je besser die sind, desto leichter ist Ihre eigene Compliance.

Ein zentrales Signal ist, ob der Anbieter den freiwilligen Code of Practice für GPAI unterzeichnet hat. Anbieter, die gezeichnet haben – darunter grosse Häuser wie OpenAI, Anthropic, Google, Mistral oder Meta – verpflichten sich zu Transparenzberichten. Diese Berichte zu Trainingsdaten, Architektur und Risiken erleichtern Ihre eigene nachgelagerte Compliance erheblich, weil Sie auf dokumentierte Angaben aufsetzen statt selbst rekonstruieren zu müssen.

Die folgende Checkliste hilft bei der Lieferantenprüfung – egal ob Sie ein offenes Modell wie Llama oder Mistral oder ein kommerzielles API-Modell einsetzen:

1. Code of Practice: Hat der Anbieter den GPAI Code of Practice unterzeichnet?
2. Transparenzbericht: Liegt eine öffentliche Dokumentation zu Trainingsdaten, Architektur und Risiken vor?
3. Model Card: Gibt es eine vollständige Model Card mit Angaben zu Einschränkungen und Eignung?
4. Trainingsdaten-Zusammenfassung: Existiert die geforderte öffentliche Zusammenfassung nach AI-Office-Template?
5. Lizenz & Privilegierung: Ist die Lizenz wirklich offen im Sinne von Art. 53 Abs. 2, oder handelt es sich um eine eingeschränkte „Open-Weight"-Lizenz?

Wir unterstützen Sie bei dieser Bewertung im Rahmen unserer Compliance-Beratung – inklusive einer dokumentierten Einordnung jedes eingesetzten Modells.

On-Premise: Dokumentation in eigener Hand

Hier zeigt sich die strategische Stärke des On-Premise-Betriebs. Wer ein Modell selbst hostet, behält die volle technische Dokumentation, die Transparenz über Trainingsdaten der eigenen Anpassungen und das vollständige Logging in eigener Hand – genau die Nachweisbarkeit, die der AI Act verlangt.

Während ein Cloud-Anbieter Ihnen seine Compliance-Roadmap vorgibt und Sie sich darauf verlassen müssen, dass dort alles korrekt dokumentiert wird, kontrollieren Sie On-Premise jeden Baustein selbst:

• Trainingsdaten-Transparenz: Sie wissen genau, mit welchen eigenen Dokumenten Sie das Modell per Fine-Tuning angepasst haben – und können es lückenlos belegen.
• Vollständiges Logging: Jede Anfrage und jede Antwort bleibt auf Ihrer Infrastruktur protokollierbar, ohne dass Daten das Haus verlassen.
• Versionskontrolle: Modellstände, Anpassungen und Konfigurationen sind nachvollziehbar versioniert – ein Audit-Trail entsteht von selbst.
• Datenhoheit: DSGVO-Konformität ist strukturell gegeben, weil keine personenbezogenen Daten an Dritte abfliessen.

Genau diese Nachweisbarkeit lässt sich mit einer durchdachten KI-Governance systematisch absichern. Wer von Beginn an Logging, Model Cards und Versionsstände sauber führt, ist sowohl als Betreiber als auch im Fall eines späteren Wechsels in die Anbieter-Rolle vorbereitet. On-Premise ist damit nicht der schwierigere, sondern der compliance-freundlichere Weg.

Fazit und Beratungsempfehlung

Self-Hosting von Open-Source-Modellen ist compliance-freundlich – aber nur, wenn man die Anbieter-Schwelle kennt. Die Kernaussagen im Überblick:

• Die Open-Source-Privilegierung nach Art. 53 Abs. 2 schützt die interne Nutzung offener Modelle, auch nach Fine-Tuning für den Eigenbedarf.
• Sie entfällt, sobald ein angepasstes Basismodell kommerziell als Dienst angeboten wird – dann werden Sie zum dokumentationspflichtigen Anbieter.
• On-Premise belässt die volle Dokumentation, Trainingsdaten-Transparenz und das Logging in Ihrer Hand – ideal für die geforderte Nachweisbarkeit.
• Ab dem 2. August 2026 setzt das EU AI Office aktiv durch. Sanktionen bei GPAI-Verstössen reichen bis zu 15 Mio. EUR oder 3 % des weltweiten Jahresumsatzes.

Die entscheidende Frage ist nicht, ob Sie offene Modelle einsetzen, sondern wie Sie sich rechtlich einordnen. Eine saubere Einordnung Ihrer konkreten Szenarien – Betreiber oder Anbieter – schützt vor unbeabsichtigten Pflichtverstössen und teurer Nacharbeit. Unsere Spezialisten ordnen Ihren Modelleinsatz rechtssicher ein und dokumentieren das Ergebnis nachvollziehbar.

Häufig gestellte Fragen zu GPAI-Pflichten

Werde ich GPAI-Anbieter, wenn ich Llama selbst hoste?

Nicht automatisch. Solange Sie ein offenes Modell rein intern nutzen, greift die Open-Source-Privilegierung nach Art. 53 Abs. 2. Zum Anbieter mit eigenen Pflichten werden Sie typischerweise erst, wenn Sie ein angepasstes Open-Source-Basismodell kommerziell als Dienst Dritten anbieten. Die genaue Einordnung hängt vom Einzelfall ab.

Welche Pflichten hat ein GPAI-Anbieter?

GPAI-Anbieter müssen technische Dokumentation zu Trainingsmethoden, verwendeten Daten, Rechenressourcen, Architektur und Risikobewertung vorhalten und diese nachgelagerten Entwicklern bereitstellen. Hinzu kommt eine Trainingsdaten-Zusammenfassung nach dem Template des AI Office. Verstösse können bis zu 15 Mio. EUR oder 3 % des weltweiten Jahresumsatzes kosten.

Warum sollte ich prüfen, ob mein Modell-Lieferant den Code of Practice gezeichnet hat?

Wenn Ihr GPAI-Lieferant – etwa OpenAI, Anthropic, Google, Mistral oder Meta – den Code of Practice unterzeichnet hat, stellt er Transparenzberichte bereit. Diese erleichtern Ihre eigene nachgelagerte Compliance erheblich, weil Sie auf dokumentierte Angaben zu Trainingsdaten und Risiken aufsetzen können.

Macht On-Premise die GPAI-Compliance einfacher?

Ja. Wer Modelle selbst hostet, behält die vollständige technische Dokumentation, die Trainingsdaten-Transparenz und das Logging in eigener Hand – statt sich auf die Compliance-Roadmap eines externen Anbieters verlassen zu müssen. Das ist genau die Nachweisbarkeit, die der AI Act fordert.