Offener Code von X stoppt Europas Nachweispflicht nicht

Am 13. August 2026 hat X den Algorithmus-Code seiner For-You-Timeline unter der Apache License 2.0 offengelegt. Was dort zu lesen ist, beweist noch nicht, welcher Stand tatsächlich produktiv läuft. Genau diese Lücke füllt der europäische Rechtsrahmen mit einklagbaren Pflichten und Fristen.

Was ist der Digital Services Act? Die Verordnung (EU) 2022/2065 regelt Pflichten für digitale Dienste in der Union. Sie verlangt Begründungen bei Sichtbarkeitsbeschränkungen, klare Angaben zu Empfehlungssystemen und einen kontrollierten Datenzugang für geprüfte Forschende. Plattformen ab 45 Millionen durchschnittlich monatlich aktiven Nutzern in der Union unterliegen erweiterten Pflichten.

Verwandt: Codex Security: Offener Client füttert OpenAI  ·  AI-first Security Review: Vibe-Coded App im Praxistest

Quellcode belegt die Struktur, nicht den produktiven Stand

Keith Coleman, VP Product bei X, kündigte die Offenlegung am 13. August 2026 an. Sein Beitrag beginnt mit drei Nutzerfragen: „Am I shadowbanned?“, „Is X fair?“ und „Why am I seeing this post?“. Dazu schreibt er: „We want the public to be able to answer these themselves.“ Das Unternehmenskonto XOpenSource beschreibt den Umfang: offengelegt wird der Code, der die Sichtbarkeit in der For-You-Timeline beeinflusst, samt der Kennzeichnungen, die Sichtbarkeit begrenzen.

Für Prüfer folgt daraus eine zentrale Unterscheidung. Offengelegter Code belegt, welche Struktur und welche Absicht ein System dokumentiert. Er belegt nicht, welcher Stand auf den Produktivsystemen läuft. X gibt an, Voreinstellungen würden regelmäßig automatisch an die Produktionswerte angeglichen und Experimente ab etwa zehn Prozent des Datenverkehrs sichtbar gemacht. Das bleibt eine Zusage des Betreibers. Am Recherchetag lag zudem keine unabhängige akademische Prüfung der neuen Fassung vor. Der Code war einen Tag alt.

Diese Unterscheidung gilt weit über soziale Netzwerke hinaus. Auch bei Lieferanten, deren Sicherheitsarchitektur öffentlich dokumentiert ist, bleibt die entscheidende Prüffrage, ob der dokumentierte Stand mit dem betriebenen Stand übereinstimmt. Ein Dokument belegt das Design. Den Nachweis des Betriebs liefert es nur zusammen mit einem unabhängigen Verfahren.

Frühere Offenlegungen fielen bei unabhängiger Prüfung durch

Die Vorgeschichte ist dokumentiert. 2023 veröffentlichte Twitter Teile des Empfehlungssystems. Die Veröffentlichung wurde rasch als unvollständig kritisiert. Für diese Art Veröffentlichung kursiert seither der Begriff „transparency theater“. Im Januar 2026 erschien eine frühe Fassung des Repositoriums. Forscher von Cornell, aus Graz und von Carnegie Mellon erklärten damals eine unabhängige Prüfung für unmöglich: Das Modell fehlte, die Trainingsdaten fehlten, die Gewichte waren geschwärzt.

Das ist insofern bemerkenswert, als es sich um eine dokumentierte Prüfung mit negativem Befund handelt. Es liegt damit ein Beleg dafür vor, dass eine Codefreigabe allein noch keinen Prüfprozess trägt. X hat externe Fachleute für Empfehlungssysteme vorab eingeladen, den Code zu prüfen. Diese Fachleute erhielten nach einer Korrektur der berichtenden Redaktion keinen Zugriff auf den produktiven Bewertungswert je Beitrag.

Die neue Fassung schließt Lücken, die Kernbereiche bleiben verdeckt

