Schlagwort: Digitale Souveränität

Mecklenburg-Vorpommern setzt auf Nextcloud: Digitale Souveränität beginnt nach der Pressemitteilung

Podcastfolge: Nextcloud statt SharePoint – Mecklenburg-Vorpommerns Souveränitätstest

Mecklenburg-Vorpommern macht etwas, das in der deutschen Digitalpolitik noch immer ungewöhnlich genug ist, um Aufmerksamkeit zu verdienen: Das Land ersetzt Microsoft SharePoint durch eine selbst kontrollierte Kollaborationsplattform auf Basis von Nextcloud. Rund 5.000 Beschäftigte nutzen das Filesharing bereits. Mittelfristig sollen Chat, Videokonferenzen und Groupware hinzukommen und mehr als 50.000 Beschäftigte in Landes- und Kommunalverwaltungen erreichen.

Das ist keine bloße Absichtserklärung. Es gibt einen landeseigenen Betreiber, eine laufende Plattform und eine konkrete Migration. Trotzdem wäre es verfrüht, bereits den Sieg der digitalen Souveränität auszurufen. Open Source ist eine notwendige Grundlage. Souverän wird eine Verwaltung aber erst, wenn sie Betrieb, Wissen, Daten, Schlüssel, Wiederherstellung und Wechselpfad tatsächlich beherrscht.

Mehr Substanz als die übliche Sonntagsrede

Nach Angaben des Finanz- und Digitalisierungsministeriums betreibt die landeseigene DVZ M-V GmbH die Plattform. Nextcloud steht unter der GNU AGPLv3. Das Land nennt eigene Test- und Produktivumgebungen, Betriebsschulungen, Sicherheitsprüfungen und eine priorisierte Einbindung von Stabilitätsupdates. Der Umstieg von SharePoint sei schrittweise und ohne Datenverluste abgeschlossen worden.

Diese Punkte sind wichtig. Ein benannter Betreiber ist besser als eine Wolke aus Unterauftragnehmern. Eine getrennte Testumgebung ist besser als Updates direkt im Produktivsystem. Eine laufende Migration ist mehr wert als die hundertste Strategie mit buntem Titelbild.

Auch der politische Kontext stimmt: Mecklenburg-Vorpommern kooperiert seit 2025 mit Schleswig-Holstein. Parallel nennt das Land OpenProject und den auf OpenWebUI beruhenden Verwaltungschatbot LEA. Daraus könnte mehr als eine einzelne Nextcloud-Installation entstehen: ein offener Verwaltungsarbeitsplatz, dessen Bausteine nicht von einem einzigen US-Konzern diktiert werden.

Open Source ist noch keine Souveränität

Der Quellcode einer Software kann offen sein, während der reale Betrieb weiterhin abhängig bleibt. Wer administriert die Systeme? Wer hält die Verschlüsselungsschlüssel? Welche Komponenten stecken vor und hinter Nextcloud? Ist das Office-Paket offen? Läuft die Videokonferenz über eigene Infrastruktur? Sind Identitätsmanagement, Push-Dienste, Monitoring und Support austauschbar?

Eine Verwaltung kann Nextcloud nutzen und trotzdem in einem neuen Lock-in landen: bei einem Integrator, bei proprietären Erweiterungen oder bei einem Sonderstand, den außer dem bisherigen Dienstleister niemand versteht. Deshalb muss das Land nicht nur Dateien exportieren können. Es braucht Dokumentation, Automatisierung, Versionsstände, Konfigurationen und ausreichend eigenes Personal, damit ein anderer Betreiber übernehmen könnte.

Ein Matrix-Raum ist auch nicht souverän, nur weil Synapse Open Source ist. Ohne Signing Keys, Datenbank, Medien, Reverse-Proxy-Konfiguration und korrekte .well-known-Einträge lässt er sich nicht sauber wiederherstellen. Ebenso ist eine Nextcloud-Sicherung unvollständig, wenn nur Nutzdateien kopiert werden, aber Datenbank, Apps, Konfiguration, Secrets und Cronjobs fehlen.

Der Restore ist die Stunde der Wahrheit

Politik spricht gern über Clouds, Plattformen und Innovation. Seltener spricht sie über den langweiligen Teil, an dem sich Kontrolle entscheidet: Backups und Wiederherstellung.

Ein Backup ist keine Erfolgsmeldung. Erst ein getesteter Restore beweist, dass Daten, Abhängigkeiten und Betriebswissen zusammenpassen. Für Mecklenburg-Vorpommern wären deshalb belastbare Antworten nötig: Gibt es getrennte, versionierte Sicherungen? Werden sie regelmäßig in einer isolierten Umgebung zurückgespielt? Wie lange dauert ein Wiederanlauf? Können zentrale Dienste bei einem Ausfall des Rechenzentrums weiterarbeiten? Wer entscheidet im Notfall über Schlüssel und DNS?

Dass das Land in seiner Kooperation mit Schleswig-Holstein auch Resilienz und Desaster Recovery nennt, ist richtig. Entscheidend ist, ob daraus überprüfbare Praxis entsteht. Ein Dokument im Notfallhandbuch startet noch keinen Server.

5.000 Nutzer sind ein Anfang – 50.000 eine andere Liga

Filesharing für 5.000 Beschäftigte und eine vollständige Kollaborationsumgebung für mehr als 50.000 Menschen sind zwei verschiedene Aufgaben. Sobald Chat, Videokonferenzen, Kalender, Kontakte und gemeinsames Office hinzukommen, steigen Last, Supportbedarf und organisatorische Abhängigkeit.

Dann zählen nicht nur CPU und Speicher. Es geht um Identitäten, Rollen, Barrierefreiheit, mobile Geräte, Aufbewahrungsregeln, Datenschutz, Schulung und Hilfe im Arbeitsalltag. Kommunen haben andere Voraussetzungen als Ministerien. Kleine Verwaltungen benötigen möglicherweise mehr Unterstützung, dürfen aber nicht zu bloßen Mandanten ohne Mitspracherecht werden.

Die Zielzahl muss deshalb an aktiven Nutzern, tatsächlicher Funktionsnutzung, Verfügbarkeit und Zufriedenheit gemessen werden. Ein freigeschaltetes Konto ist noch kein gelungener Rollout.

Die ökonomische Frage: Wer bekommt das Geld und wer behält das Wissen?

Digitale Souveränität ist auch Industriepolitik. Öffentliche Milliarden können entweder Lizenzrenten und Abhängigkeiten finanzieren oder offene Infrastruktur, europäische Anbieter und dauerhaftes Wissen in der Verwaltung stärken.

Das bedeutet nicht, dass Open Source kostenlos ist. Im Gegenteil: Betrieb, Integration, Sicherheit, Schulung und Weiterentwicklung müssen anständig bezahlt werden. Der Unterschied liegt darin, was nach der Zahlung übrig bleibt. Bei einem proprietären Vertrag bleiben häufig Nutzungsrechte und Abhängigkeit. Bei einer klugen Open-Source-Beschaffung bleiben zusätzlich Quellcode, Dokumentation, Standards, Wechselmöglichkeiten und idealerweise Verbesserungen für alle.

Darum sollte Mecklenburg-Vorpommern offenlegen, welche Kosten die Migration und der laufende Betrieb verursachen, welche externen Dienstleister beteiligt sind und welche Anpassungen an die jeweiligen Projekte zurückgegeben werden. Öffentliche Mittel sollten keine unsichtbaren Sonderlösungen produzieren, sondern gemeinschaftlich nutzbare Infrastruktur.

Kooperation statt 16 Landesinseln

Die Zusammenarbeit mit Schleswig-Holstein ist möglicherweise der politisch stärkste Teil des Projekts. Deutschland braucht nicht 16 inkompatible Landesclouds und 11.000 kommunale Einzelwege. Es braucht gemeinsame offene Standards, wiederverwendbare Betriebsmodelle und föderale Strukturen, bei denen ein Land nicht vom guten Willen des anderen abhängig wird.

Gemeinsam heißt dabei nicht zentralistisch. Mecklenburg-Vorpommern muss seine Daten und Entscheidungen selbst kontrollieren können. Gleichzeitig sollten Schnittstellen, Automatisierung, Sicherheitswissen und Beschaffungsunterlagen geteilt werden. So entsteht Redundanz: Wenn ein Betreiber ausfällt oder ein Vertrag endet, existiert ein realer Wechselpfad.

Ein guter Anfang, der öffentlich geprüft werden muss

Mecklenburg-Vorpommern verdient Anerkennung dafür, SharePoint nicht nur zu kritisieren, sondern praktisch zu ersetzen. Doch politische Glaubwürdigkeit entsteht nicht durch das Etikett „souverän“. Sie entsteht durch überprüfbare Kontrolle.

In den kommenden Monaten sind deshalb konkrete Nachweise wichtiger als weitere Hochglanzmeldungen:

  • Wie entwickeln sich aktive Nutzerzahlen und kommunaler Rollout?
  • Welche Komponenten werden für Talk, Office und Groupware eingesetzt?
  • Wo liegen Daten, Schlüssel und Backups?
  • Gibt es dokumentierte und getestete Wiederherstellungen?
  • Können Betreiber und Dienstleister gewechselt werden?
  • Welche Kosten entstehen und welche Verbesserungen fließen upstream?
  • Gibt es unabhängige Sicherheitsprüfungen und veröffentlichbare Ergebnisse?

