Ausgabe vom 21. Juli 2026

Die Ankündigung kam nüchtern, die Zahl ist es nicht: Alibaba stellte am 20. Juli sein Modell Qwen 3.8 vor — 2,4 Billionen Parameter, laut Alibaba nur von Anthropics Spitzenmodell Fable 5 übertroffen. Die Gewichte sollen „bald“ quelloffen verfügbar sein; einen genauen Termin, Benchmarks oder Architekturdetails nannte das Unternehmen zunächst nicht. Damit reiht sich Qwen 3.8 in eine Serie ein, die in wenigen Wochen die Machtverhältnisse verschoben hat: Erst Moonshots Kimi K3 (siehe unsere Ausgaben vom 17. Juli und 20. Juli), jetzt Alibaba — offene Modelle im Billionen-Maßstab, die der geschlossenen Weltspitze gefährlich nahe kommen.

Genau das ruft in Washington die Gegenkräfte auf den Plan. In einem vielzitierten Text argumentierte OpenAIs Strategiechef, die US-Regierung solle einen Vorwand finden, um regulatorische Unsicherheit und Misstrauen rund um die neuen chinesischen Modelle zu säen — schließlich untergrüben frei verfügbare Modelle zwangsläufig die Investitionslogik der westlichen Frontier-Labore. Bemerkenswert offen legte er damit das eigentliche Motiv bloß: Es geht weniger um nationale Sicherheit als um Geschäftsmodelle. Kurz darauf ruderte er teilweise zurück und relativierte die Behauptung, ein regulatorisches Vorgehen sei die „beste Strategie“ des Weißen Hauses.

Das strukturelle Dilemma hinter der Debatte ist eleganter, als es die Politik wahrhaben will: Ein Open-Weight-Modell lässt sich kaum verbieten. Eine kommerzielle API kann man abschalten, ein Cloud-Konto sperren. Aber ein Modell, dessen Gewichte einmal veröffentlicht sind, ist überall — kopiert, gespiegelt, weiterverteilt. „Die offenen Gewichte blockieren das Verbot“, brachte es ein Kommentar auf den Punkt. Wer chinesische Modelle aus amerikanischen Unternehmen fernhalten will, kämpft gegen eine Datei, die sich beliebig vervielfältigen lässt.

Dass das Misstrauen nicht aus dem Nichts kommt, zeigt ein Vorgang vom Juni: Anthropic warf Alibabas Qwen-Team in einem Brief an US-Senatoren vor, mit rund 25.000 gefälschten Konten mehr als 28 Millionen Claude-Interaktionen erzeugt zu haben — mutmaßlich, um daraus Trainingsmaterial für konkurrierende Modelle zu gewinnen. Der Vorwurf ist unbestätigt, illustriert aber, wie ruppig der Wettbewerb zwischen den Laboren geworden ist und warum die Sicherheitsdebatte über chinesische Modelle mehr ist als reiner Protektionismus.

Für Entscheider in Unternehmen ist die Lehre weniger ideologisch als praktisch. Die offenen Billionen-Modelle sind real und leistungsfähig genug für den produktiven Einsatz — aber wer heute eine Produktarchitektur fest an ein einzelnes chinesisches Modell bindet, sollte das geopolitische Risiko einpreisen und einen Ausweichpfad bereithalten, falls die Compliance-Abteilung oder die Regulierung morgen anders entscheidet. Wie sich diese Abwägung konkret treffen lässt, vertieft unsere Reportage in dieser Ausgabe.

Die Meldung stammt vom Branchendienst The Information und bewegte am 20. Juli prompt den Aktienkurs: Alphabet entwickle einen neuen KI-Server-Chip mit dem internen Namen „Frozen v2“, der Bestandteile von Googles Gemini-Modell direkt in Silizium einbrenne, um die Inferenz — also die eigentliche Nutzung des Modells nach dem Training — effizienter zu machen. Die Alphabet-Aktie legte daraufhin rund drei Prozent zu.

