Open Weights unter Beschuss: Was US-Beschränkungen für europäische Unternehmen bedeuten

Die möglichen Beschränkungen für Open Weights KI in den USA hätte auch Folgen für Unternehmen in Europa.

Microsoft hat am 24. Juli 2026 einen offenen Brief mit dem Titel „Open Weights and American AI Leadership“ veröffentlicht. Rund 35 Unternehmen und Organisationen haben unterzeichnet, darunter Meta, Nvidia, IBM, Cisco, Dell, Palantir, Palo Alto Networks, Hugging Face, Mozilla, die Linux Foundation, Mistral, Cohere und OpenAI. Die Botschaft an Washington ist kurz: keine vorschnellen Beschränkungen für offene KI-Modelle.

Abbildung: Unterzeichner des Briefs für Open Weight KI, veröffentlicht durch Microsoft

Der Brief ist eine Reaktion auf Überlegungen der US-Regierung, den Zugang zu leistungsfähigen chinesischen Open-Weights-Modellen zu unterbinden. Auch für IT-Verantwortliche in Europa ist das relevant: Wer heute Llama, Mistral, Qwen oder Kimi auf eigener Hardware betreibt, hat sich bewusst gegen die Abhängigkeit von einer US-Cloud-API entschieden. Genau dieser Weg steht jetzt zur Debatte.

Was in Washington gerade passiert

Auslöser war ein Modell-Release. Mitte Juli stellte das Pekinger Start-up Moonshot AI Kimi K3 vor: 2,8 Billionen Parameter, Spitzenplatzierungen in Coding-Benchmarks, Gewichte angekündigt für den 27. Juli unter einer modifizierten MIT-Lizenz. Damit war ein frei herunterladbares Modell auf dem Niveau der teuersten proprietären US-Systeme verfügbar.

Axios beschrieb wenige Tage später, wie stark sich der Markt bereits verschoben hat. Auf dem Entwickler-Marktplatz OpenRouter belegen chinesische Modelle die ersten fünf Plätze nach wöchentlichem Token-Verbrauch: Tencent, Xiaomi, DeepSeek, MiniMax und Z.ai. Alle fünf sind Open Weights. Mozilla-CTO Raffi Krikorian verglich den Einsatz von Frontier-Modellen für Alltagsaufgaben mit einer Fahrt zum Supermarkt im Ferrari; für Routineaufgaben kosteten kleinere Modelle bis zu 50-mal weniger. Ein Investor formulierte gegenüber Axios die These, dass offene Modelle am Ende rund 95 Prozent der Unternehmensanfragen abdecken werden und nur der Rest bei OpenAI oder Anthropic landet.

Die Reaktion aus Washington kam innerhalb einer Woche. US-Finanzminister Scott Bessent kündigte am 21. Juli an, Sanktionen und Entity-List-Einträge lägen auf dem Tisch, falls chinesische Firmen amerikanische Modelle unrechtmäßig destilliert hätten. Einen Tag später warf Michael Kratsios, Direktor des White House Office of Science and Technology Policy, Moonshot AI vor, eine interne Plattform für groß angelegte Destillation gegen US-Modelle betrieben und dafür Nvidia-GB300-Server über Thailand bezogen zu haben. Moonshot hat sich zu den Vorwürfen bislang nicht geäußert. Fachleute halten die Vorwürfe für technisch zweifelhaft: Fable 5 war zum Zeitpunkt der Kimi-K3-Ankündigung erst seit rund drei Wochen auf breiter Ebene verfügbar, und eine Replikation von Frontier-Fähigkeiten allein per Destillation braucht in diesem Zeitfenster eine Trainingsinfrastruktur, die kaum unbemerkt bliebe.

Am selben Tag verschickte die neu gegründete Little Tech Association mit knapp 200 Mitgliedsfirmen, darunter Proton und Y Combinator, Briefe an Präsident Trump, Handelsminister Howard Lutnick und Kratsios. Der Kern: Startups sollen chinesische Open-Weights-Modelle weiter einsetzen dürfen. Zwei Tage später folgte der Microsoft-Brief der großen Konzerne.

Wichtig für die Einordnung: Ein Verbot ist bislang weder erlassen noch formell vorgeschlagen. Es gibt keine Regel im Federal Register, keinen definierten Anwendungsbereich und kein Durchsetzungsverfahren. Diskutiert werden mehrere Varianten: Sanktionen bei nachgewiesenem IP-Diebstahl, Offenlegungspflichten für Unternehmen, die verdächtige Modelle einsetzen, oder Beschaffungsverbote für Auftragnehmer der US-Regierung. Das sind sehr unterschiedliche Eingriffstiefen.