Wenn diese Fragen sauber beantwortet werden, kann aus dem Projekt ein Vorbild werden. Wenn nicht, bleibt Nextcloud nur ein anderes Logo auf einer weiterhin fremdbestimmten Infrastruktur.

Digitale Souveränität bedeutet nicht, dass der Staat alles selbst programmieren muss. Sie bedeutet, dass er jederzeit verstehen, prüfen, betreiben, wiederherstellen und wechseln kann. Mecklenburg-Vorpommern hat einen ernst zu nehmenden Anfang gemacht. Jetzt beginnt der Teil, an dem sich entscheidet, ob aus Software tatsächlich politische Handlungsfähigkeit wird.

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Quellen

  1. Ministerium für Finanzen und Digitalisierung Mecklenburg-Vorpommern, „Auf dem Weg zur Digitalen Souveränität: Mecklenburg-Vorpommern setzt auf Open Source“, 3. Juli 2026: https://www.regierung-mv.de/Landesregierung/fm/Aktuell/?id=221531
  2. DVZ M-V GmbH, „Mecklenburg-Vorpommern setzt auf Open Source“, 3. Juli 2026: https://www.dvz-mv.de/news/mecklenburg-vorpommern-setzt-auf-open-source
  3. Gemeinsame Kooperation Mecklenburg-Vorpommern/Schleswig-Holstein zur digitalen Souveränität, 21. Oktober 2025: https://www.regierung-mv.de/Aktuell/?id=215184

Die LLC als Freiheitsbunker? Wie aus Debanking-Angst gefährlicher Rechtsmythos wird

Audiofassung

Redaktioneller Hinweis: Der Beitrag ordnet öffentliche Rechtsbehauptungen journalistisch ein. Er ersetzt keine Rechts- oder Steuerberatung für einen konkreten Fall.

Ein Pop-up im Geschäftskonto. Die Nachricht klingt endgültig: Das Konto werde geschlossen. Der erste Gedanke ist nicht Buchhaltung, sondern Existenz. Was passiert mit Einnahmen, Lastschriften, Gehältern und Spenden? Und was, wenn die Kündigung tatsächlich mit politischen Gästen, unpopulären Positionen oder öffentlichem Druck zusammenhängt?

Diese Angst ist real. Ein Unternehmen ohne Zahlungsverkehr ist kein freier Marktteilnehmer, sondern ein Betrieb im künstlichen Koma.

In einem öffentlich verbreiteten Videoausschnitt wird daraus jedoch eine verführerisch einfache Rettung gebaut: Man gründe eine US-amerikanische LLC, lasse sie in Deutschland registrieren, eröffne US-Konten – und stehe plötzlich unter dem First Amendment. Deutschland könne wegen Meinungsäußerungen kaum noch eingreifen, Konten seien schwerer zu schließen oder zu pfänden, Immobilien besser gegen Enteignung geschützt.

Der Ausschnitt wurde von einem ausdrücklich als lizenziert bezeichneten Fan-Kanal verbreitet und verweist auf die vollständige Folge „Ist es Zeit für mich, das Land zu verlassen?“ von „ungeskriptet“ mit Ben und Christoph Heuermann. Das angezeigte Transkript wurde automatisch synchronisiert. Deshalb behandelt dieser Beitrag die erkennbaren Rechtsbehauptungen, nicht jede möglicherweise fehlerhaft transkribierte Formulierung als wörtliches Zitat. Die konkrete Kontokündigung und ihre behauptete politische Ursache sind durch den Ausschnitt allein nicht belegt.

Das klingt nach internationaler Strategie. Tatsächlich werden Gesellschaftsrecht, Steuerrecht, Meinungsfreiheit, Bankaufsicht und Vollstreckung zu einem Schutzschild zusammengeschoben, das in dieser Form nicht existiert.

Die wahre Geschichte ist interessanter: Eine LLC kann ein legitimes Werkzeug für grenzüberschreitende Geschäfte sein. Wer sie aber als Fluchttunnel aus deutschem Recht verkauft, macht aus berechtigter Debanking-Angst ein Geschäftsmodell.

Der wahre Kern: Eine LLC kann in Deutschland tätig sein

Eine wirksam gegründete US-LLC kann in Deutschland grundsätzlich anerkannt werden. Sie kann hier Geschäfte betreiben und eine inländische Zweigniederlassung zum Handelsregister anmelden. §§ 13d, 13e und 13g HGB regeln genau solche Niederlassungen ausländischer Gesellschaften.

Das ist keine geheime Nachkriegsabkürzung. Es ist normaler grenzüberschreitender Wirtschaftsverkehr.

Auch der Hinweis auf fehlendes Stammkapital hat einen wahren Kern. Viele US-Bundesstaaten verlangen für eine LLC kein gesetzliches Mindestkapital, das den 25.000 Euro einer deutschen GmbH entspricht. Das kann Gründungskosten und formale Hürden senken.

Doch an dieser Stelle endet die belastbare Abkürzung. Die Eintragung einer Zweigniederlassung verwandelt Köln nicht in amerikanisches Hoheitsgebiet. Sie macht aus deutschem Tätigkeitsrecht keine unverbindliche Empfehlung. Und sie verleiht dem Betreiber weder Diplomatenstatus noch einen verfassungsrechtlichen Tarnumhang.

Das First Amendment ist kein Exportartikel

Der gröbste Fehler des Ausschnitts ist die Behauptung, eine US-Firma könne sich in Deutschland auf das First Amendment berufen und sei deshalb gegen Eingriffe wegen Meinungsäußerungen geschützt.

Das First Amendment bindet amerikanische staatliche Stellen. Es ist keine weltweite Lizenz, mit einer in den USA gegründeten Gesellschaft die Rechtsordnung anderer Staaten abzuschalten.

Wer von Deutschland aus publiziert, hier ein Unternehmen führt oder mit Inhalten Wirkungen im deutschen Rechtsraum erzeugt, bleibt grundsätzlich Adressat deutschen Rechts. Für Inlandstaten gilt § 3 StGB. § 9 StGB erfasst Handlungs- und Erfolgsorte. Auch zivilrechtliche Ansprüche wegen Persönlichkeitsrecht, Wettbewerb, Urheberrecht oder Unterlassung verschwinden nicht, weil auf dem Briefkopf „LLC“ steht.

Die deutsche Meinungsfreiheit steht in Art. 5 Grundgesetz. Sie ist stark, aber nicht schrankenlos. Über ihre Grenzen entscheiden deutsche Verfassung, Gesetze und Gerichte – nicht die Rechtsform eines Medienunternehmens.

Eine US-Gesellschaft kann politischen und diplomatischen Einfluss interessanter machen. Das ist aber kein einklagbarer Schutzbrief. Zwischen „Washington könnte sich politisch interessieren“ und „Deutschland kann rechtlich nichts mehr machen“ liegt der Unterschied zwischen Machtanalyse und Märchen.

Der Vertrag von 1954 schafft keine Rechtsinsel

Im Video wird ein deutsch-amerikanisches Nachkriegsabkommen als Grundlage weitreichenden Schutzes beschrieben. Gemeint ist der Freundschafts-, Handels- und Schifffahrtsvertrag von 1954.

Dieser Vertrag ist real. Er unterstützt die Anerkennung ordnungsgemäß gegründeter Gesellschaften und ihre geschäftliche Betätigung. Genau deshalb können US-Gesellschaften in Deutschland nicht so behandelt werden, als existierten sie rechtlich gar nicht.

Die genaue Fundstelle lautet: Freundschafts-, Handels- und Schifffahrtsvertrag vom 29. Oktober 1954, veröffentlicht im Bundesgesetzblatt 1956 II ab Seite 487 und in der amtlichen UN-Vertragssammlung als Band 273, Seite 3, Vertragsnummer 3943. Damit ist der Vertrag überprüfbar benannt – ohne ihm einen Schutzumfang anzudichten, den sein Text nicht trägt.

Aber Anerkennung ist keine Immunität. Der Vertrag stellt die Tätigkeit im Gaststaat unter dessen Gesetze und Vorschriften. Er schafft Gleichbehandlung und Marktzugang, nicht amerikanische Hoheitsgewalt auf deutschem Boden.

Die Erzählung von fortdauernder Besatzung vernebelt mehr, als sie erklärt. Ein bilateraler Wirtschaftsvertrag ist kein Beweis dafür, dass eine LLC über deutschem Zivil-, Straf-, Medien- oder Verwaltungsrecht steht.

Steuerlich ist die LLC kein Wunschzettel

Auch die Aussage, eine LLC werde in Deutschland einfach „wie eine GmbH“ versteuert, ist zu glatt.

Die deutsche Finanzverwaltung und Rechtsprechung arbeiten mit einem Typenvergleich. Entscheidend sind konkrete Satzung, Organisation, Rechte der Mitglieder, Geschäftsführung und Gewinnverteilung. Eine LLC kann aus deutscher Sicht eher einer Kapitalgesellschaft oder eher einer Personengesellschaft ähneln.

Die zentrale Verwaltungsfundstelle ist das BMF-Schreiben vom 19. März 2004, Aktenzeichen IV B 4 – S 1301 USA – 22/04, veröffentlicht im Bundessteuerblatt I 2004 auf Seite 411. Schon diese amtliche Systematik widerspricht dem Versprechen, jede LLC werde hier automatisch wie eine GmbH behandelt.