Die Fassung vom 13. August 2026 enthält erstmals Gewichte, Filter, Sichtbarkeitscode, Trainingscode, synthetische Daten und SimClusters. Das Repository liegt unter github.com/xai-org/x-algorithm. Gemessen am Befund aus dem Januar ist das eine echte Verbesserung, denn die damals genannten Lücken im Modell und in den Trainingsdaten sind teilweise geschlossen.

Gleichzeitig bleiben wesentliche Teile außerhalb des Repositoriums: die Eingabetexte für die KI-gestützten Prüfungen, Teile der Regeln zur Bot-Erkennung sowie die Vorhersagemodelle für Regelverstöße. Genau dort fallen Moderations- und Spam-Entscheidungen. Für Sicherheitsleser ist das der interessanteste Punkt, denn diese Bereiche tragen das größte Missbrauchs- und Manipulationspotenzial.

Coleman präzisierte auf Nachfrage, ob auch Regelwerke außerhalb des Codes offengelegt würden: „We’re specifically addressing that by showing you the output of any such decisions that get made.“ Das Pilotwerkzeug „Under the Hood“ zeigt Kennzeichnungen auf Konto- und Beitragsebene und erlaubt einen Datenexport. Der Pilot ist stark eingeschränkt: Er gilt zunächst für eine zufällig ausgewählte Testgruppe berechtigter Konten, die mindestens ein Jahr alt sind. Berechtigt ist, wer im Vormonat mindestens zehn Beiträge veröffentlicht hat.

Der Digital Services Act erzwingt Begründung und Parametertransparenz

Der europäische Rechtsrahmen geht über freiwillige Veröffentlichungen hinaus. Artikel 17 der Verordnung (EU) 2022/2065 begründet eine Pflicht zur Begründung bei Sichtbarkeitsbeschränkungen, ausdrücklich einschließlich der Herabstufung von Inhalten. Artikel 27 verlangt, dass die Hauptparameter der Empfehlungssysteme in klare Sprache in die Geschäftsbedingungen gehören, samt Einflussmöglichkeiten für Nutzer. Artikel 24 Absatz 2 verlangt seit dem 17. Februar 2023 halbjährliche Veröffentlichungen der durchschnittlichen monatlich aktiven Nutzer in der Union. Nach Erwägungsgrund 76 liegt die Schwelle für sehr große Online-Plattformen bei 45 Millionen durchschnittlichen monatlich aktiven Nutzern, das entspricht zehn Prozent der Unionsbevölkerung.

Für Unternehmen ist dieser Rahmen belastbarer als eine freiwillige Veröffentlichung. Er ist einklagbar, er kennt Fristen und er definiert Zuständigkeiten. Eine Codefreigabe kann jederzeit zurückgenommen oder inhaltlich verengt werden. Artikel 27 bleibt als Pflicht bestehen.

Der Datenzugang für geprüfte Forschende folgt eigenen Regeln

Artikel 40 der Verordnung regelt den Zugang geprüfter Forschender zu internen Daten sehr großer Plattformen. Die Plattform hat 15 Tage Zeit, auf das Ersuchen des zuständigen Koordinators zu reagieren. Sie kann Änderungen wegen Sicherheit oder Geschäftsgeheimnissen vorschlagen. Die Ausnahme für Geschäftsgeheimnisse war im Gesetzgebungsverfahren umstritten.

Die Delegierte Verordnung (EU) 2025/2050 vom 1. Juli 2025, veröffentlicht am 9. Oktober 2025, konkretisiert den Datenzugang seit dem 29. Oktober 2025. Geprüfte Forschende stellen ihre Ersuchen über ein zentrales Portal der Kommission. Die zuständigen nationalen Koordinatoren haben bis zu 80 Arbeitstage für ein begründetes Ersuchen. Vorgesehen sind außerdem Datenkataloge, Kontaktstellen der Anbieter und sichere Verarbeitungsumgebungen für sensible Daten.

Ein Prüfraster für die eigene Lieferantenprüfung