Hier die wichtigste Ereignisse in chronologischer Reihenfolge:

Tabelle: Chronologie der Open-Weights-Debatte, Juni bis Juli 2026

Open Weights und Open Source: die Abgrenzung in Kürze

Die politische Debatte vermischt die Begriffe Open Source und Open Weights fast durchgehend. Für die Compliance-Bewertung im Unternehmen macht der Unterschied allerdings sehr viel aus. Wir haben ihn ausführlich in einem eigenen Beitrag beschrieben: KI-Modelle: Was ist der Unterschied zwischen Open Source und Open Weights?.

Zusammengefasst: Ein KI-Modell besteht aus Trainingsdaten, Quellcode, Architektur und den trainierten Parametern. Echte Open Source AI nach der Open Source AI Definition 1.0 der OSI verlangt alle vier Bausteine unter einer permissiven Lizenz, inklusive belastbarer Angaben zur Herkunft und Filterung der Trainingsdaten. Beispiele sind OLMo vom Allen Institute for AI und die Pythia-Suite von EleutherAI.

Open Weights liefert davon zwei Teile: Architektur und fertig trainierte Parameter. Trainingsdaten und Trainingscode bleiben Geschäftsgeheimnis. Sie können das Modell herunterladen, lokal betreiben und mit Low-Rank Adaption (LoRA) an Ihre Fachdomäne anpassen. Woher die statistischen Muster stammen, sehen Sie nicht. Llama, Gemma, Qwen und Kimi K3 fallen alle in diese Kategorie. Der Begriff „goldener Käfig“ trifft es gut: technisch hervorragend, in der Entstehung undurchsichtig.

Der offene Brief und die Bruchlinie in der Branche

Die Argumentation der Unterzeichner des offenen Briefs läuft über vier Linien.

Erstens Zugang: Startups, Mittelständler, Hochschulen und Behörden können auf fortgeschrittenen Modellen aufbauen, ohne selbst zu trainieren oder Frontier-Preise für jede Routineaufgabe zu zahlen.

Zweitens Wettbewerb: Viele Anbieter drücken die Preise und verteilen die Gewinne breiter.

Drittens Kontrolle: Wer ein Modell selbst betreibt, verliert weder seine Daten noch das aufgebaute Wissen an einen einzelnen Anbieter.

Die vierte Linie ist die interessanteste, weil sie das Sicherheitsargument umdreht. Geschlossene Modelle sind nicht automatisch sicher; sie lassen sich kompromittieren und versagen auf Arten, die von außen niemand prüfen kann. Wenige geschlossene Systeme erzeugen wenige Single Points of Failure. Verteidiger in der IT-Sicherheit brauchen Modelle vergleichbarer Leistungsklasse, um Angriffe zu simulieren und Abwehrmaßnahmen zu entwickeln.

Ein konkreter Fall stützt das Argument. Nach dem Einbruch bei Hugging Face wollte das Unternehmen den Angriff mit Anthropics Fable 5 analysieren. Das scheiterte an den Sicherheitsfiltern des Modells, die den Verteidigungszweck nicht erkannten. Hugging Face wechselte auf GLM 5.2 von Z.ai und bekam den Vorfall damit schnell in den Griff. Ein chinesisches Open-Weights-Modell erledigte also die Arbeit, die ein amerikanisches Spitzenmodell verweigerte.

Zur Destillation bezieht der Brief ebenfalls Position: Das Verfahren, Ausgaben eines Modells zum Training eines anderen zu verwenden, gehört zum normalen Handwerk der Modellentwicklung. Unrechtmäßige Zugriffe auf geschlossene Systeme sollen über gezielte zivil- und handelsrechtliche Verfahren geahndet werden statt über pauschale Restriktionen.

Wer fehlt und warum das aufschlussreich ist

Auf der Unterzeichnerliste stehen OpenAI, Mistral, Cohere und Palantir. Nicht darauf steht Anthropic. Damit fehlt ein Haus, dessen Geschäftsmodell am stärksten davon abhängt, dass Spitzenleistung knapp und teuer bleibt. Lawfare zitiert eine regierungsnahe Quelle, nach der führende KI-Labore oder ihnen nahestehende Akteure alle drei bis fünf Monate für ein Verbot offener Modelle lobbyieren.