Hinzu kommen die tatsächlichen Verhältnisse. Wo sitzt die Geschäftsleitung? Wo arbeitet das Team? Wo befindet sich eine Betriebsstätte? Wo wird Wert geschaffen? Eine Briefkastenadresse in Wyoming beantwortet diese Fragen nicht.

Wer in Deutschland lebt, von Deutschland aus entscheidet und hier wirtschaftet, kann deutsche Körperschaft-, Einkommen-, Gewerbe- und Umsatzsteuerpflichten auslösen. Die amerikanische „check-the-box“-Wahl bindet die deutsche Einordnung nicht automatisch.

Das macht die LLC nicht unbrauchbar. Es macht sie beratungsintensiv. Wer sie als steuerlich neutrale GmbH ohne Stammkapital verkauft, verschweigt genau den Teil, an dem Gestaltungen teuer und riskant werden.

Debanking: Das Problem ist real, der LLC-Zauber nicht

Die stärkste Seite der Erzählung ist ihr Ausgangspunkt. Geschäftskonten können gekündigt werden. Zahlungsdienstleister können Beziehungen beenden. Bei Unternehmen gibt es keinen allgemeinen gesetzlichen Basiskontoanspruch wie für Verbraucher.

Aber auch hier entscheidet der konkrete Fall. Ein Geschäftskonto ist regelmäßig Teil eines Zahlungsdiensterahmenvertrags. Vertrag, AGB, Kündigungsfrist, Institutstyp und Kündigungsgrund müssen geprüft werden. Eine fristlose Kündigung verlangt grundsätzlich einen wichtigen Grund und eine Interessenabwägung. Private Banken, öffentlich-rechtliche Sparkassen und politisch oder staatlich gebundene Institute sind nicht in jeder Hinsicht gleich zu behandeln.

Politische Meinung ist im zivilrechtlichen Benachteiligungskatalog des § 19 AGG nicht pauschal als geschütztes Merkmal aufgeführt. Das bedeutet nicht, dass jede politische Kontokündigung rechtmäßig wäre. Es bedeutet, dass die juristische Antwort nicht aus einem einzigen Schlagwort folgt.

Vor allem beweist ein Pop-up keine politische Motivation. Ohne Kündigungsschreiben, Vertrag, Banktyp, Frist und Kommunikation bleibt die Behauptung „wegen der falschen Gäste“ eine Vermutung. Sie kann stimmen. Sie kann aber auch Compliance, Risikopolitik, Geldwäscheprüfung, Vertragsverstöße oder andere Gründe verdecken.

Seriöse Kritik an Debanking beginnt deshalb mit Dokumenten. Die emotionale Lücke zwischen Kontoschließung und geklärtem Grund ist der Ort, an dem politische Erzählungen wachsen.

Auch amerikanische Banken kündigen Konten

Die LLC garantiert kein US-Konto. Banken verlangen Gründungsunterlagen, Steueridentifikation, Vertretungsnachweise und Angaben zu wirtschaftlich Berechtigten. Sie bewerten Geschäftsmodell, Länderbezug, Transaktionen, Sanktionen und Geldwäscherisiken.

US-Banken unterliegen ebenfalls umfangreichen KYC- und AML-Pflichten. Eine ausländisch beherrschte LLC mit Remote-Geschäft kann weniger, nicht mehr, attraktiv erscheinen. Ein Konto kann abgelehnt, eingeschränkt oder nach Vertrag beendet werden.

Das First Amendment hilft auch hier nicht automatisch. Private Banken sind keine amerikanische Regierungsbehörde. Wer behauptet, eine US-Bank werde politische Aktivität begrüßen, weil sie zur jeweiligen Regierung passe, ersetzt Vertrags- und Aufsichtsrecht durch Spekulation.

Ein zweites Konto in einem anderen Rechtsraum kann betriebliche Resilienz erhöhen. Das ist vernünftiges Risikomanagement. Ein einziges US-Konto als angeblich unkündbare Festung ist das Gegenteil: eine neue Abhängigkeit, nur weiter entfernt.

Ein US-Konto ist kein Vollstreckungsbunker

Ausländische Konten können eine Vollstreckung komplizierter machen. Zuständigkeit, Anerkennung eines deutschen Titels und Verfahren im US-Bundesstaat kosten Zeit und Geld. Die europäische Kontenpfändungsverordnung hilft bei einer US-Bank nicht.

Aber „komplizierter“ ist nicht „unpfändbar“.

Gläubiger können je nach Konstellation deutsche Urteile in den USA anerkennen und dort vollstrecken lassen. Vermögen, Forderungen, Ausschüttungen oder Zahlungseingänge in Deutschland bleiben weitere Ansatzpunkte. Auch LLC-Anteile und Ansprüche gegen die Gesellschaft können relevant werden.

Wer Komplexität als Immunität verkauft, verschweigt nicht nur das Recht. Er verführt Unternehmer dazu, auf eine Struktur zu vertrauen, die im Ernstfall vielleicht gerade dann zusammenfällt, wenn sie gebraucht wird.

Deutsche Immobilien bleiben in Deutschland

Noch deutlicher wird der Denkfehler bei Immobilien. Ein Grundstück in Deutschland unterliegt deutschem Sachen-, Grundbuch-, Vollstreckungs- und Enteignungsrecht – unabhängig davon, ob im Grundbuch eine GmbH oder eine US-LLC steht.

Art. 14 Abs. 3 Grundgesetz erlaubt Enteignungen zum Wohl der Allgemeinheit auf gesetzlicher Grundlage und gegen Entschädigung. Internationale Verträge können Gleichbehandlung, Diskriminierungsschutz oder Entschädigungsfragen beeinflussen. Sie teleportieren das Grundstück aber nicht nach Delaware.

Gerade bei Immobilien ist die Erzählung vom ausländischen Schutzmantel gefährlich. Sie klingt nach geopolitischer Raffinesse, obwohl der Vermögenswert physisch, rechtlich und registermäßig in Deutschland bleibt.

Transparenz endet nicht an der US-Grenze

Auch steuerlich ist das US-Konto kein dunkler Raum. FATCA, das deutsch-amerikanische Abkommen, deutsche Erklärungspflichten und weitere Informationswege sorgen dafür, dass internationale Strukturen nicht automatisch unsichtbar sind.

Richtig ist: Die USA nehmen nicht wie ein gewöhnlicher CRS-Staat am Common Reporting Standard teil. Daraus folgt aber keine pauschale Geheimhaltung. Ein in Deutschland steuerlich Ansässiger muss ausländische Einkünfte und relevante Strukturen erklären. Wer das nicht tut, baut keinen Freiheitsbunker, sondern ein Steuer- und Strafrisiko.

Was digitale Souveränität hier wirklich bedeutet

Die richtige Antwort auf Debanking ist nicht nationale Romantik. Ein deutsches Konto allein kann ein Single Point of Failure sein. Internationale Anbieter, getrennte Zahlungswege und belastbare Rückfallpläne können sinnvoll sein.

Aber digitale und wirtschaftliche Souveränität entsteht nicht durch magische Rechtsformen. Sie entsteht durch überprüfbare Redundanz:

  • mehrere rechtmäßig geführte Konten bei unterschiedlichen Instituten,
  • dokumentierte Zahlungs- und Buchhaltungswege,
  • transparente wirtschaftlich Berechtigte,
  • getestete Wechsel- und Notfallprozesse,
  • rechtliche Prüfung statt YouTube-Gewissheit,
  • Infrastruktur, Domains und Server ohne unnötige Einzelabhängigkeit.

Ein Selfhosting-Betreiber würde nie behaupten, ein Backup sei sicher, nur weil es auf einem Server in den USA liegt. Er würde Verschlüsselung, Zugriff, Versionierung und Restore testen. Bei Firmenstrukturen gilt derselbe Maßstab. Nicht die Flagge schützt. Der nachgewiesene Rückweg schützt.

Fazit: Die Angst ist echt, der Schutzschild erfunden

Eine Kontokündigung kann ein Unternehmen existenziell treffen. Wer wegen legaler politischer Arbeit vom Zahlungsverkehr ausgeschlossen wird, verdient Aufklärung, Rechtsschutz und öffentliche Debatte.

Genau deshalb ist die LLC-Erzählung so problematisch. Sie nimmt eine reale Angst und verkauft dafür einen Schutz, den die Rechtsform nicht leisten kann.

Der belastbare Satz lautet: Eine US-LLC kann ein sinnvolles Instrument für echte internationale Tätigkeit sein. Sie ist kein First-Amendment-Pass für Deutschland, kein unkündbares Bankkonto, kein Pfändungsschutz und keine Enteignungsbremse.

Freiheit braucht mehr als eine Flagge im Gesellschaftsregister. Sie braucht Rechtskenntnis, belastbare Verträge, technische und finanzielle Redundanz – und die Ehrlichkeit, zwischen einer komplizierten Option und einem erfundenen Ausweg zu unterscheiden.

