„Datensouveränität” klingt nach einem abstrakten Policy-Begriff. In der Praxis bedeutet es: Wer hat Zugriff auf deine Daten, und unter welchen Gesetzen?
Für Entwickler ist das besonders relevant, weil die Tools, die wir täglich nutzen – von KI-Assistenten bis zu CI/CD-Plattformen – kontinuierlich Code und Konfigurationsdaten verarbeiten. Dieser Guide erklärt die wichtigsten Konzepte und gibt konkrete Handlungsempfehlungen.
Was Datensouveränität wirklich bedeutet
Datensouveränität ist das Prinzip, dass Daten den Gesetzen des Landes unterliegen, in dem sie erhoben oder verarbeitet werden. Für europäische Daten bedeutet das: Europäisches Recht gilt, und keine ausländische Regierung kann Zugang erzwingen, ohne die etablierten rechtlichen Rahmenbedingungen einzuhalten.
Die DSGVO-Konformität allein gibt dir keine Datensouveränität (praktische Checkliste: DSGVO-Checkliste für Startups). Du kannst vollständig DSGVO-konform sein, während deine Daten auf Servern liegen, die von einem US-Konzern kontrolliert werden, US-Geheimdienstgesetzen unterliegen und für US-Behörden ohne dein Wissen zugänglich sind.
Datensouveränität hat zwei Dimensionen:
Technische Souveränität: Wo liegen die Daten physisch? Auf welchen Servern werden sie verarbeitet? Wer hat technisch Zugriff?
Rechtliche Souveränität: Unter welchem Recht werden die Daten verarbeitet? Welche Behörden können unter welchen Bedingungen Zugriff verlangen? Welcher Gerichtsbarkeit unterliegt der Betreiber?
Beide Dimensionen sind wichtig. Es reicht nicht, wenn deine Daten auf EU-Servern liegen, wenn der Betreiber ein US-Unternehmen ist.
Das rechtliche Rahmenwerk: FISA 702 und CLOUD Act
Zwei US-Gesetze schaffen strukturelle Probleme für europäische Datensouveränität, selbst wenn Daten in EU-Rechenzentren gespeichert werden.
FISA Section 702
Der Foreign Intelligence Surveillance Act (FISA) Section 702 erlaubt US-Geheimdiensten, US-Unternehmen zu verpflichten, Daten über Nicht-US-Personen herauszugeben. Die Ziele müssen nicht unter Verdacht stehen – es reicht, dass sie „ausländische Geheimdienstinformationen” besitzen könnten.
Was das konkret heißt: Wenn ein US-Cloud-Anbieter deinen Code hostet, können US-Behörden diesen Code theoretisch anfordern, ohne dass du davon erfährst. Das gilt auch dann, wenn der Server physisch in Frankfurt steht.
FISA Section 702 wurde im April 2024 verlängert und läuft bis April 2026.
Der CLOUD Act
Der Clarifying Lawful Overseas Use of Data (CLOUD) Act von 2018 geht noch weiter. Er stellt klar, dass US-Unternehmen Daten herausgeben müssen, die sie „besitzen, verwahren oder kontrollieren” – unabhängig davon, wo diese Daten physisch gespeichert sind.
Der CLOUD Act hat keine Sunset-Klausel. Er gilt unbefristet.
Die Kombination: Ein US-Unternehmen mit einem Rechenzentrum in Deutschland unterliegt trotzdem US-Recht. Es kann vertraglich zusagen, deine Daten nicht weiterzugeben – aber es kann nicht garantieren, dass es einer gerichtlichen Anordnung unter CLOUD Act oder FISA widersetzt.
Das Schrems-II-Problem
Das EuGH-Urteil von 2020 (Schrems II) hat Privacy Shield gekippt und klargestellt: Datenübertragungen in die USA sind nur noch unter strengen Bedingungen legal.
Die aktuell gültige Rechtsgrundlage sind Standard Contractual Clauses (SCCs) und das EU-US Data Privacy Framework (DPF) von Juli 2023.
Aber beide Mechanismen haben eine bekannte Schwachstelle: Sie können nur vertragliche Verpflichtungen des Unternehmens regeln – nicht die gesetzlichen Zugriffsrechte von US-Behörden.
Das Data Privacy Framework hat seine erste rechtliche Anfechtung im September 2025 überstanden. Allerdings hat NOYB eine umfassendere Klage vor dem EuGH angekündigt. Wenn das DPF für ungültig erklärt wird – wie seine Vorgänger Safe Harbor und Privacy Shield – stehen Unternehmen, die sich darauf verlassen, vor plötzlichen Compliance-Problemen.
Warum Datensouveränität für Entwickler wichtig ist
Die EU baut seit Jahren ein strategisches Rahmenwerk für digitale Souveränität auf. Das spiegelt die Erkenntnis wider, dass Abhängigkeit von nicht-europäischer Technologie-Infrastruktur wirtschaftliche und politische Risiken schafft.
Hier ist ein Perspektivwechsel, der sich zu verinnerlichen lohnt: Datensouveränität ist nicht nur ein Compliance-Kostenfaktor. Sie wird zunehmend zum Wettbewerbsvorteil.
Beschaffungsanforderungen: Öffentliche Aufträge in EU-Mitgliedstaaten verlangen zunehmend EU-Datensouveränität als hartes Kriterium. Enterprise-Beschaffungsfragebögen fragen nach Cloud-Jurisdiktion, Subunternehmer-Standorten und Exposition gegenüber ausländischen Geheimdienstgesetzen.
Kundenvertrauen: Für B2B-Unternehmen ist „Ihre Daten verlassen niemals die EU und unterliegen niemals US-Zugriffsgesetzen” ein echter Differenzierungsfaktor – besonders in Deutschland, wo Datenschutzbewusstsein hoch ist.
Investoren-Due-Diligence: VC-Firmen und strategische Investoren prüfen zunehmend die Infrastruktur-Abhängigkeiten ihrer Portfoliounternehmen. US-Cloud-Risiken tauchen in Due-Diligence-Berichten auf.
Welche Tools haben ein Souveränitätsproblem?
Cloud-Infrastruktur
AWS, Azure und Google Cloud sind US-Unternehmen. Europäische Regionen dieser Anbieter sind physisch in der EU, aber rechtlich unter US-Recht. Unter dem CLOUD Act können US-Behörden AWS zwingen, Daten herauszugeben, die es kontrolliert – unabhängig vom Standort.
Alternativen mit echter EU-Souveränität: Hetzner (Deutschland), OVH (Frankreich), IONOS (Deutschland), Scaleway (Frankreich), Exoscale (Schweiz).
KI-Coding-Tools
GitHub Copilot (Microsoft/USA), Cursor (USA), Claude Code (Anthropic/USA) – alle US-basiert. Standardmäßig wird Code auf US-Servern verarbeitet.
GitHub Copilot bietet EU-Datenresidenz, aber nur im Enterprise-Tarif und nur als Konfigurationsoption.
Alternative: Lurus Code (Deutschland) – einziges Mainstream-KI-Coding-Tool mit EU-only-Processing auf allen Tarifen und AVV nach deutschem Recht.
Versionskontrolle
GitHub ist seit 2018 ein Microsoft-Tochterunternehmen und unterliegt US-Recht.
Alternative: GitLab bietet eine EU-Hosting-Option. Gitea und Forgejo können selbst gehostet werden.
CI/CD
GitHub Actions läuft auf US-Infrastruktur.
Alternativen: GitLab CI mit EU-Hosting, Woodpecker CI auf eigener Infrastruktur, Jenkins selbst gehostet.
Risikobewertung nach Use Case
Nicht jeder Use Case hat dasselbe Risikoprofil. Eine ehrliche Bewertung hilft, Ressourcen richtig zu allokieren.
Geringes Risiko:
- Open-Source-Code, der ohnehin öffentlich ist
- Prototypen und experimentelle Projekte ohne Kundendaten
- Interne Tools ohne personenbezogene Daten
- Nicht-sensible Konfigurationen
Mittleres Risiko:
- SaaS-Produkte mit Nutzerdaten
- Interne Tools mit Mitarbeiterdaten
- Code mit eingebetteten Konfigurationen
- Produktions-Deployment-Pipelines
Hohes Risiko (strenge EU-Anforderungen):
- Fintech-Anwendungen (DORA-reguliert)
- Medizinische Software (MDR/DSGVO-Gesundheitsdaten)
- Öffentliche Verwaltung und Behördensoftware
- Anwendungen mit besonders sensiblen Daten (Art. 9 DSGVO)
- Code mit Zugang zu kritischer Infrastruktur
- Verteidigungsbezogene Projekte
Der praktische Weg zu EU-Datensouveränität
Wenn du dich in Richtung EU-Datensouveränität in deinem Entwicklungs-Workflow bewegen willst, hier ist ein konkreter Pfad:
Schritt 1: Tool-Audit durchführen
Liste alle Tools im Entwicklungs-Workflow auf. Für jedes Tool frage:
- Wo ist das Unternehmen ansässig?
- Wo werden Daten verarbeitet?
- Gibt es einen AVV?
- Wer sind die Subunternehmer?
Schritt 2: Datenkategorien bestimmen
Welche Daten gehen wohin? Quellcode, Commit-Messages, Issue-Beschreibungen, CI/CD-Logs, Entwickler-Prompts an KI-Tools – jede Kategorie hat ihr eigenes Risikoprofil.
Erstelle eine Matrix: Tool × Datenkategorie × Sensitivität.
Schritt 3: Sensitivsten Use Case zuerst migrieren
Du musst nicht alles auf einmal ändern. Beginne mit dem Use Case, der am kritischsten ist:
- Wenn du Kundendaten verarbeitest: KI-Coding-Tool auf EU-Anbieter wechseln
- Wenn du für den öffentlichen Sektor arbeitest: Hosting auf EU-Anbieter migrieren
- Wenn du in einer regulierten Branche bist: Vollständige Toolchain evaluieren
Schritt 4: Vertragliche Absicherung
Für alle verbleibenden US-Anbieter:
- AVV abschließen (verpflichtend!)
- SCCs prüfen
- Subprozessorlisten analysieren
- Transfer Impact Assessment dokumentieren
Schritt 5: Entscheidungen dokumentieren
Füge Jurisdiktion und Datensouveränität in deine Architecture Decision Records (ADRs) ein. Das schützt dich bei Audits und hilft neuen Teammitgliedern zu verstehen, warum bestimmte Tools gewählt wurden.
Häufig gestellte Fragen
Reicht es, AWS Frankfurt zu nutzen?
Nein. AWS Frankfurt bedeutet, dass deine Daten physisch in Deutschland gespeichert werden, aber sie werden von Amazon Web Services, Inc. kontrolliert – einem US-Unternehmen. Unter dem CLOUD Act können US-Behörden AWS zur Herausgabe von Daten zwingen, unabhängig vom Standort. Unter FISA Section 702 können US-Geheimdienste auf Daten zugreifen, die US-Unternehmen über Nicht-US-Personen halten.
Der geografische Standort des Servers ändert nicht die Unternehmens-Jurisdiktion. Für echte EU-Datensouveränität brauchst du einen Anbieter, der in der EU gegründet wurde und keine US-Muttergesellschaft hat.
Löst das EU-US Data Privacy Framework das Souveränitätsproblem?
Teilweise und temporär. Das Data Privacy Framework, im Juli 2023 verabschiedet, bietet eine Rechtsgrundlage für die Übertragung personenbezogener Daten an zertifizierte US-Unternehmen. Es ändert aber nichts an den zugrundeliegenden US-Gesetzen (FISA 702, CLOUD Act), die den Souveränitätskonflikt schaffen.
Wenn das DPF für ungültig erklärt wird, wie es mit seinen Vorgängern passiert ist, stehen Organisationen, die sich darauf verlassen, vor plötzlichen Disruptions.
Ist EU-Datensouveränität nur für große Unternehmen relevant?
Nein. Die Vorstellung, dass nur Großunternehmen sich um Jurisdiktionsfragen kümmern müssen, ist überholt. Startups, die Enterprise-Kunden anvisieren, werden bei der Beschaffung nach Datenresidenz gefragt. Regulierte Branchen haben Anforderungen unabhängig von der Unternehmensgröße. Und für Venture-finanzierte Unternehmen ist Infrastruktur-Risiko zunehmend Teil der Due Diligence.
Lurus Code als Teil einer EU-souveränen Toolchain
Lurus Code wurde mit diesem Verständnis entwickelt. Als deutsches Unternehmen, das auf EU-Infrastruktur läuft, ohne US-Mutterkonzern und ohne US-Subunternehmer für Code-Daten, bietet es KI-Coding-Unterstützung mit voller EU-Datensouveränität.
- Deutsches Unternehmen, kein US-Mutterkonzern, kein FISA-702-Risiko
- EU-only-Processing
- Zero-Retention: Quellcode wird nach Verarbeitung sofort gelöscht
- AVV nach Art. 28 DSGVO für alle Tarife (nicht nur Enterprise)
- Keine Model-Training-Nutzung von Kundendaten
- Transparente Subprozessorliste
Der AVV ist mit einer deutschen Gesellschaft unter deutschem und EU-Recht.
Lurus Code fügt sich in eine vollständig EU-souveräne Toolchain ein: GitLab oder Gitea auf EU-Infrastruktur, CI/CD auf EU-Infrastruktur, Lurus Code als KI-Assistent – alles unter EU-Recht, ohne US-Jurisdiktions-Risiko.
Fazit
Datensouveränität ist kein Trend oder Buzzword. Sie ist ein strukturelles Merkmal davon, wie du Software baust und deployst. FISA 702 wurde gerade verlängert. Der CLOUD Act hat keine Sunset-Klausel. Und das EU-Engagement für digitale Souveränität vertieft sich.
Für europäische Entwickler ist der praktische Weg vorwärts klar: Wähle Infrastruktur, die von EU-Entitäten kontrolliert wird, wenn du kannst. Nutze KI-Tools, die deinen Code innerhalb der EU-Jurisdiktion verarbeiten. Dokumentiere deine Entscheidungen. Und behandle Souveränität nicht als Einschränkung, sondern als Feature, für das deine Kunden, dein Legal-Team und dein zukünftiges Ich dir danken werden.
Die gute Nachricht: 2025 gibt es für nahezu jeden Teil des Entwicklungs-Workflows EU-souveräne Alternativen, die technisch auf Augenhöhe sind. Die Entscheidung für EU-Hosting ist keine Einschränkung – sie ist eine bewusste Wahl für rechtliche Sicherheit und Vertrauenswürdigkeit. echtliche Sicherheit und Vertrauenswürdigkeit.