Der Fall lässt sich als Prüfraster auf die eigene Lieferantenprüfung übertragen. Zuerst steht die Vollständigkeit des offengelegten Teils: Welcher Anteil des entscheidungsrelevanten Systems ist dokumentiert und welche Bereiche bleiben verdeckt. Beim X-Repository liegt die Grenze erkennbar bei der Bot-Erkennung und der Verstoßvorhersage. In einer Lieferantenprüfung entspricht dem die Frage, ob die dokumentierte Architektur die sicherheitsrelevanten Entscheidungen vollständig abdeckt.

Danach folgt die Nachrechenbarkeit. Ein Gegenbeispiel mit höherer Prüfbarkeit sind Community Notes: Bewertungscode und die täglichen Rohdaten sind öffentlich, das Ergebnis lässt sich lokal nachrechnen. Zugleich entsteht der produktive Bewerter nach Projektangabe intern und wird erst beim Ausliefern veröffentlicht. Auch hier gilt also die Grenze beim produktiven Stand. Weiter Prüfmodelle neben der Codefreigabe sind die unabhängige Prüfung durch Dritte, Datenspende-Untersuchungen ohne Mitwirkung der Plattform sowie nachrechenbare Verfahren mit offenen Daten.

Als dritter Punkt bleibt der unabhängige Nachweis des produktiven Stands. Eine freiwillige Veröffentlichung liefert dafür keinen Beleg. Vertragliche Zusicherungen, wiederholte Audits und abgestimmte Testverfahren liefern dagegen Nachweise mit Verbindlichkeit. Genau an dieser Stelle entscheidet sich, ob eine Offenlegung ein Dokument bleibt oder Teil einer prüfbaren Kontrolle wird.

Häufige Fragen

Welchen Nachweiswert hat der offengelegte Algorithmus-Code?

Er belegt die Struktur des Systems und die dokumentierte Absicht. Welcher Stand produktiv läuft, belegt er nicht. Die Übereinstimmung mit den Produktionswerten ist eine Zusage des Betreibers.

Welche Teile des Systems bleiben verdeckt?

Die Eingabetexte für die KI-gestützten Prüfungen, Teile der Regeln zur Bot-Erkennung sowie die Vorhersagemodelle für Regelverstöße. Genau dort fallen Moderations- und Spam-Entscheidungen.

Ist die neue Fassung eine Verbesserung gegenüber Januar 2026?

Ja. Sie enthält erstmals Gewichte, Filter, Sichtbarkeitscode, Trainingscode, synthetische Daten und SimClusters. Eine unabhängige akademische Prüfung der neuen Fassung lag am Recherchetag noch nicht vor.

Wem steht das Pilotwerkzeug „Under the Hood“ offen?

Zunächst einer zufällig ausgewählten Testgruppe berechtigter Konten. Konten müssen mindestens ein Jahr alt sein, berechtigt ist, wer im Vormonat mindestens zehn Beiträge veröffentlicht hat.

Was verlangt der Digital Services Act bei Sichtbarkeitsbeschränkungen?

Artikel 17 verlangt eine Begründung, ausdrücklich einschließlich der Herabstufung von Inhalten. Artikel 27 bringt die Hauptparameter der Empfehlungssysteme in klare Sprache in die Geschäftsbedingungen. Für geprüfte Forschende regelt Artikel 40 den Datenzugang mit einer Frist von 15 Tagen für die Plattform.

Lesetipps der Redaktion

LesetippCodex Security: Offener Client füttert OpenAILesetippAI-first Security Review: Vibe-Coded App im PraxistestLesetippWas ist ein Supply-Chain-Angriff? Definition und Abwehr

Mehr aus dem MBF Media Netzwerk

cloudmagazinSouverän bei Daten, abhängig beim KI-ModellMyBusinessFutureArt. 50 KI-VO: Was Betreiber ab August 2026 tunDigital ChiefsWie man Open Source ausbremst, ohne es zu verbieten

Bildquelle: KI-generiert (August 2026)