Quellen

  1. Videoausschnitt und vollständige Folge:

    https://www.youtube.com/watch?v=k6ESGVbvYiY

    https://www.youtube.com/watch?v=eqo5HZIKJ54
  2. HGB, Zweigniederlassungen ausländischer Gesellschaften:

    https://www.gesetze-im-internet.de/hgb/__13d.html

    https://www.gesetze-im-internet.de/hgb/__13e.html

    https://www.gesetze-im-internet.de/hgb/__13g.html
  3. BFH, Einordnung einer US-LLC:

    https://www.bundesfinanzhof.de/de/entscheidung/entscheidungen-online/detail/STRE202150148/
  4. First Amendment, US Congress:

    https://constitution.congress.gov/constitution/amendment-1/
  5. Grundgesetz, Art. 5 und Art. 14:

    https://www.gesetze-im-internet.de/gg/art_5.html

    https://www.gesetze-im-internet.de/gg/art_14.html
  6. Strafgesetzbuch, §§ 3 und 9:

    https://www.gesetze-im-internet.de/stgb/__3.html

    https://www.gesetze-im-internet.de/stgb/__9.html
  7. Zivilprozessordnung, § 21 sowie §§ 828 und 829:

    https://www.gesetze-im-internet.de/zpo/__21.html

    https://www.gesetze-im-internet.de/zpo/__828.html

    https://www.gesetze-im-internet.de/zpo/__829.html
  8. BGB, §§ 675e, 675h und 314:

    https://www.gesetze-im-internet.de/bgb/__675e.html

    https://www.gesetze-im-internet.de/bgb/__675h.html

    https://www.gesetze-im-internet.de/bgb/__314.html
  9. Zahlungskontengesetz, §§ 31 und 38:

    https://www.gesetze-im-internet.de/zkg/__31.html

    https://www.gesetze-im-internet.de/zkg/__38.html
  10. Geldwäschegesetz, §§ 10 und 15:

    https://www.gesetze-im-internet.de/gwg_2017/__10.html

    https://www.gesetze-im-internet.de/gwg_2017/__15.html
  11. FinCEN, Customer Due Diligence Rule:

    https://www.fincen.gov/resources/statutes-and-regulations/cdd-final-rule
  12. IRS, FATCA:

    https://www.irs.gov/businesses/corporations/foreign-account-tax-compliance-act-fatca
  13. FATCA-Abkommen Deutschland–USA:

    https://home.treasury.gov/system/files/131/FATCA-Agreement-Germany-5-31-2013.pdf
  14. EU-Kontenpfändungsverordnung 655/2014:

    https://eur-lex.europa.eu/eli/reg/2014/655/oj
  15. BMF-Schreiben vom 19. März 2004, IV B 4 – S 1301 USA – 22/04, BStBl I 2004, S. 411: „Steuerliche Einordnung der nach dem Recht der Bundesstaaten der USA gegründeten Limited Liability Company“.
  16. Freundschafts-, Handels- und Schifffahrtsvertrag Deutschland–USA vom 29. Oktober 1954, BGBl. 1956 II S. 487; UNTS Band 273, S. 3, Nr. 3943, amtlicher englischer Volltext:

    https://treaties.un.org/doc/Publication/UNTS/Volume%20273/volume-273-I-3943-English.pdf

CTA

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Android macht Freiheit zum Expertenmodus: Was Googles Entwicklerverifizierung für F-Droid bedeutet

Ein App-Store darf Regeln für seinen eigenen Katalog setzen. Ein Betriebssystemkonzern, der auch die Installierbarkeit außerhalb seines Stores an eine zentrale Registrierung bindet, tut etwas anderes: Er stellt den Türsteher nicht vor den Laden, sondern vor das Gerät.

Google beginnt laut aktueller Entwicklerdokumentation am 30. September 2026 mit der regionalen Durchsetzung seiner Android-Entwicklerverifizierung. Zunächst genannt werden Brasilien, Indonesien, Singapur und Thailand; ein weiterer weltweiter Ausbau ist ab 2027 angekündigt. Apps auf zertifizierten Android-Geräten sollen einem verifizierten Entwickler zugeordnet sein – ausdrücklich auch dann, wenn sie nicht aus Google Play kommen.

Das ist kein weltweites Sideloading-Verbot am 30. September. Es ist aber der Aufbau einer zentralen Kontrollschicht über alternative App-Verteilung. Für F-Droid trifft diese Schicht den Kern des eigenen Modells.

Was belegt ist – und was nicht

Google kündigte die Entwicklerverifizierung im August 2025 als Sicherheitsmaßnahme an. Das Unternehmen will wiederkehrende Betrüger und Schadakteure stärker an eine überprüfte Identität binden. Die Registrierung soll nicht nur den Play Store betreffen, sondern Apps aus anderen Stores und aus direkter Verteilung auf zertifizierten Android-Geräten.

Google beschreibt das Verfahren selbst als Identitätskontrolle, nicht als inhaltliche App-Prüfung. Das ist eine wichtige Grenze: Verifiziert wird zunächst, wer eine App registriert. Nicht bewiesen wird damit, dass ihr Quellcode sicher ist oder ihr Binärpaket tatsächlich aus einem veröffentlichten Quellstand entstand.

Die Durchsetzung beginnt nach aktueller Dokumentation regional. Deutschland gehört nicht zur ersten Ländergruppe. Deshalb sind Schlagzeilen wie „Ab 30. September ist F-Droid weltweit tot“ sachlich falsch. Ebenfalls nicht belastbar bestätigt ist eine pauschale Android-Versionsgrenze. Belegt ist die Kategorie „certified Android devices“.

Offen bleibt am 4. August, welche Stores und Installationswege zum Start praktisch erfasst werden, wie Updates bereits installierter unregistrierter Apps behandelt werden und welche Systemkomponente die Regel auf unterschiedlichen Geräten durchsetzt. Diese Fragen bleiben für die weitere Beobachtung offen. Die drei zentralen Primärquellen waren unmittelbar vor der Veröffentlichung weiterhin erreichbar.

Der Advanced Flow: Ausnahme mit eingebauter Abschreckung

Nach Kritik kündigte Google im März 2026 einen „Advanced Flow“ an. Technisch erfahrene Nutzer sollen damit weiterhin Apps nicht verifizierter Entwickler installieren können. Nach Googles Beschreibung gehören dazu:

  1. Entwicklermodus aktivieren,
  2. bestätigen, nicht von einer anderen Person angeleitet zu werden,
  3. das Telefon neu starten,
  4. sich erneut authentifizieren,
  5. einmalig einen Tag warten,
  6. Installationen für sieben Tage oder unbefristet erlauben.

Eine Warnung bleibt bestehen. Der Ablauf soll Telefonbetrug und Social Engineering erschweren: Neustart und Wartezeit unterbrechen Fernanleitung und künstlichen Zeitdruck. Das ist ein legitimes Sicherheitsziel.

Trotzdem verändert der Ablauf die Bedeutung von Wahlfreiheit. Eine nicht registrierte App ist nicht mehr ein normaler Installationsfall, über den der Eigentümer nach einer verständlichen Warnung entscheidet. Sie wird zum Expertenfall mit absichtlich eingebauter Reibung. Dass eine dauerhafte Freischaltung angekündigt ist, verhindert ein Totalverbot. Es stellt aber keine Gleichwertigkeit der Vertriebswege her.

Für Hobbyentwickler ist zusätzlich ein kostenloses Modell ohne amtlichen Identitätsnachweis und Gebühr vorgesehen. Es ist auf höchstens zwanzig ausdrücklich autorisierte Geräte begrenzt. Für eine Lerngruppe kann das reichen. Für einen öffentlichen freien App-Store, einen Verein oder eine Community mit wechselnden Mitgliedern ist diese Ausnahme keine Lösung.

Warum F-Droid anders vertraut

F-Droid ist nicht bloß ein zweiter Play Store mit anderem Logo. Das Projekt veröffentlicht freie Software über eine eigene Metadaten- und Build-Pipeline. Regulär wird eine App aus dem angegebenen Quellcode gebaut und mit einem F-Droid-Schlüssel signiert. Dokumentierte Anti-Features machen beispielsweise Werbung, Tracking oder unfreie Abhängigkeiten sichtbar.

Bei reproduzierbaren Builds kann F-Droid eine upstream-signierte APK gegen einen eigenen Nachbau prüfen. Stimmen die Pakete kryptografisch überein, beschreibt die technische Dokumentation einen Weg für die Veröffentlichung mit der ursprünglichen Signatur. Das garantiert weder fehlerfreien Code noch einen reproduzierbaren Build für jede App. Es schafft aber einen überprüfbaren Zusammenhang zwischen Quellcode, Buildprozess und ausgeliefertem Paket.

Googles Modell beantwortet eine andere Frage: Welche registrierte Identität darf welche Paketkennung verteilen? Genau diese Verbindung kollidiert mit F-Droid. Das Projekt kann nicht alle Upstream-Entwickler zwingen, sich bei Google zu registrieren. Es kann die Paketkennungen fremder Projekte auch nicht einfach selbst beanspruchen, ohne eine zentrale Vertriebsrolle für Software einzunehmen, die ihm nicht gehört.

F-Droid nennt die Regel daher eine existenzielle Bedrohung für seine bisherige Arbeitsweise. Das ist die Position eines direkt betroffenen Projekts, kein neutraler Beweis für ein bereits feststehendes Ende. Die strukturelle Kollision ist dennoch real: Ein dezentrales Build- und Signaturmodell trifft auf ein zentrales Identitäts- und Paketregister.

Entwickleridentität ersetzt keine Softwareprüfung

Googles Sicherheitsargument ist nicht erfunden. Wer Betrugs-Apps unter ständig wechselnden Namen verbreitet, kann durch eine Identitätsbindung leichter verfolgt und ausgeschlossen werden. Google verweist außerdem auf eine eigene Analyse, nach der Internet-Sideloading-Quellen mehr als fünfzigmal so viel Malware enthielten wie Google Play.