Um zu verstehen, warum das mehr als ein weiterer Chip ist, hilft eine Analogie. Ein normaler KI-Beschleuniger — auch Googles eigene Tensor Processing Units (TPUs) — ist wie eine gut ausgestattete Werkstatt: Sie kann viele verschiedene Modelle ausführen, weil sie flexibel bleibt. „Frozen v2“ geht den umgekehrten Weg und gleicht eher einer Spezialmaschine, die für genau ein Produkt gebaut ist. Indem Teile der Modellarchitektur fest verdrahtet werden, muss der Chip weniger rechnen und weniger Daten hin- und herschieben. Der Preis dieser Spezialisierung ist Unflexibilität; der Gewinn ist Effizienz.

Und dieser Gewinn ist erheblich. Laut dem Bericht soll „Frozen v2“ sechs- bis zehnmal mehr KI-Token pro Energieeinheit liefern als Googles aktuelle TPU-Generation. In einer Welt, in der die Stromrechnung zum dominierenden Kostenfaktor von KI-Rechenzentren geworden ist, ist das eine strategisch bedeutsame Zahl. Der Chip soll die TPUs nicht ersetzen, sondern ergänzen — und ist erst für den Einsatz ab 2028 vorgesehen.

Der eigentliche Treiber hinter dem Projekt ist ein Engpass im eigenen Haus. Google Cloud kann nach eigenen internen Angaben manche Unternehmenskunden nicht ausreichend bedienen, weil die Rechenkapazität knapp ist. Ein Chip, der dieselbe Gemini-Leistung mit einem Bruchteil der Energie erbringt, entlastet diese Knappheit doppelt — er senkt sowohl die Strom- als auch die Hardwarekosten pro ausgelieferter Anfrage. Für einen Anbieter, der Gemini gleichzeitig in Suche, Workspace und Cloud ausrollt, multipliziert sich jeder Effizienzgewinn über gigantische Nutzungsvolumina.

Für Infrastruktur-Entscheider ist „Frozen v2“ vor allem ein Signal über die Richtung der Branche, weniger eine kurzfristige Kaufoption — der Chip ist Jahre entfernt und dient zunächst Googles Eigenbedarf. Bemerkenswert ist der Trend dahinter: Nach der Ära der universellen GPUs und der etwas spezialisierteren TPUs kommt nun die nächste Stufe der Spezialisierung, bei der einzelne Modelle in Hardware zementiert werden. Das lohnt sich nur bei enormen, stabilen Workloads — und genau das macht es zu einem Vorteil, den vorerst allein die Hyperscaler ausspielen können.

Wenn ein KI-Agent heute eine Datenbank abfragt, einen Kalender liest oder ein Ticket anlegt, geschieht das mit hoher Wahrscheinlichkeit über das Model Context Protocol — kurz MCP, ursprünglich von Anthropic vorgestellt und inzwischen der De-facto-Standard, über den Sprachmodelle mit der Außenwelt kommunizieren. Man kann sich MCP als eine Art USB-Anschluss für KI vorstellen: eine einheitliche Buchse, an die sich beliebige Werkzeuge andocken lassen. Die für den 28. Juli geplante Spezifikationsversion bringt nun die größte Überarbeitung seit dem Start — und ihr Kern ist eine Vereinfachung.

Bislang funktionierte MCP „zustandsbehaftet“ (stateful): Client und Server handelten zu Beginn eine Sitzung aus, tauschten eine Sitzungs-Kennung (die Mcp-Session-Id) aus und mussten sich für die Dauer der Verbindung aneinander erinnern. Das ist elegant für ein einzelnes Gespräch, aber ein Albtraum für den Betrieb im großen Maßstab. Denn jede Anfrage muss dann wieder beim selben Server landen, der die Sitzung kennt — Fachleute sprechen von „Session Affinity“ oder „sticky sessions“. Man braucht spezielle Lastverteiler, gemeinsame Sitzungsspeicher und tiefe Eingriffe am Netzwerk-Gateway.

