Die kurze Antwort lautet: Open-Source-KI ist im EU AI Act nicht pauschal ausgenommen. Gemäß Art. 2(12) der EU-VO 2024/1689 greift eine Ausnahme nur für KI-Systeme unter freien und offenen Lizenzen, und selbst dann nicht bei Hochrisiko-Systemen sowie nicht bei Systemen nach Art. 5 oder Art. 50.
Letzte Aktualisierung: 23. März 2026
Für Unternehmen ist deshalb weniger die Marketing-Bezeichnung entscheidend als die juristische Einordnung. Wenn Sie zuerst die Grundpflichten sortieren wollen, lesen Sie parallel unseren Beitrag zu Artikel 4, die operative Einordnung zu Artikel 26, die Rollenlogik aus Anbieter vs. Betreiber und die häufigsten Praxisfragen in der FAQ.
Was ist Open-Source-KI?
Die wichtigste Unterscheidung lautet: Offene KI ist nicht automatisch vollständig offen. Für Geschäftsführung und Fachbereiche hilft eine einfache Analogie: Ein offenes Rezept ist etwas anderes als ein Fertiggericht. Bei KI entspricht das Rezept vor allem dem Modellaufbau und den Gewichten, während das Fertiggericht die fertige Anwendung ist, die Ihr Team tatsächlich nutzt.
Für die Praxis besteht ein KI-Modell aus mindestens vier relevanten Bausteinen. Erstens gibt es die Weights als trainierte Parameter. Zweitens den Code für Training, Inferenz und Anpassung. Drittens die Trainingsdaten oder zumindest Informationen darüber. Viertens die Architektur und Nutzungsdokumentation. Je mehr davon offenliegen, desto eher können Dritte Verhalten, Grenzen und Risiken nachvollziehen.
Open Source, Open Weight und proprietär sollten Sie deshalb nicht verwechseln. Gerade im Einkauf und in der IT-Governance werden diese Begriffe oft durcheinander genutzt, obwohl sie für Compliance, Nachvollziehbarkeit und spätere Vertragsfragen sehr unterschiedliche Folgen haben.
| Modelltyp | Was offen ist | Typische Einschränkung | Compliance-Folge | | --- | --- | --- | --- | | Open Source | Gewichte, Nutzung, Modifikation und Weitergabe sind unter freier Lizenz erlaubt | Nicht alle Trainingsdaten sind vollständig offen | Gute Ausgangslage für Prüfung, Self-Hosting und Anpassung | | Open Weight | Gewichte sind zugänglich, aber Lizenz oder Nutzung ist eingeschränkt | Oft Marken-, Nutzungs- oder Größenbeschränkungen | Technisch offen, rechtlich nicht frei | | Proprietär | Zugang meist nur per API oder SaaS | Kaum Einblick in Modell, Training und Grenzen | Stärkere Herstellerabhängigkeit und weniger technische Prüfbarkeit |
Der Compliance-Vorteil offener Modelle liegt vor allem in besserer Nachvollziehbarkeit. Wenn Gewichte, Architektur und Laufzeitumgebung zugänglich sind, können Sicherheitsteams, Auditoren und Fachbereiche Fehlerbilder, Halluzinationen, Prompt-Leaks oder schädliche Konfigurationen besser testen als bei einem reinen API-Blackbox-Modell. Das ersetzt aber keine Rechtsprüfung, sondern verbessert nur die technische Transparenz.
Art. 2(12): Die Open-Source-Ausnahme im AI Act
Der Gesetzestext ist klar, aber eng. Gemäß Art. 2(12) der EU-VO 2024/1689 gilt: „This Regulation does not apply to AI systems released under free and open-source licences, unless they are placed on the market or put into service as high-risk AI systems or as an AI system that falls under Article 5 or 50.“ Für Unternehmen ist das die zentrale Norm zur Open-Source-Ausnahme.
Die Ausnahme greift nur unter drei Kernbedingungen. Erstens muss tatsächlich eine freie und offene Lizenz vorliegen. Zweitens darf das System nicht als Hochrisiko-KI-System im Sinne von Art. 6 eingesetzt werden. Drittens darf es nicht in den Bereich verbotener Praktiken nach Art. 5 oder der Transparenzpflichten nach Art. 50 fallen.
Die Ausnahme ist damit deutlich schmaler, als viele Anbieter suggerieren. Ein offenes Modell für Forschung, interne Wissensarbeit oder experimentelle Assistenz kann von Teilen der Verordnung ausgenommen sein. Sobald dasselbe Modell aber in Recruiting, Kreditprüfung, kritischer Infrastruktur oder biometrischen Szenarien landet, greift die Ausnahme nicht mehr.
Für Unternehmen ist die Kernaussage deshalb einfach: Open Source bedeutet nicht exempt. Wer ein offenes Modell in einen regulierten Use Case überführt, muss den Einsatz selbst klassifizieren, dokumentieren und organisatorisch absichern. Genau dafür sind ein KI-Inventar, saubere Rollenklärung und eine AI-Act-Checkliste für Unternehmen sinnvoll.
Zusätzlich endet die Entspannung bei GPAI-Modellen mit systemischem Risiko. Nach den GPAI-Leitlinien, die der AI-Act-Explorer am 30. Juli 2025 zusammenfasst, wird ab einem Trainingsschwellenwert von 10^25 FLOP ein systemisches Risiko vermutet. In diesem Bereich gibt es für Open-Source-GPAI keine Freistellung von den vollen Systemic-Risk-Pflichten.
Welche Modelle sind wirklich Open Source?
Die wichtigste Marktbeobachtung lautet: Nicht jedes populäre Modell ist nach Open-Source-Maßstab wirklich offen. Für die Compliance-Praxis zählt deshalb die Lizenzform, nicht die PR-Sprache. Genau hier beginnt das Problem des sogenannten Open Washing: Modelle werden als offen vermarktet, obwohl Nutzung, Weitergabe oder bestimmte Nutzergruppen eingeschränkt sind.
Die OSI-Logik und die GPAI-Leitlinien ziehen dieselbe Richtung vor. Frei und offen ist ein Modell nur dann, wenn Nutzung, Zugang, Modifikation und Weitergabe erlaubt sind und keine Beschränkungen wie Forschung-only, Non-Commercial, Nutzergrößenlimits oder Pflicht zum gesonderten kommerziellen Vertrag entgegenstehen.
| Modell | Lizenz / Status | Einordnung für Unternehmen | Warum das relevant ist | | --- | --- | --- | --- | | Mistral 7B Instruct | Apache 2.0 | Weitgehend offen nutzbar | Freie Nutzung, Modifikation und Weitergabe | | DeepSeek R1 | MIT | Weitgehend offen nutzbar | Permissive Lizenz, lokal betreibbar | | Qwen2-7B-Instruct | Apache 2.0 | Weitgehend offen nutzbar | Freie Nutzung, Modifikation und Weitergabe | | Llama 3.1 | Meta Community License | Nicht Open Source | 700-Millionen-MAU-Schwelle, Marken- und Lizenzauflagen | | Whisper large-v3 | Apache 2.0 | Offen nutzbar, aber spezialisiert | Kein typisches GPAI-Sprachmodell, sondern ASR-Modell | | Phi-4-mini-instruct | MIT | Weitgehend offen nutzbar | Permissive Lizenz für breite Nutzung |
Die Abgrenzung bei Llama ist für Einkaufs- und Rechtsabteilungen besonders wichtig. Die offizielle Modellkarte zu Llama 3.1 auf Hugging Face nennt ausdrücklich die Llama 3.1 Community License und eine zusätzliche kommerzielle Schwelle ab mehr als 700 Millionen Monthly Active Users. Das genügt gerade nicht für die AI-Act-Logik freier und offener Lizenzen, weil solche Nutzergrößenbeschränkungen nach den GPAI-Leitlinien gerade gegen die Open-Source-Ausnahme sprechen.
Bei neueren Llama-Familien kommen weitere Einschränkungen hinzu. Für bestimmte multimodale Llama-3.2-Modelle weist Meta laut offizieller Modellveröffentlichung sogar aus, dass die eingeräumten Rechte in der EU nicht gewährt werden. Wer Llama pauschal als Open Source bezeichnet, beschreibt daher eher eine Marketingposition als eine belastbare Rechtskategorie.
Apache 2.0 und MIT sind für Unternehmen dagegen leichter einzuordnen. Beide Lizenzen sind permissiv und erlauben im Grundsatz Nutzung, Bearbeitung und Weitergabe. Die Meta Community License ist demgegenüber eine proprietäre Community-Lizenz mit Zusatzbedingungen. Für AI-Act-Zwecke ist das ein entscheidender Unterschied.
GPAI-Pflichten für offene Modelle
Die zentrale Compliance-Antwort lautet: Auch offene GPAI-Modelle können Pflichten auslösen. Gemäß Art. 53 der EU-VO 2024/1689 sind Anbieter von GPAI-Modellen grundsätzlich zu technischer Dokumentation, Downstream-Informationen, Copyright-Policy und Trainingsdaten-Zusammenfassung verpflichtet.
Die Open-Source-Ausnahme in Art. 53 Abs. 2 ist dabei ausdrücklich begrenzt. Befreit sind nur die Pflichten aus Art. 53 Abs. 1 Buchstabe a und b, also technische Dokumentation gegenüber Behörden sowie Informationsweitergabe an nachgelagerte Systemanbieter. Nicht befreit sind die Copyright-Policy nach Buchstabe c und die öffentliche Zusammenfassung der Trainingsinhalte nach Buchstabe d.
| GPAI-Pflicht | Offenes GPAI ohne Systemic Risk | Offenes GPAI mit Systemic Risk | | --- | --- | --- | | Technische Dokumentation | Ausnahme möglich | Voll anwendbar | | Downstream-Informationen | Ausnahme möglich | Voll anwendbar | | Copyright-Policy | Gilt weiterhin | Gilt weiterhin | | Summary der Trainingsdaten | Gilt weiterhin | Gilt weiterhin | | Risikomanagement, Evaluierung, Incident Reporting, Cybersecurity | Nicht einschlägig ohne Systemic Risk | Voll anwendbar |
Für Unternehmen ist das praktisch aus zwei Gründen relevant. Erstens sollten Sie bei offenen Modellen nicht nur auf GitHub oder Hugging Face schauen, sondern gezielt prüfen, ob eine belastbare Copyright-Policy und eine Trainingsdaten-Zusammenfassung vorliegen. Zweitens dürfen Sie aus einer fehlenden Dokumentationspflicht des Modellanbieters nicht ableiten, dass Ihr eigener Einsatz automatisch unreguliert wäre.
Gerade beim Einsatz in Unternehmensprozessen bleibt der Use Case ausschlaggebend. Wenn Sie ein offenes Modell produktiv in internen Workflows oder Kundenprozessen verwenden, sollten Sie zusätzlich die Transparenzpflichten aus Artikel 50, die Betreiberlogik aus Artikel 26 und die Rollenabgrenzung aus Anbieter vs. Betreiber mitdenken.
Fine-Tuning: Wann werden Sie zum Anbieter?
Die wichtigste Entwarnung für KMU lautet: Die meisten Unternehmen werden durch Open-Source-Nutzung nicht automatisch zum Anbieter. Nach der im Projekt vorhandenen Research-Linie und den GPAI-Leitlinien bleibt reine Nutzung, Konfiguration oder Wissensanbindung typischerweise auf der Betreiberseite. Kritisch wird es erst, wenn die Modifikation substanziell genug ist.
Als indikatives Kriterium nennen die GPAI-Leitlinien eine Schwelle von mehr als einem Drittel des Trainings-Compute des Originalmodells. Wird für die Modifikation also über ein Drittel des ursprünglichen Trainingsaufwands eingesetzt, kann der Downstream-Akteur als neuer GPAI-Anbieter gelten. Das ist keine triviale Alltagsschwelle, sondern eher ein Marker für tiefgreifende Modellveränderungen.
| Form der Anpassung | Typischer Zusatz-Compute | Praktische Rolle | | --- | --- | --- | | RAG / Wissensdatenbank / Prompting | 0 % | Betreiber | | Leichtes LoRA oder Adapter-Tuning | ca. 5-15 % | Meist weiter Betreiber | | Breites Fine-Tuning mit deutlicher Verhaltensänderung | ca. 15-30 % | Graubereich, Einzelfallprüfung | | Teil-Re-Training oder umfangreiche Neujustierung | ca. 40 %+ | Anbieter-Risiko real |
Für Mittelständler bedeutet das: Ein internes Chatbot-Projekt mit RAG auf Unternehmensdokumente macht Sie regelmäßig nicht zum Anbieter. Auch ein schlankes LoRA-Tuning bleibt häufig im Betreiberbereich, solange es das Modell nicht fundamental neu prägt. Wer dagegen ein offenes Basismodell tief neu trainiert und anschließend als eigenes Produkt oder unter eigener Marke in Verkehr bringt, verlässt die Komfortzone.
Die Rollenfrage sollten Sie deshalb nicht technisch, sondern organisatorisch dokumentieren. Wenn Ihr Team Fine-Tuning plant, halten Sie fest, welches Basismodell genutzt wird, wie stark die Modifikation ist, wer das Modell betreibt und ob daraus ein eigenständiges Produkt entsteht. Für die Grundlogik hilft unser Beitrag zu Anbieter vs. Betreiber.
Ist Open-Source-KI sicherer?
Die ehrliche Antwort lautet: Open-Source-KI ist nicht automatisch sicherer, aber oft besser prüfbar. Für Unternehmen ist das ein echter Unterschied. Self-Hosting, eigene Red-Teaming-Tests und unabhängige Community-Audits sind bei offenen Modellen deutlich realistischer als bei geschlossenen APIs. Das reduziert Vendor Lock-in und kann datenschutzrechtlich vorteilhaft sein, wenn sensible Inhalte das eigene Umfeld nicht verlassen.
Besonders im DSGVO-Kontext ist Self-Hosting ein starkes Argument. Wenn Sie ein offenes Modell lokal oder in einer kontrollierten EU-Umgebung betreiben, sinkt das Risiko unnötiger Datenübermittlungen an externe Anbieter. Für viele Unternehmen ist genau das der Grund, sich Mistral, DeepSeek oder Phi genauer anzusehen.
Die Gegenposition ist aber ebenso wichtig. Offene Modelle kommen häufig mit weniger Guardrails, weniger Support und mehr Eigenverantwortung. Wer ein offenes Modell ohne Monitoring, Zugriffskontrolle, Prompt-Schutz und klare Nutzungsregeln ausrollt, verschiebt Risiken nur vom Hersteller ins eigene Haus.
Für den AI Act ist deshalb die richtige Formel: Mehr Transparenz verbessert Erklärbarkeit, aber Erklärbarkeit ist nicht dasselbe wie Compliance. Dass Sie Gewichte lesen oder ein Modell lokal hosten können, erfüllt weder automatisch Art. 4 noch Betreiberpflichten nach Art. 26 noch branchenspezifische Hochrisiko-Anforderungen.
Chinesische Modelle: DeepSeek, Qwen und der AI Act
Die nüchterne Einordnung lautet: Chinesische offene Modelle sind regulatorisch nicht per se problematischer als US-Modelle, aber sie bringen eigene Prüfbedarfe mit. DeepSeek R1 ist laut offizieller Modellkarte unter MIT veröffentlicht und wird wegen seiner starken Reasoning-Leistung und niedrigen Kosten breit diskutiert. Qwen2-7B-Instruct ist laut offizieller Modellkarte unter Apache 2.0 verfügbar und zeigt zugleich, wie stark sich offene Modellfamilien durch Derivate und eigene Betriebsumgebungen verbreiten.
Für Unternehmen entstehen daraus drei Ebenen der Prüfung. Erstens die Lizenzfrage: Darf das Modell wirklich frei genutzt, verändert und weitergegeben werden? Zweitens die Sicherheitsfrage: Welche Telemetrie, Standardkonfiguration und Supply-Chain-Abhängigkeiten bringt die Betriebsumgebung mit? Drittens die Governance-Frage: Welche internen Einsatzregeln gelten für Daten, Outputs und Freigaben?
Die häufig genannten Bedenken zu Zensur, politischem Einfluss oder Datensicherheit sind nicht bloß geopolitische Schlagworte. Sie können bei cloudbasiertem Bezug tatsächlich relevant sein, etwa wenn API-Zugriffe, Telemetrie oder Hosting außerhalb Ihrer Kontrollzone stattfinden. Diese Risiken sind allerdings kein exklusives China-Problem, sondern betreffen grundsätzlich jeden externen Modellanbieter.
Self-Hosting verändert diese Lage deutlich. Wenn Sie DeepSeek oder ein anderes offenes Modell in einer kontrollierten eigenen Umgebung betreiben, eliminieren Sie das typische Cloud-Risiko externer Prompt- und Inhaltsübertragung weitgehend. Übrig bleiben dann vor allem Lizenz-, Sicherheits- und Qualitätsfragen. Für viele Unternehmen ist das die sachlichste Art, geopolitische Debatten in operative Governance zu übersetzen.
Praktische Empfehlungen für Unternehmen
Die wichtigste Pflicht gilt unabhängig von der Lizenzfrage: Seit dem 2. Februar 2025 verlangt Art. 4 der EU-VO 2024/1689 ausreichende KI-Kompetenz für die betroffenen Personen. Ob Ihr Team mit OpenAI, Mistral, DeepSeek, Llama oder einem selbst gehosteten Modell arbeitet, ändert daran nichts. Open Source ersetzt keine Schulung.
Vor dem Einsatz offener Modelle sollten Sie deshalb mindestens fünf Punkte prüfen:
- Lizenz sauber lesen. Prüfen Sie, ob wirklich eine freie und offene Lizenz vorliegt oder nur ein Open-Weight-Modell mit Zusatzbedingungen.
- Use Case klassifizieren. Klären Sie, ob der Einsatzzweck in Richtung Hochrisiko, Art. 5 oder Art. 50 geht.
- Rolle dokumentieren. Halten Sie fest, ob Sie Betreiber bleiben oder durch tiefes Fine-Tuning in Richtung Anbieter rutschen.
- Betriebsmodell entscheiden. Bewerten Sie API, EU-Hosting oder Self-Hosting nach Datenschutz, Security und Support.
- Team schulen und Regeln festlegen. Verankern Sie Eingaberegeln, Output-Prüfung, Freigaben und Eskalationswege.
Für europäische Alternativen lohnt sich ein nüchterner Blick auf Mistral und auf europäische Initiativen wie Teuken. Der Punkt ist nicht, dass europäische Modelle automatisch rechtskonformer wären. Der Vorteil liegt eher in strategischer Souveränität, einfacherer Stakeholder-Kommunikation und oft besserer Passung zu europäischen Governance-Anforderungen.
Wenn Sie Open-Source-KI nicht nur technisch testen, sondern rechtskonform und teamfähig einführen wollen, ist ein gemeinsamer Mindeststandard der schnellste Hebel. Genau dafür ist unsere EU AI Act Schulung gedacht: als kompakter Einstieg in Art. 4, Rollenlogik, Transparenz, praktische Risiken und einen dokumentierbaren Abschluss mit Schulungszertifikat.