Belegt ist, dass Google diese Zahl nennt. Die abgerufene Veröffentlichung legt Methodik, Stichprobe und Vergleichsdefinition jedoch nicht so offen, dass die Zahl unabhängig reproduziert werden könnte. Sie muss daher als Konzernangabe bezeichnet werden, nicht als neutraler Messwert.

Vor allem prüft eine Identität nicht den Code. Ein bekanntes Entwicklerkonto kann übernommen werden. Eine legitime App kann später eine kompromittierte Bibliothek einbauen. Ein registriertes Binärpaket kann Funktionen enthalten, die im veröffentlichten Quellcode nicht sichtbar sind. Signaturen, nachvollziehbare Builds, Berechtigungskontrollen und transparente Updateketten bleiben notwendig.

Die Debatte darf deshalb nicht auf „Registrierung oder Chaos“ verkürzt werden. Es gibt weitere Schutzmechanismen: abgestufte Warnungen, lokale Prüfungen, transparente Signaturinformationen, reproduzierbare Builds, föderierte Vertrauenslisten und einen klaren Eigentümerentscheid. Keine dieser Maßnahmen ist allein perfekt. Gerade das spricht gegen einen zentralen Registerpunkt als universelle Lösung.

Die eigentliche Macht liegt in der Paketkennung

Die politische Machtverschiebung entsteht aus der Kombination von Entwickleridentität, Paketkennung und Installierbarkeit. Wer diese Verbindung kontrolliert, entscheidet nicht nur, wer in einem Store sichtbar ist. Er entscheidet, welcher Anbieter Software unter welchem Namen normal auf einem Gerät verteilen darf.

Heute wird dieser Punkt mit Betrugsabwehr begründet. Dieselbe Infrastruktur kann künftig Gebühren, Vertragsbedingungen, regionale Sperren oder politische Vorgaben durchsetzen. Das ist keine Behauptung, dass Google all diese Möglichkeiten einsetzen wird. Es ist eine Analyse dessen, was eine zentrale Kontrollarchitektur technisch und wirtschaftlich ermöglicht.

Apple liefert in der EU ein warnendes Vergleichsbild. Alternative App-Marktplätze sind dort grundsätzlich möglich, bleiben aber an Apple-Autorisierung, Notarisierung, Entitlements und erhebliche Betreiberanforderungen gebunden. Das beweist nicht, dass Google Apples Modell kopiert. Es zeigt, dass „Alternative erlaubt“ und „Alternative unabhängig“ zwei sehr verschiedene Aussagen sind.

Konkrete Folgen für freie Communities

Eine kleine Matrix-Community kann einen angepassten Client für Moderation und Raumverwaltung bauen. Sie kann den Quellcode veröffentlichen, die APK signieren und über ein eigenes F-Droid-Repository verteilen. Mit der neuen Kontrollschicht kann auf zertifizierten Geräten trotzdem eine Google-Registrierung zum zusätzlichen Engpass werden.

Ein Selfhosting-Projekt kann eine kleine App für Backup-Status oder Token-Widerruf bereitstellen. Zwanzig Testgeräte reichen vielleicht während der Entwicklung. Sie reichen nicht, wenn Administratoren, Helfer, Ersatzgeräte und eine offene Nutzergemeinschaft versorgt werden sollen.

Die Hürde trifft damit nicht nur unbekannte APK-Portale. Sie trifft auch Software, deren Quellcode offenliegt, deren Build dokumentiert ist und deren Nutzer den Anbieter bewusst gewählt haben. Eine identische Warn- und Sperrlogik behandelt unterschiedliche Vertrauenssituationen gleich.

Bewertung: Schutz ja, Konzernpassamt nein

Eigene redaktionelle Bewertung: Google benennt ein reales Problem. Social Engineering und Schadsoftware außerhalb kuratierter Stores verdienen wirksame Gegenmaßnahmen. Eine zentrale Registrierung kann die Kosten für wiederholten Missbrauch erhöhen.

Die Machtkonzentration geht dennoch zu weit. Ein Konzern sollte nicht zugleich das dominante Betriebssystemökosystem, einen zentralen Store, die Entwickleridentität, die Paketzuordnung und den normalen Installationsweg kontrollieren. Sicherheit darf Entscheidungen des Eigentümers informieren und in nachweisbaren Risikosituationen erschweren. Sie darf nicht aus freier Software einen genehmigungspflichtigen Sonderfall machen.

Der Advanced Flow bewahrt eine Restfreiheit. Aber eine Freiheit hinter Entwicklermodus, Belehrung, Neustart und Wartefrist ist praktisch schwächer als ein normaler Eigentümerentscheid. Vor allem bleibt dieser Weg von Google gestaltet und jederzeit veränderbar.

Fazit: Offenheit braucht einen normalen Weg

F-Droid ist am 30. September nicht automatisch tot. Sideloading wird nicht weltweit mit einem Schalter abgeschafft. Solche Übertreibungen helfen nur Google, berechtigte Kritik als Panik abzutun.

Der belastbare Befund ist schärfer: Google baut eine Kontrollschicht auf, die über den eigenen Store hinausreicht. Sie bindet normale Installierbarkeit an eine zentrale Zuordnung von Entwickleridentität und Paketkennung. F-Droids Modell aus freiem Quellcode, eigener Build-Pipeline und unabhängiger Signatur passt nicht sauber in dieses Register.

Digitale Souveränität bedeutet nicht, Warnungen abzuschaffen. Sie bedeutet, dass nach einer verständlichen Warnung die letzte Entscheidung beim Eigentümer liegt. Ein Smartphone gehört dir nicht vollständig, wenn der Konzern nach dem Kauf bestimmt, welcher Entwickler darauf normal Software verteilen darf.

Offene Prüfpunkte für die weitere Beobachtung

  • allgemeine Verfügbarkeit und endgültige Oberfläche des Advanced Flow
  • exakte Länder-, Store-, Geräte- und Updateabdeckung
  • technische Komponente der Durchsetzung auf zertifizierten Geräten
  • aktueller F-Droid-Plan für Bestands-Apps, Signaturen und Paketkennungen
  • amtliche Stellungnahmen oder Verfahren europäischer Behörden

Quellen

  1. Google, Android Developers Blog: „A new layer of security for certified Android devices“

https://android-developers.googleblog.com/2025/08/elevating-android-security.html

  1. Google, Android Developers Blog: „Balancing openness and choice with safety“

https://android-developers.googleblog.com/2026/03/android-developer-verification.html

  1. Google, Android Developers: „Developer verification“

https://developer.android.com/developer-verification

  1. F-Droid: „F-Droid and Google’s Developer Registration Decree“

https://f-droid.org/2025/09/29/google-developer-registration-decree.html

  1. F-Droid-Dokumentation: „Reproducible Builds“

https://f-droid.org/en/docs/Reproducible_Builds/

  1. Apple Developer Support: „Getting started as an alternative app marketplace in the European Union“

https://developer.apple.com/support/alternative-app-marketplace-in-the-eu/

  1. Europäische Kommission: „DMA designated Gatekeepers“

https://digital-markets-act.ec.europa.eu/gatekeepers-portal_en

CTA

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Open Source als Standard? Deutschlands neue Beschaffungsregeln sind noch keine Wende

Deutschland hat 2026 zwei echte Schritte in Richtung digitaler Souveränität gemacht. Öffentliche Vergabestellen dürfen digitale Souveränität ausdrücklich als Zuschlagskriterium berücksichtigen. Außerdem wurden acht EVB-IT-Vertragsmuster modernisiert, damit Open-Source-Software rechtssicher beschafft werden kann.

Das klingt nach einer Open-Source-Wende. Es ist aber noch keine.

Der entscheidende Unterschied steckt in einem einzigen Wort: kann. § 58 Absatz 2 der Vergabeverordnung erlaubt, Aspekte digitaler Souveränität bei der Zuschlagsentscheidung zu berücksichtigen. Die Vorschrift verpflichtet Vergabestellen nicht dazu. Im verkündeten Regelungstext des Vergabebeschleunigungsgesetzes kommen die Begriffe „Open Source“, „Software“ und „Quellcode“ nicht vor. [3][4]

Die Bundesregierung hat eine Tür geöffnet. Ob Verwaltungen hindurchgehen, entscheidet sich in Ausschreibungen, Verträgen, Budgets und im späteren Betrieb.

Was seit Juli 2026 tatsächlich gilt

Das Gesetz zur Beschleunigung der Vergabe öffentlicher Aufträge trat am 1. Juli 2026 in Kraft. Sein Hauptzweck ist eine schnellere und einfachere öffentliche Beschaffung. Die Reform erhöht unter anderem Direktauftragsgrenzen, flexibilisiert Gesamtvergaben, verringert Nachweispflichten und beschleunigt Nachprüfungsverfahren. [3][6]

Für digitale Souveränität ist die Änderung von § 58 Absatz 2 VgV relevant. Neben Preis und Kosten können qualitative, umweltbezogene oder soziale Kriterien einfließen. Neu genannt werden „Aspekte der digitalen Souveränität“. [4]

Das erweitert den Spielraum. Eine Behörde kann künftig deutlicher bewerten, ob sie Daten exportieren, Schnittstellen dokumentiert nutzen oder einen Betreiber wechseln kann. Sie kann Abhängigkeiten und Kontrollrechte in die Zuschlagsentscheidung einbeziehen, statt nur auf den kurzfristig niedrigsten Preis zu schauen.