Die Unterschrift von OpenAI ist dabei besonders bemerkenswert, weil Dean Ball, dort Head of Strategic Futures und früher Berater im Weißen Haus, öffentlich für weitgehende Beschränkungen chinesischer Open-Weights-Modelle argumentiert. Die Branche ist also auch intern uneins, und die Positionen folgen erkennbar den Bilanzinteressen. Wer Restriktionen bewertet, sollte das mitlesen: Eine Regulierung offener Modelle wirkt ökonomisch wie eine Subvention für die geschlossenen Anbieter.

Was Beschränkungen konkret für europäische Unternehmen bedeuten würden

Für europäische Anwender und Unternehmen sind vier Wirkungskanäle wichtig. Sie treffen unterschiedliche Unternehmen unterschiedlich hart, und sie sind nicht alle gleich wahrscheinlich.

1. Der Abschalter: Verfügbarkeit ohne Vorwarnung

Das US-Handelsministerium belegte im Juni die öffentliche Verbreitung von Claude Fable 5 und Mythos 5 mit einer weltweiten Lizenzpflicht für Exporte, Reexporte und Weitergaben an ausländische Personen. Der Zugang für Nicht-US-Personen, aber auch für Nutzer außerhalb der USA, verschwand binnen Stunden, auch bei Partnern von AWS, Google Cloud und Azure. Anthropic hat den Zugang am 1. Juli wiederhergestellt, nachdem die Kontrollen aufgehoben wurden.

Zwei Wochen Ausfall eines produktiv eingebundenen Modells sind für viele Architekturen ein Schaden, den kein SLA abfedert. Die Lehre daraus betrifft nicht nur geschlossene Anbieter: Vertragliche Zusagen amerikanischer Anbieter stehen unter dem Vorbehalt kurzfristiger Anweisungen aus Washington, und das ohne vorheriges Anhörungsverfahren. Wer eine einzige API als Rückgrat eines Geschäftsprozesses einplant, plant ein einzelnes Ausfallrisiko ein.

2. Gewichte als Exportgut: ECCN 4E091, Deemed Export, FDPR

Mit einer Interim Final Rule des Bureau of Industry and Security wurden die Exportkontrollen für fortgeschrittene Rechenchips ausgeweitet und mit der Klassifizierungsnummer ECCN 4E091 erstmals Modellgewichte selbst erfasst. Ein Regelwerk, das für Waffensysteme und Halbleiter entworfen wurde, greift damit auf Zahlenmatrizen zu.

Praktisch heikel wird es über die Deemed-Export-Doktrin. Nach US-Recht gilt bereits das Zugänglichmachen kontrollierter Technologie gegenüber einer ausländischen Person innerhalb der USA als Export in deren Heimatland. In Multi-Tenant-Cloud-Umgebungen prüft niemand die Staatsangehörigkeit der Administratoren, die eine Plattform warten. Beim Entzug im Juni erstreckte sich die Anweisung deshalb auch auf ausländische Beschäftigte auf US-Boden, und weil eine Filterung nach Nationalität in Echtzeit nicht möglich war, folgte die weltweite Abschaltung.

Drei Konstellationen sollten Sie kennen:

• Eingaben in die Inferenz. Speist ein europäisches Luftfahrt-, Rüstungs- oder Halbleiterunternehmen technische Unterlagen, die EAR oder ITAR unterliegen, in eine chinesisch gehostete API ein, ist das ein Export. Ohne Lizenz ist er unzulässig.
• Entity List. Der bloße Download offener Gewichte ist meist kein Export. Die Einspeisung kontrollierter Technologie in die Schnittstellen eines gelisteten Unternehmens ist ein direkter Verstoß. Z.ai steht bereits auf der Liste.
• Foreign Direct Product Rule. Die FDPR erfasst im Ausland gefertigte Produkte, wenn sie direktes Erzeugnis bestimmter US-Technologie sind. Auf KI übertragen könnte das ein Derivat treffen, das ein europäisches Unternehmen durch Feintuning eines US-Basismodells erstellt hat, in weiter Auslegung sogar dessen Ausgaben.

Für die große Mehrheit europäischer Unternehmen ohne Rüstungs- oder Dual-Use-Bezug bleibt dieser Kanal theoretisch. Wer in kontrollierten Lieferketten arbeitet, sollte ihn vor dem nächsten Proof of Concept prüfen lassen.

3. Vertrieb und Nachschub statt Besitz

Ein Verbot kann keine Gewichte einsammeln, die bereits verteilt sind. Genau darin liegt das strukturelle Problem jeder Regulierung offener Modelle.