Die neue Version streicht all das. Der Sitzungs-Header verschwindet, der einleitende Handshake entfällt, das Protokoll kennt keine Sitzung mehr. Jede Anfrage steht für sich — sie enthält alles, was der Server zur Bearbeitung braucht. Das klingt nach einem Detail, ändert aber die Betriebsrealität grundlegend: Ein MCP-Server, der bisher klebrige Sitzungen, einen geteilten Sitzungsspeicher und ein aufwändiges Gateway brauchte, läuft nun hinter einem simplen Rundlauf-Lastverteiler, wie ihn jede gewöhnliche Website seit Jahren nutzt. Genau darin liegt der Fortschritt: MCP wird betreibbar wie normale Web-Infrastruktur.

Im Gepäck hat die Neufassung weitere Verbesserungen, die für den Unternehmenseinsatz zählen: vollständige Validierung der Datenformate nach dem aktuellen JSON-Schema-Standard, Zwischenspeicher-Hinweise (der Client darf Werkzeuglisten für eine definierte Zeit cachen), durchgereichte Trace-Informationen für die Beobachtbarkeit über OpenTelemetry sowie ein modulares Erweiterungssystem. Die ersten beiden offiziellen Erweiterungen sind „MCP Apps“ (abgeschottete HTML-Oberflächen) und eine zustandslose Variante von „Tasks“.

Für Entwicklungsteams ist der Zeitplan die eigentliche Handlungsanweisung. Der Release-Kandidat ist seit dem 21. Mai eingefroren, die finale Spezifikation erscheint am 28. Juli, danach gibt es ein rund zehnwöchiges Fenster, in dem die Anbieter der Software-Bausteine (SDKs) und die Client-Hersteller ihre Umsetzungen gegen reale Lasten testen sollen. Wer heute MCP-Server für Agenten in Produktion betreibt oder plant, sollte die Umstellung jetzt einplanen — sie macht bestehende Betriebs-Provisorien überflüssig, verlangt aber eine Anpassung der Server-Logik, weil der Zustand nun woanders verwaltet werden muss.

Sony Music Entertainment hat vor einem New Yorker Gericht eine neue Klage gegen den KI-Musikgenerator Udio eingereicht. Der Vorwurf: Udio habe die Urheberrechte an mehr als 30.000 Songs verletzt — die Bandbreite reicht von Elvis Presleys „Hound Dog“ über Beyoncés „Say My Name“ bis zu Harry Styles' „As It Was“. Nach Sonys Darstellung nutzte Udio diese Aufnahmen ohne Genehmigung, um sein KI-Modell zu trainieren.

Der prozesstaktische Hintergrund erklärt, warum es eine neue Klage ist. Sony hatte zunächst versucht, sein bereits laufendes Verfahren gegen Udio um eben jene gut 30.000 Aufnahmen zu erweitern. Diesen Vorstoß wies Bundesrichter Alvin K. Hellerstein Anfang Juli zurück — das ursprüngliche Verfahren läuft mit den anfänglich benannten 333 Werken weiter. Statt aufzugeben, macht Sony die zusätzlichen Titel nun zum Gegenstand eines eigenen Prozesses.

Technischer Kern des Vorwurfs ist der Weg, auf dem Udio an das Material gelangt sein soll. Sony argumentiert, Udio habe die Schutzmechanismen von YouTube gegen das sogenannte „Stream-Ripping“ umgangen — also das unerlaubte Herausziehen von Audio aus Streams — und sich so eine Trainingsbibliothek aufgebaut. Damit verschiebt sich die juristische Frage von der reinen „Ist Training fair use?“-Debatte hin zu einem handfesteren Vorwurf: das aktive Aushebeln technischer Schutzmaßnahmen.