Belegte Tatsache: Digitale Souveränität ist nun ausdrücklich als mögliches Zuschlagskriterium genannt.

Ebenso belegt: Eine allgemeine gesetzliche Pflicht zu Open Source enthält der veröffentlichte Normtext nicht.

Genau an diesem Punkt formuliert der am 28. Juli 2026 veröffentlichte Deutschland-Bericht des europäischen Open Source Observatory, kurz OSOR, zu stark. Der Bericht beschreibt Deutschland als führendes Beispiel für Open Source im öffentlichen Sektor. Er behauptet jedoch auch, das Gesetz verpflichte Beschaffungsstellen zur Berücksichtigung digitaler Souveränität bei nicht preislichen Kriterien. Zudem soll ein Anhang Open Source und offene Standards als Beispiele nennen. Im verkündeten deutschen Regelungstext lässt sich diese Darstellung nicht bestätigen. [1][2][3]

Nachprüfung vom 31. Juli 2026: Die Fußnote 37 des OSOR-Berichts verweist ausschließlich auf BGBl. 2026 I Nr. 137. Der dort veröffentlichte 19-seitige Regelungstext enthält keinen Anhang und keinen Treffer für „Open Source“, „offene Standards“, „Software“ oder „Quellcode“. Damit ist die Behauptung durch die vom OSOR selbst genannte Quelle nicht gedeckt. Sie wird in diesem Entwurf als fehlerhafte Darstellung des Länderberichts behandelt, nicht als Inhalt des geltenden Gesetzes.

Bewertung: Wer Open Source stärken will, sollte ein „kann“ nicht zum „muss“ aufblasen. Die Übertreibung verdeckt gerade jene Umsetzungslücke, über die politisch gestritten werden muss.

Die EVB-IT können mehr bewirken als eine Sonntagsrede

Praktisch womöglich wichtiger als der neue Gesetzessatz sind die modernisierten EVB-IT. Diese ergänzenden Vertragsbedingungen und Muster werden von Bund, Ländern und Kommunen für IT-Leistungen eingesetzt.

Das Bundesministerium für Digitales und Staatsmodernisierung erklärte am 20. März 2026:

  • Acht Vertragsmuster wurden für die rechtssichere Beschaffung von Open Source überarbeitet.
  • Die Entwicklung und Bereitstellung neuer Softwareprojekte als Open Source wird als Standard in den Mustern abgebildet.
  • Die Muster bieten Optionen für mehr Transparenz, darunter die Übergabe einer Software Bill of Materials, kurz SBOM.
  • Proprietäre Software bleibt weiterhin beschaffbar. [5]

Standardklauseln lösen ein reales Problem. Eine Beschaffungsstelle muss nicht für jedes Open-Source-Projekt eine individuelle juristische Konstruktion erfinden. Das senkt Aufwand und Unsicherheit.

Aber ein Mustervertrag ist nur ein Werkzeug. Ob daraus Freiheit entsteht, entscheidet der ausgefüllte Vertrag.

Ein Auftrag kann etwa die Übergabe von Quellcode verlangen. Ohne Build-Anleitung, dokumentierte Abhängigkeiten, Testfälle und Release-Prozess kann ein anderer Betreiber daraus trotzdem kein lauffähiges System erzeugen. Eine SBOM zeigt, welche Komponenten verbaut wurden. Sie spielt aber kein Sicherheitsupdate ein und benennt nicht automatisch die verantwortliche Wartungsstelle.

Bewertung: Die EVB-IT sind ein starker Hebel, weil sie in die tägliche Verwaltungspraxis eingreifen. Ihre Wirkung muss jedoch an realen Verträgen gemessen werden: Welche Klauseln werden übernommen, welche abgewählt, und welche Übergaben werden tatsächlich abgenommen?

Souveränität ist mehr als Serverstandort und Lizenz

Der Begriff „digitale Souveränität“ bleibt gefährlich dehnbar. Ein europäischer Anbieter mit einem deutschen Rechenzentrum kann geschlossene Formate, undokumentierte Schnittstellen und ein proprietäres Kontrollpanel einsetzen. Der Standort allein verändert dann die Machtverteilung nicht.

Umgekehrt ist auch eine freie Lizenz keine Betriebsgarantie. Ein Open-Source-Dienst bleibt abhängig, wenn nur ein Integrator die Konfiguration kennt oder eine einzige Person über privilegierte Zugänge verfügt.

Das lässt sich am Community-Betrieb gut erkennen.

Eine Matrix-Instanz kann vollständig auf Synapse und anderer freier Software beruhen. Wenn Admin-Tokens, Raumrechte, Signaturschlüssel, .well-known-Einträge und Wiederanlaufprozedur nicht dokumentiert sind, kann die Community den Betreiber trotzdem nicht sicher wechseln.

Eine offene Webanwendung kann hinter Nginx laufen. Wenn Reverse-Proxy-Regeln, Zertifikatserneuerung, Datenbankmigration, Monitoring und Secrets beim bisherigen Dienstleister bleiben, ist der Auftraggeber weiterhin gefangen.

Ein Backup kann jeden Abend erfolgreich gemeldet werden. Wenn niemals geprüft wurde, ob Datenbank, Dateien, Konfiguration, Schlüssel und passende Softwareversion auf einer frischen Umgebung wiederhergestellt werden können, ist dieses Backup nur eine Hoffnung.

Technische Bewertung: Souverän ist ein Dienst erst, wenn eine zweite Organisation ihn mit den übergebenen Daten, Rechten und Unterlagen unabhängig wieder in Betrieb nehmen kann.

Zehn Mindestanforderungen für souveräne Verträge

Eine belastbare öffentliche Ausschreibung sollte mindestens folgende Punkte verlangen:

  1. vollständigen Quellcode unter einer anerkannten freien Lizenz;
  2. offene Datenformate und dokumentierte Schnittstellen;
  3. reproduzierbare Bereitstellung, Build-Anleitung und dokumentierte Abhängigkeiten;
  4. eine aktuelle SBOM sowie klare Zuständigkeiten für Sicherheitsmeldungen und Updates;
  5. vollständigen Export von Daten, Konfigurationen, Rollen und Berechtigungen;
  6. kontrollierte Übergabe und Rotation von Domains, Schlüsseln, Zertifikaten und Admin-Zugängen;
  7. unabhängige Betriebs-, Prüf- und Weiterentwicklungsrechte;
  8. Wartungsbudget und einen geregelten Umgang mit Upstream-Projekten;
  9. vertragliche Unterstützung beim Anbieterwechsel;
  10. einen praktisch bestandenen Migrations- und Restore-Test.

Diese Anforderungen machen Beschaffung zunächst aufwendiger. Sie verhindern aber, dass niedrige Einstiegspreise mit späteren Wechselkosten erkauft werden. Der Exit muss von Anfang an Teil der Gesamtbetriebskosten sein.

Der Deutschland-Stack ist ein Aufbau, kein fertiger Zustand

Der Deutschland-Stack soll eine gemeinsame, interoperable und europäisch anschlussfähige Grundlage für Bund, Länder und Kommunen schaffen. Als Leitlinien nennt das Ministerium offene Standards, Open-Source-Lösungen, Wiederverwendbarkeit und die Verringerung externer Abhängigkeiten. Zu den ersten Bereichen gehören Identität, Postfach und Interaktion, Datenaustausch, Nachweisabruf sowie Ein- und Auszahlung. [7]

Bund und Länder verständigten sich im IT-Planungsrat im März 2026 auf Eckpunkte für einen gemeinsamen Plattformkern und ein initiales Portfolio. Gleichzeitig beschreibt das Ministerium einen schrittweisen Aufbau bis 2028. Roadmap, Steuerung, Umsetzung und Beschaffung werden weiterentwickelt. [7][8]

Das ist ein politischer Aufbauplan, kein Beleg für eine abgeschlossene bundesweite Migration.

Gemeinsame Komponenten können Doppelarbeit vermeiden. Sie schaffen jedoch neue kritische Abhängigkeiten. Fällt eine zentrale Identitäts- oder Austauschkomponente aus, können viele angebundene Dienste gleichzeitig betroffen sein. Deshalb müssen offene Schnittstellen, alternative Implementierungen, Schlüsselrotation, Fehlerzustände und unabhängige Wiederherstellung zum Plattformkern gehören.

Bewertung: Der Deutschland-Stack sollte nicht nur an Konten oder angeschlossenen Diensten gemessen werden. Entscheidend sind nachgewiesene Interoperabilität, alternative Betreiber und bestandene Ausfall- und Migrationstests.

Die Gegenargumente sind berechtigt – aber kein Freifahrtschein

Open Source ist nicht automatisch sicher. Offener Quellcode garantiert keine Prüfung, kein Update und keine schnelle Reaktion auf Schwachstellen. Dafür braucht es gepflegte Meldewege, bezahlte Wartung, nachvollziehbare Builds und klare Verantwortung.

Open Source ist auch nicht automatisch billiger. Schulung, Integration, Support und Bereitschaft kosten Geld. Ein fairer Vergleich muss jedoch auch Preissteigerungen, Datenrückgewinnung und Anbieterwechsel einbeziehen.

Und nicht jede Kommune muss jeden Dienst selbst hosten. Ein kompetenter externer Betreiber kann sicherer und wirtschaftlicher sein. Entscheidend bleibt, ob der Auftraggeber Daten, Rechte, Wissen und Wechselmöglichkeiten behält.