Verwundbar ist der Nachschub. Verteilung, Quantisierungen, Sicherheitspatches und Tooling laufen über wenige Plattformen, und die größte davon ist ein US-Unternehmen. Eine Regel, die amerikanischen Plattformen die Verbreitung bestimmter Modelle untersagt, bricht nicht Ihre laufende Installation, aber den Strom an Updates, Community-Beiträgen und geprüften Derivaten. Ein eingefrorenes Modell ohne Patchpfad altert schnell, und zwar sicherheitstechnisch.

Dazu kommt ein Risiko, das unabhängig von Washington besteht: Offene Gewichte sind Ergebnis unternehmerischer Entscheidungen. Keine Institution garantiert, dass Meta, Alibaba oder Moonshot in zwei Jahren die verwendeten Gewichte noch veröffentlichen. Verschieben sich die Interessen, versiegt der Zufluss neuer Modelle kurzfristig.

4. Regulatorische Doppelbelastung in Europa

Der EU AI Act kennt eine Erleichterung für offene Modelle, die schmaler ausfällt, als viele annehmen. Artikel 53 Absatz 2 befreit Anbieter frei und quelloffen bereitgestellter GPAI-Modelle von der technischen Dokumentation und den Informationspflichten gegenüber nachgelagerten Anbietern. Die Urheberrechts-Policy und die zusammenfassende Übersicht der Trainingsdaten bleiben bestehen. Überschreitet ein Modell die Schwelle für systemisches Risiko, entfällt die Ausnahme vollständig.

Die allgemeine Open-Source-Ausnahme in Artikel 2 Absatz 12 endet ebenfalls früh: bei Hochrisiko-Anwendungen, bei verbotenen Praktiken nach Artikel 5 und bei den Transparenzpflichten nach Artikel 50. Für Ihre Bewertung zählen Lizenz, Bereitstellungsform, Einsatzkontext und Ihre eigene Rolle in der Wertschöpfungskette.

Und hier liegt die eigentliche Lücke: Ob Llama, Qwen oder Kimi K3 überhaupt als „frei und quelloffen“ im Sinne der Verordnung gelten, ist juristisch umstritten, weil Trainingsdaten und Trainingscode fehlen. Die bestehenden Rechtsrahmen bilden teiloffene Modelle schlecht ab. Wer ein solches Modell modifiziert und in ein eigenes Produkt einbaut, kann gleichzeitig als Betreiber und als Anbieter gelten. Erkennt eine Aufsichtsbehörde die Open-Source-Eigenschaft nicht an, treffen Sie Dokumentationspflichten, die Sie wegen der verschlossenen Trainingsdaten objektiv nicht erfüllen können. Die Bußgeldobergrenze für GPAI-Verstöße liegt bei 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes; durchsetzbar werden diese Sanktionen ab dem 2. August 2027.

Lohnt sich der Einsatz von Open Weights?

Für die meisten unternehmensinternen Anwendungsfälle lautet die Antwort “ja”, unter zwei Bedingungen: Sie hosten selbst oder bei einem europäischen Anbieter, und Sie wissen, welche Daten in welches Modell fließen.

Der Grund ist wirtschaftlicher Natur. Wissensmanagement, Dokumentenverarbeitung, Ticket-Klassifikation, Codeunterstützung und interne Assistenten brauchen selten das stärkste verfügbare Modell. Ein lokal betriebenes Open-Weights-Modell erledigt diese Arbeit zu Kosten, die planbar sind und mit der Auslastung sinken. Die Kehrseite ist der Betriebsaufwand, den wir in unserem Beitrag zur Make-or-Buy-Entscheidung bei eigener KI-Infrastruktur aufgeschlüsselt haben.

Die vier Bereitstellungswege im Vergleich:

Tabelle: Bereitstellungswege für KI-Modelle im Vergleich

Ist echte Open Source die bessere Wahl?

Gemessen an Rechtssicherheit und Auditierbarkeit: ja, eindeutig. Nur bei einem Modell wie OLMo lässt sich die Herkunft einer Ausgabe bis zur Trainingsquelle zurückverfolgen. Für Finanzdienstleister, Betreiber kritischer Infrastruktur und Anwendungen in der Medizin, wo Erklärbarkeit gefordert wird, ist das langfristig der einzig tragfähige Weg.

Gemessen an der Leistung heute: nein. Der Abstand zu den milliardenschwer trainierten Open-Weights-Modellen beträgt in der Regel eine Modellgeneration. Ein Unternehmen, das ein Analyse- oder Coding-Problem lösen will, merkt diesen Unterschied sofort.