Sony steht in diesem Kampf zunehmend allein. Die beiden anderen großen Musikkonzerne, Universal Music und Warner, haben ihre Verfahren gegen Udio nach Vergleichen beigelegt. Die ursprüngliche Klagewelle der Musikindustrie gegen die KI-Generatoren Suno und Udio hatte 2024 begonnen; seither hat sich das Feld ausdifferenziert — manche Labels suchen den Deal, Sony sucht das Urteil. Im laufenden Verfahren reicht die Beweisaufnahme („Discovery“) noch bis zum 25. August, eine Anhörung ist für September angesetzt.

Der Fall fügt sich in ein Muster, das diese Ausgabe an mehreren Stellen zeigt: Die Rechtslage rund um KI-Trainingsdaten wird gerade Gericht für Gericht ausgehandelt (siehe auch den Anthropic-Vergleich im Leitartikel). Für Unternehmen, die generative Musik- oder Medien-Tools einsetzen wollen, bleibt die Botschaft dieselbe wie bei den freiwilligen Kennzeichnungs-Standards der Branche (siehe unsere Ausgabe vom 11. Juli): Die Herkunft der Trainingsdaten ist die entscheidende Risikofrage — und sie ist juristisch noch lange nicht geklärt.

Die Coalition for Health AI (CHAI), ein branchenübergreifender Zusammenschluss im US-Gesundheitswesen, hat ein nationales Programm mit dem Namen PULSE gestartet — die Abkürzung steht für „Public health Use case and Learning Scaling Engine“. Ziel ist es, staatlichen, lokalen, tribalen und territorialen Gesundheitsbehörden dabei zu helfen, generative KI verantwortungsvoll zu bewerten, einzuführen und zu skalieren.

Das Bemerkenswerte an PULSE ist die Konstellation der Beteiligten. OpenAI und Anthropic — sonst erbitterte Konkurrenten — spenden jeweils Unternehmenslizenzen: zusammen zehn Lizenzen mit bis zu 2.000 Zugängen für Fachkräfte im öffentlichen Gesundheitswesen. Der Beratungskonzern Accenture übernimmt das Onboarding und entwickelt gemeinsam mit CHAI Handlungsleitfäden für fünf zentrale Anwendungsfelder. Ein 17-köpfiger Führungsrat wählt die teilnehmenden Behörden aus und ordnet die Fachkräfte den passenden „Communities of Practice“ zu. In der ersten Phase sollen Pilotprojekte in zehn Zuständigkeitsbereichen laufen.

Warum ist ein solches Programm mehr als eine Randnotiz? Weil es zeigt, wie ein stark regulierter, risikoscheuer Sektor an KI herangeht — nämlich nicht über den einzelnen enthusiastischen Mitarbeiter, der eigenmächtig ChatGPT nutzt, sondern über eine koordinierte Struktur mit Governance, Datenschutz-Leitplanken und dem ausdrücklichen Auftrag, aus den Pilotprojekten übertragbare Implementierungs-Empfehlungen abzuleiten. Gesundheitsdaten sind besonders sensibel; ein unkontrollierter Einsatz wäre rechtlich wie ethisch heikel. PULSE ist der Versuch, das Experimentieren in geordnete Bahnen zu lenken.

Zugleich ist die Konstruktion nicht frei von Interessen. Dass ausgerechnet die beiden führenden KI-Anbieter die Lizenzen stiften, sichert ihnen einen frühen Fuß in der Tür eines riesigen öffentlichen Marktes — und formt die Standards, an denen sich spätere Beschaffungen orientieren. Für die Behörden ist das ein günstiger Einstieg, für die Anbieter eine strategische Investition in künftige Vertragsbeziehungen. Solche „gespendeten“ Pilotphasen sind selten reine Wohltat.