Eine sofortige ausnahmslose Open-Source-Pflicht könnte bei spezialisierten Fachverfahren zu Verzögerungen führen. Die bessere Regel wäre ein verbindlicher Vorrang mit begründungspflichtigen Ausnahmen. Dabei müsste öffentlich festgehalten werden, welche offene Lösung welche Anforderung nicht erfüllt, welche Lock-in-Kosten die proprietäre Ausnahme erzeugt und wann die Entscheidung erneut geprüft wird.

Bewertung: Die Alternative zu blindem proprietärem Einkauf ist nicht blinder Open-Source-Einkauf. Die Alternative ist überprüfbare Beschaffung mit offenen Rechten, professionellem Betrieb und einem realen Ausstieg.

Fazit: Deutschland hat Werkzeuge, noch keine Wende

Deutschland hat 2026 Fortschritte gemacht. Digitale Souveränität kann ausdrücklich in die Zuschlagsentscheidung einfließen. Die EVB-IT senken Hürden für Open-Source-Verträge. Der Deutschland-Stack stellt offene Standards und gemeinsame Komponenten ins Zentrum.

Aber aus einer Möglichkeit folgt keine Praxis. Aus einem Vertragsmuster folgt kein guter Vertrag. Aus einem öffentlichen Repository folgt kein übergabefähiger Betrieb.

Jetzt braucht es messbare Zahlen: Wie viele Vergaben gewichten digitale Souveränität? Wie oft werden die neuen Open-Source-Klauseln genutzt? Welche Verträge enthalten Exit- und Restore-Tests? Wie häufig übernimmt tatsächlich ein zweiter Betreiber?

Meine abschließende Bewertung: Die Open-Source-Wende beginnt erst, wenn eine öffentliche Stelle Nein sagen, den Anbieter wechseln und weiterarbeiten kann. Souveränität ist kein Etikett. Sie ist die belegbare Verteilung von Rechten, Wissen, Geld und Kontrolle.

Quellen

  1. Open Source Observatory / Interoperable Europe Portal: Germany 2026 Country Report, 28. Juli 2026: https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/germany-2026-country-report
  2. OSOR: Open Source Software Country Intelligence Report – Germany, 2026: https://interoperable-europe.ec.europa.eu/sites/default/files/inline-files/germany-2026-osor-country-report.pdf
  3. Bundesgesetzblatt: BGBl. 2026 I Nr. 137 – Gesetz zur Beschleunigung der Vergabe öffentlicher Aufträge, 18. Mai 2026: https://www.recht.bund.de/bgbl/1/2026/137/VO.html
  4. Gesetze im Internet: § 58 Vergabeverordnung, insbesondere Absatz 2 Nummer 4: https://www.gesetze-im-internet.de/vgv_2016/__58.html
  5. Bundesministerium für Digitales und Staatsmodernisierung: Open Source rechtssicher beschaffen, 20. März 2026: https://bmds.bund.de/aktuelles/pressemitteilungen/detail/open-source-rechtssicher-beschaffen
  6. Bundesregierung: Einfachere Verfahren mit dem neuen Vergaberecht, 1. Juli 2026: https://www.bundesregierung.de/breg-de/suche/oeffentliche-vergabe-2376854
  7. Bundesministerium für Digitales und Staatsmodernisierung: Deutschland-Stack: https://bmds.bund.de/themen/digitaler-staat/deutschland-stack
  8. Bundesministerium für Digitales und Staatsmodernisierung: Bund und Länder einigen sich auf gemeinsame Umsetzung des Deutschland-Stacks, 19. März 2026: https://bmds.bund.de/aktuelles/aktuelle-meldungen/detail/gemeinsame-umsetzung-des-deutschland-stacks
  9. Deutscher Bundestag: Stärkung der digitalen Souveränität ist Kernanliegen, zur Antwort der Bundesregierung auf Drucksache 21/1264: https://www.bundestag.de/presse/hib/kurzmeldungen-1106074

CTA

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Freigabe erforderlich: ja
Veröffentlichung erfolgt: nein

Das KI-Label kommt – die Hochrisiko-Kontrolle wartet

Was am 2. August 2026 beim EU AI Act wirklich beginnt, warum Transparenz nicht Kontrolle ersetzt und weshalb Open Source weder Freibrief noch Feindbild ist.

Am 2. August bekommt die europäische KI-Regulierung ein sichtbares Gesicht. Menschen sollen erkennen können, wenn sie mit einem KI-System interagieren. Synthetische Ausgaben sollen maschinenlesbar markiert werden. Deepfakes und bestimmte automatisch erzeugte Texte zu Themen von öffentlichem Interesse müssen offengelegt werden.

Das ist ein Fortschritt. Aber die bequeme Schlagzeile „Jetzt gilt der AI Act“ ist falsch. Die Verordnung trat bereits am 1. August 2024 in Kraft und wird seitdem stufenweise anwendbar. Noch wichtiger: Während die Transparenzregeln jetzt greifen, hat der jüngste AI Omnibus zentrale Pflichten für Hochrisiko-Systeme verschoben. Das sichtbare Label kommt. Die schwierigere Kontrolle wartet.

Was am 2. August tatsächlich passiert

Ab dem 2. August 2026 wird Artikel 50 des AI Act anwendbar. Außerdem beginnt die Durchsetzung wichtiger bereits geltender Vorschriften auf europäischer und nationaler Ebene. Die Regeln für General-Purpose-AI-Modelle gelten schon seit dem 2. August 2025; nun stehen den zuständigen Stellen reale Untersuchungs- und Sanktionsbefugnisse zur Verfügung.

Das europäische AI Office kann laut der offiziellen Übersicht unter anderem Auskünfte verlangen, Zugang zu Modellen und Evaluationen fordern, Korrekturmaßnahmen anordnen und nötigenfalls die öffentliche Verfügbarkeit eines Modells beschränken. Für andere KI-Systeme sind grundsätzlich nationale Marktüberwachungsbehörden zuständig.

Die Kommission nennt je nach Verstoß Höchstgrenzen von bis zu 35 Millionen Euro oder sieben Prozent des weltweiten Jahresumsatzes für verbotene Praktiken sowie bis zu 15 Millionen Euro oder drei Prozent für andere Verstöße. Das sind Maximalwerte. Sie bedeuten nicht, dass jeder fehlerhafte Hinweis automatisch eine Millionenbuße auslöst.

Offen bleibt in der vorliegenden Recherche, welche deutsche Behörde am Stichtag für welchen Systemtyp praktisch zuständig ist, wie konkret Beschwerden eingereicht werden können und ob alle nötigen Fachstellen einsatzbereit sind. Wer dazu mehr behauptet, müsste es mit deutschen amtlichen Quellen belegen.

Artikel 50 ist genauer als das Schlagwort „KI-Kennzeichnung“

Artikel 50 verteilt unterschiedliche Pflichten auf Anbieter und Betreiber.

Anbieter direkt interagierender KI-Systeme müssen Menschen grundsätzlich darüber informieren, dass sie mit KI sprechen, sofern dies nicht ohnehin offensichtlich ist. Anbieter generativer Systeme müssen synthetische Audio-, Bild-, Video- und Textausgaben maschinenlesbar als künstlich erzeugt oder manipuliert erkennbar machen. Die technische Lösung soll wirksam, interoperabel, robust und zuverlässig sein – soweit dies technisch machbar ist.

Betreiber müssen bei Deepfakes offenlegen, dass Bild, Ton oder Video künstlich erzeugt oder verändert wurden. Für Texte, die die Öffentlichkeit über Angelegenheiten öffentlichen Interesses informieren sollen, gilt ebenfalls eine Offenlegungspflicht, wenn sie künstlich erzeugt oder manipuliert wurden.

Doch die Verordnung unterscheidet zwischen automatischer Publikation und verantworteter Redaktion: Hat ein Text einen menschlichen Prüf- oder Redaktionsprozess durchlaufen und übernimmt eine Person oder Organisation die redaktionelle Verantwortung, greift diese besondere Offenlegungspflicht nicht automatisch.

Ein Blogentwurf, den ein Sprachmodell strukturiert und den eine Redaktion anschließend vollständig anhand der Primärquellen prüft, umschreibt und verantwortet, ist damit nicht dasselbe wie ein Bot, der politische Meldungen ohne menschliche Prüfung veröffentlicht. Das ist keine Einladung, Werkzeuge zu verschleiern. Es ist eine notwendige Unterscheidung zwischen technischer Hilfe und ausgelagerter Verantwortung.

Für bestimmte Generatoren, die schon vor dem 2. August 2026 angeboten wurden, kann außerdem eine Übergangsfrist bis zum 2. Dezember 2026 relevant sein. Ein fehlender Marker am 3. August beweist deshalb nicht ohne Einzelfallprüfung einen Rechtsverstoß.

Das Wasserzeichen löst das Wahrheitsproblem nicht

Maschinenlesbare Markierungen können Herkunftsinformationen transportieren. Sie können anzeigen, dass ein System an einer Datei beteiligt war. Sie beweisen aber nicht, dass der Inhalt falsch ist. Sie beweisen auch nicht automatisch, wer ihn erstellt, verändert oder veröffentlicht hat.