Prozesse mit Auditpflicht und personenbezogenen Daten laufen auf Modellen, deren Entstehung dokumentiert ist. Alles andere läuft auf dem Modell mit dem besten Verhältnis von Leistung zu Betriebskosten. Ein einziges Modell für das gesamte Haus ist unter den aktuellen Bedingungen die riskanteste Variante.

Was europäische Unternehmen jetzt tun sollten

Vier Schritte, die sich unabhängig vom Ausgang der Washingtoner Debatte lohnen:

Tabelle: Handlungsrahmen für den Einsatz offener KI-Modelle

Abschließende Bewertung

Die Debatte um ein Verbot offener Modelle wird in Washington geführt. Die Rechnung zahlen unter Umständen europäische Anwender. Der Juni 2026 hat gezeigt, wie schnell ein Modellzugang verschwinden kann und wie wenig vertragliche Zusagen daran ändern. Dass sich fast die gesamte westliche Technologiebranche gegen pauschale Beschränkungen stellt, ist ein starkes Signal, aber letztendlich immer noch keine Garantie.

Für die Praxis ändert das wenig an der Richtung: Offene Gewichte auf eigener oder europäischer Infrastruktur bleiben der beste Hebel gegen Anbieterbindung und für Datenhoheit. Sie bringen ein eigenes Restrisiko mit, weil die Entstehung der Modelle undokumentiert bleibt und die Einordnung unter dem AI Act ungeklärt ist. Wer beides kennt und seine Anwendungsfälle entsprechend zuordnet, kommt durch diese Phase deutlich ruhiger als ein Haus, das alles auf eine einzige API gesetzt hat.

FAQ

Gibt es bereits ein Verbot von Open-Weights-Modellen in den USA?

Nein. Stand Ende Juli 2026 wird eine Beschränkung diskutiert, es existiert aber keine veröffentlichte Regel, kein festgelegter Anwendungsbereich und kein Durchsetzungsverfahren. Im Gespräch sind Sanktionen bei nachgewiesenem IP-Diebstahl, Offenlegungspflichten und Beschaffungsverbote für US-Regierungsauftragnehmer. Ein pauschales Nutzungsverbot wäre die weitreichendste dieser Varianten und ist bislang nur eine Forderung einzelner Akteure.

Würde ein US-Verbot auch europäische Unternehmen treffen?

Nicht unmittelbar. Ein US-Nutzungsverbot bindet europäische Anwender rechtlich nicht. Spürbar wären die Nebenwirkungen: eingeschränkte Verbreitung über US-Plattformen, fehlende Updates und Derivate, und für Unternehmen in exportkontrollierten Lieferketten zusätzliche Prüfpflichten. Wer amerikanische Kunden, US-Tochtergesellschaften oder ITAR-relevante Projekte hat, sollte die Entwicklung eng verfolgen.

Darf ich chinesische Modelle wie Qwen oder Kimi K3 im Unternehmen einsetzen?

In den meisten Fällen ja. Kritisch wird es, wenn Sie in einer Branche mit US-Exportkontrollbezug arbeiten, etwa Luft- und Raumfahrt, Verteidigung oder Halbleiterfertigung. Dort kann bereits das Einspeisen technischer Unterlagen in eine chinesisch gehostete API ein genehmigungspflichtiger Export sein. Lokales Hosting der Gewichte entschärft den Punkt erheblich, weil keine Daten das eigene Netz verlassen.

Was passiert mit Modellen, die ich bereits heruntergeladen habe?

Sie bleiben lauffähig. Ein Verbot kann verteilte Gewichte nicht zurückholen. Wegfallen würde der Nachschub: neue Versionen, Sicherheitspatches, geprüfte Quantisierungen und Community-Werkzeuge. Deshalb gehören Modellstände genauso in Ihre Lifecycle-Planung wie Firmware- und Betriebssystemversionen.

Reicht ein europäisches Rechenzentrum, um das Problem zu lösen?

Für die Datenhoheit hilft es deutlich, für die Verfügbarkeit nur teilweise. Beim Entzug von Claude Fable im Juni 2026 verloren auch Partner der Hyperscaler mit EU-Standorten den Zugang, weil die Anweisung am Anbieter ansetzte und nicht am Serverstandort. Sicher ist erst der Betrieb auf Gewichten, die Sie selbst vorhalten, oder bei einem europäischen Anbieter ohne US-Konzernmutter.