Für Entscheider in anderen regulierten Branchen — von Finanzdienstleistern bis zu Versorgern — liefert PULSE eine übertragbare Blaupause. Die Kernidee: KI-Einführung nicht dem Zufall überlassen, sondern als strukturiertes Programm mit definierten Anwendungsfällen, klarer Governance und einer Lern-Rückkopplung aufsetzen. Und ebenso wichtig: die Anreize der Anbieter mitdenken, die solche Programme gern finanzieren. Ein kostenloser Pilot ist selten ohne strategisches Kalkül — was ihn nicht wertlos macht, aber verhandelbar.

Hugging Face, die zentrale Plattform, auf der die KI-Welt ihre Modelle und Datensätze teilt, hat einen Sicherheitsvorfall offengelegt, der in seiner Ausführung neu ist: Der Angriff auf die Produktionsinfrastruktur wurde vollständig von einem autonomen KI-Agenten durchgeführt — ohne dass ein Mensch jeden Schritt steuerte. Das Unternehmen sprach von mehr als 17.000 einzelnen protokollierten Aktionen innerhalb seiner Systeme.

Der Einstieg erfolgte über einen bösartigen Datensatz. Er nutzte zwei Schwachstellen aus, über die sich Code ausführen ließ: einen Loader, der beim Laden des Datensatzes fremden Code startete, und eine sogenannte Template-Injection in der Konfiguration des Datensatzes. So gelangte der Angreifer auf einen Verarbeitungs-Rechner der Plattform. Von dort verschaffte sich der Agent selbstständig höhere Rechte, sammelte gespeicherte Zugangsdaten ein und bewegte sich seitwärts durch interne Cluster — gesteuert über einen selbst-migrierenden Kommando-Mechanismus, der in kurzlebigen, wegwerfbaren Sandbox-Umgebungen lief und seine Steuerungsserver auf öffentlichen Diensten versteckte.

Was macht diesen Angriff so bemerkenswert? Es ist die Autonomie und die Geschwindigkeit. Ein menschliches Angreiferteam hätte für 17.000 koordinierte Aktionen über verteilte Sandboxes Tage gebraucht; ein Agenten-Schwarm erledigt das in einem Bruchteil der Zeit und passt sich dabei laufend an. Die klassische Cyber-Abwehr ist auf menschliches Tempo und menschliche Muster ausgelegt — ein autonomer Agent unterläuft beide Annahmen.

Der Schaden blieb nach Angaben von Hugging Face begrenzt: Betroffen war eine überschaubare Zahl interner Datensätze sowie mehrere von den eigenen Diensten genutzte Zugangsschlüssel. Es gebe keine Hinweise, dass der Agent an den öffentlichen, für Nutzer sichtbaren Modellen, Datensätzen oder „Spaces“ manipuliert habe, ebenso wenig an der eigenen Software-Lieferkette. Die ausgenutzte Schwachstelle wurde geschlossen. Pikantes Detail: Aufgedeckt wurde der Angriff durch eine KI-gestützte Analyse — eine LLM-basierte Triage-Pipeline wertete das vollständige Aktionsprotokoll des Angreifers aus. KI gegen KI, in beide Richtungen.

Für Sicherheitsverantwortliche ist der Vorfall ein Weckruf mit konkreter Lehre. Erstens: Von außen eingespeiste Inhalte — hier ein Datensatz — sind ein realer Angriffsvektor, sobald ihre Verarbeitung Code ausführen kann; die Trennung von Daten und ausführbarem Code muss kompromisslos sein. Zweitens: Die Bedrohung skaliert jetzt mit KI-Geschwindigkeit, was Erkennung und Eindämmung ebenfalls automatisiert und maschinengestützt verlangt — menschliche Reaktionszeiten reichen gegen einen Agenten-Schwarm nicht mehr. Und drittens: Dass hier eine KI die andere enttarnte, ist kein Trost, sondern die neue Normalität, auf die sich die Verteidigung einstellen muss.