In der Praxis werden Bilder komprimiert, Videos transkodiert, Audiodateien neu kodiert und Inhalte als Screenshot weitergereicht. Dabei können Metadaten oder andere Marker verloren gehen. Umgekehrt kann ein sichtbares Label den falschen Eindruck erzeugen, die gesamte Herkunftskette sei damit geprüft.

Die EU hat ergänzend einen freiwilligen Transparenzkodex geschaffen. Unterzeichner können dessen Maßnahmen als anerkannten Nachweisweg verwenden. Wer nicht unterzeichnet, handelt nicht automatisch rechtswidrig, sondern muss gleichwertige eigene Maßnahmen belegen. Ende Juli 2026 hatten sich laut Kommission rund 190 Organisationen angeschlossen. Diese Zahl ist veränderlich und muss vor einer Veröffentlichung erneut geprüft werden.

Redaktionelle Bewertung – von Andreas vor Veröffentlichung zu prüfen: Transparenz wird erst dann zu digitaler Souveränität, wenn die Prüfwerkzeuge offen und unabhängig nutzbar sind. Wenn nur große Plattformen maschinenlesbare Nachweise ausstellen und lesen können, entsteht ein neuer Lock-in. Dann gehört nicht nur das Modell einigen Konzernen, sondern auch die technische Definition von Glaubwürdigkeit.

Eine souveräne Infrastruktur braucht offene Spezifikationen, freie Prüfsoftware, mehrere unabhängige Validierer und die Möglichkeit, Nachweise selbst zu hosten. Ein proprietärer KI-Detektor darf nicht zum Wahrheitsministerium werden.

Der eigentliche politische Konflikt: Hochrisiko kommt später

Der AI Omnibus trat nach Angaben der EU-Kommission am 27. Juli 2026 in Kraft. Er verschiebt die Anwendung der Hochrisiko-Regeln für Systeme aus Anhang III auf den 2. Dezember 2027. Dazu gehören unter anderem Bereiche wie Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, Migration und Justiz. Für KI als Bestandteil regulierter Produkte nach Anhang I ist nun der 2. August 2028 vorgesehen.

Die Kommission begründet die längeren Fristen mit fehlenden Standards, Unterstützungsinstrumenten und dem Bedarf an Rechtssicherheit. Das ist ein ernst zu nehmendes Argument. Uneinheitliche Prüfverfahren können gerade kleine Anbieter überfordern, während Konzerne ganze Rechts- und Compliance-Abteilungen finanzieren.

Aber daraus folgt nicht zwingend, dass breite Verschiebungen die einzige Lösung waren. Denkbar wären stufenweise Mindestpflichten, öffentliche Audit-Angebote, klare Beschaffungsregeln und gezielte Unterstützung kleiner und freier Projekte.

Gesichert ist die Verschiebung. Nicht gesichert ist, wie viele konkrete Systeme dadurch länger ohne eine bestimmte AI-Act-Pflicht betrieben werden. Dafür fehlen belastbare öffentliche Bestandszahlen und Einzelfallklassifikationen. Der Satz „Die EU hat Hochrisiko-KI freigegeben“ wäre daher ebenso falsch wie die Behauptung, ab 2. August sei die gesamte Regulierung fertig.

Redaktionelle Bewertung – von Andreas vor Veröffentlichung zu prüfen: Die zeitliche Asymmetrie ist politisch gefährlich. Labels sind sichtbar und leicht zu kommunizieren. Die Kontrolle von Systemen, die über Bildung, Arbeit, Migration oder Justiz mitentscheiden können, ist komplizierter – und wurde vertagt. Transparenz darf nicht als Ersatz für Grundrechtsschutz verkauft werden.

Open Source ist nicht pauschal ausgenommen

Auch bei Open Source lohnt der Blick in den Wortlaut. Artikel 2 Absatz 12 privilegiert Systeme unter freien und offenen Lizenzen grundsätzlich. Im selben Satz stehen jedoch klare Rückausnahmen: verbotene Praktiken, Hochrisiko-Systeme und Systeme, die unter Artikel 50 fallen.

Ein frei lizenzierter Chatbot oder Bildgenerator ist also nicht allein wegen seiner Lizenz von den Transparenzpflichten befreit. Wer ein Modell privat auf dem eigenen Rechner nutzt, befindet sich außerdem in einer anderen Lage als jemand, der einen öffentlichen Dienst betreibt oder Ausgaben automatisiert publiziert. „Selfhosting“ allein beantwortet die rechtliche Rollenfrage nicht.

Für Anbieter von General-Purpose-AI-Modellen enthält Artikel 53 eine engere Erleichterung. Wenn die Lizenz Zugriff, Nutzung, Veränderung und Weitergabe erlaubt und Parameter einschließlich Gewichten, Architektur- und Nutzungsinformationen öffentlich sind, können zwei Dokumentationspflichten entfallen. Die Urheberrechtsrichtlinie und eine öffentliche, hinreichend detaillierte Zusammenfassung der Trainingsinhalte bleiben jedoch Pflicht. Für Modelle mit systemischem Risiko greift die Ausnahme nicht.

Deshalb sind „Open Weights“ und „Open Source“ nicht dasselbe. Ein Download von Gewichten ohne ausreichende Nutzungsrechte und technische Informationen ist kein vollständiger Offenheitsnachweis.

Redaktionelle Bewertung – von Andreas vor Veröffentlichung zu prüfen: Open Source darf weder als Schlupfloch noch als Kollateralschaden behandelt werden. Offene Systeme ermöglichen unabhängige Prüfung, Anpassung und gemeinschaftlichen Betrieb. Offenheit macht riskante Anwendungen aber nicht harmlos. Die richtige Linie ist risikobasierte Verantwortung plus offene öffentliche Compliance-Infrastruktur – kein Freibrief, aber auch keine proprietäre Mautstelle.

Was Betreiber und Communities jetzt praktisch tun können

Für einen kleinen Server- oder Community-Betrieb sind fünf Schritte sinnvoll:

  1. Dokumentieren, wo KI-Systeme tatsächlich eingesetzt werden.
  2. Private Nutzung, internen Betrieb, öffentliches Angebot und automatische Veröffentlichung auseinanderhalten.
  3. Bot-Konten klar benennen, Tokens minimal berechtigen, regelmäßig rotieren und einer verantwortlichen Person zuordnen.
  4. Originaldateien, Quellen, Hashwerte und Prüfprotokolle in getesteten Backups erhalten.
  5. Vor jeder Veröffentlichung zu öffentlichen Themen einen echten menschlichen Freigabeschritt setzen.

Ein Beispiel: Taucht in einem Matrix-Raum ein angebliches Beweisvideo auf, reicht die Meldung eines proprietären Online-Detektors nicht. Belastbarer sind Originaldatei, dokumentierte Quelle, Hashwert, Metadatenprüfung und menschliche Kontextanalyse. Das Werkzeug liefert einen Hinweis. Die Redaktion trägt das Urteil.

Ein zweites Beispiel: Ein lokaler Textgenerator läuft hinter Nginx und wird von einem Synapse-Bot angesprochen. Entscheidend sind nicht die Schlagworte „lokal“ und „Open Source“, sondern Zugänglichkeit, Lizenz, Rolle, Kennzeichnung, Token-Rechte, Protokollierung und ein klarer Abschaltweg.

Fazit

Der 2. August 2026 ist ein wichtiger Stichtag, aber kein Schlusspunkt. Der AI Act macht Transparenz und Durchsetzung konkreter. Das ist gut. Gleichzeitig wurden zentrale Hochrisiko-Pflichten verschoben. Das ist die Lücke, über die politisch gesprochen werden muss.

Ein Label kann zeigen, dass eine Maschine beteiligt war. Es kann nicht erklären, wem das System dient, wie eine Entscheidung angefochten wird oder wer den Schaden trägt. Dafür braucht Europa offene technische Standards, unabhängige Prüfung, klare Zuständigkeiten und durchsetzbaren Grundrechtsschutz.

Transparenz und Kontrolle sind keine Gegensätze. Wir brauchen beides.

Quellen

  1. Europäische Kommission, AI Act – Überblick und Zeitplan: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
  2. Europäische Kommission, „AI Omnibus enters into force“, 27. Juli 2026: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
  3. EUR-Lex, Verordnung (EU) 2026/1744: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744
  4. AI Act Service Desk, Umsetzungszeitleiste: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
  5. AI Act Service Desk, Artikel 50: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
  6. Europäische Kommission, Leitlinien zu Artikel 50: https://digital-strategy.ec.europa.eu/en/policies/guidelines-transparency-ai-generated-content
  7. Europäische Kommission, Transparenzkodex: https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
  8. Europäische Kommission, Durchsetzungsrahmen: https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
  9. AI Act Service Desk, Artikel 2: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-2
  10. AI Act Service Desk, Artikel 53: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-53

Transparenz- und Prüfstatus

Dieser Entwurf wurde mit Crow/Codex auf Grundlage der lokalen Recherche vom 1. August 2026 und der dort dokumentierten EU-Primärquellen erstellt. Es wurden keine eigenen Praxistests behauptet. Tatsachen und vorgeschlagene redaktionelle Bewertungen sind getrennt. Fristen, Unterzeichnerstand, amtlicher Wortlaut und deutsche Zuständigkeiten müssen vor Veröffentlichung erneut geprüft werden. Die persönliche Position und Veröffentlichung verantwortet Andreas erst nach ausdrücklicher Freigabe.

CTA

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/
Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Freigabe erforderlich: ja. Veröffentlichung erfolgt: nein.