EU-Souveränität im KI-Tech-Stack: Ein ehrlicher Leitfaden für Entscheider

TL;DR

Ihre Daten liegen in Frankfurt. Trotzdem hat eine US-Behörde Zugriff. Der CLOUD Act richtet sich nach der Unternehmenszugehörigkeit, nicht nach dem Standort des Rechenzentrums. Wer im DACH-Raum KI-Systeme baut oder einkauft, steht vor einer echten Entscheidung: Wie viel Souveränität braucht Ihr Projekt tatsächlich, und was kostet sie? Dieser Artikel gibt Ihnen eine ehrliche Entscheidungshilfe mit konkreten Kosten, realistischen Szenarien und den fünf häufigsten Irrtümern.

1. Das CLOUD-Act-Missverständnis

Die Annahme ist weit verbreitet: Wenn die Daten physisch in der EU liegen, sind sie vor US-Behörden geschützt. Das stimmt nicht.

Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act, USA 2018) verpflichtet US-Unternehmen, auf Anfrage der US-Regierung Zugriff auf Daten zu gewähren, unabhängig davon, wo diese Daten physisch gespeichert sind. Die entscheidende Frage ist nicht: "Wo liegt das Rechenzentrum?" Die entscheidende Frage ist: "Welchem Unternehmen gehört der Dienst?"

Ein Beispiel: Supabase betreibt eine Region in Frankfurt. Supabase Inc. ist ein US-Unternehmen mit Sitz in San Francisco. Die Daten in Frankfurt unterliegen damit potenziell dem CLOUD Act, auch wenn sie physisch nie die EU verlassen.

Das gilt für die meisten bekannten Cloud-Dienste: AWS, Google Cloud, Microsoft Azure, Vercel, Supabase Cloud, Resend, Stripe. Alle US-Firmen. Alle CLOUD-Act-exponiert.

Was Standard Contractual Clauses (SCCs) leisten

SCCs sind vertragliche Zusicherungen, die zwischen EU-Kunden und US-Anbietern vereinbart werden. Sie sind ein anerkanntes Instrument unter der DSGVO und bieten einen Rahmen für den rechtmäßigen Datentransfer. Was sie nicht leisten: Sie heben den CLOUD Act nicht auf. Bei einem konkreten Zugriff durch US-Behörden setzt sich US-Recht über vertragliche Vereinbarungen hinweg.

SCCs reduzieren das regulatorische Risiko. Sie eliminieren es nicht. Für viele Projekte ist das akzeptabel. Für einige nicht. Genau das gilt es zu klären.

Was das für Ihre Entscheidung bedeutet

Für Projekte ohne besondere Datenschutzanforderungen ist der pragmatische Umgang mit US-Cloud-Diensten vertretbar und wirtschaftlich sinnvoll. Für Projekte mit sensiblen Daten (Patientendaten, Finanzdaten, behördliche Daten) oder für Unternehmen, die Souveränität als Produktmerkmal positionieren, reicht das nicht.

Der Rest dieses Artikels hilft Ihnen einzuordnen, in welche Kategorie Ihr Projekt fällt, und was die einzelnen Optionen realistisch kosten.

2. Die vier Souveränitätsstufen

Nicht jeder Stack braucht die gleiche Souveränität. Eine sinnvolle Einordnung in vier Stufen hilft bei der Orientierung.

| Stufe | Name | Definition | Typische Beispiele | |-------|------|-----------|-------------------| | 0 | US-Native | US-Firma, US-Region | AWS us-east-1, GPT-4 API | | 1 | US-Firma, EU-Region | US-Firma, EU-Rechenzentrum | Supabase Frankfurt, Vercel, Resend | | 2 | EU-Firma, Cloud | EU-Firma, Managed Service | Hetzner, Scaleway, Pirsch Analytics | | 3 | Self-Hosted | Eigene Infrastruktur, eigene Server | Supabase self-host, GlitchTip, Garage |

Stufe 0 ist der Standard-Entwicklerpfad. Schnell, günstig, gut dokumentiert. DSGVO-Compliance erfordert SCCs und Auftragsverarbeitungsverträge.

Stufe 1 ist der häufigste Kompromiss in der DACH-Region. EU-Rechenzentrum gibt ein gutes Gefühl, löst das CLOUD-Act-Problem aber nicht. Für viele Projekte trotzdem ausreichend.

Stufe 2 schließt die CLOUD-Act-Lücke. Hetzner ist ein deutsches Unternehmen, Scaleway ein französisches. US-Behörden haben keinen direkten Hebel. Der Preis: weniger Managed Services, mehr Eigenarbeit.

Stufe 3 bietet maximale Kontrolle. Sie betreiben die Infrastruktur selbst. Kein Drittanbieter hat Zugriff auf Ihre Daten. Der Preis: erheblicher Ops-Aufwand und volle Verantwortung für Updates, Backups, Sicherheit.

Wichtig: Kein reales Projekt läuft auf einer einzigen Stufe. Die meisten sinnvollen Setups sind Mischungen: kritische Daten auf Stufe 2 oder 3, unkritische Dienste auf Stufe 1.

3. Die harten Fragen zur Selbsteinschätzung

Bevor ich mit einem Kunden über konkrete Stack-Entscheidungen spreche, stelle ich fünf Fragen. Die Antworten bestimmen, welche Souveränitätsstufe tatsächlich nötig ist.

Frage 1: Ist Datensouveränität das Produkt oder ein Kostentreiber? Wenn Ihr Produkt mit dem Argument verkauft wird "Ihre Daten bleiben in der EU unter EU-Recht", dann ist Souveränität ein differenzierendes Merkmal und muss technisch eingehalten werden. Wenn Souveränität nur ein internes Compliance-Thema ist, gelten andere Maßstäbe.

Frage 2: Haben Sie mindestens vier Stunden pro Monat Ops-Kapazität? Self-Hosting bedeutet: Updates einspielen, Backups prüfen, Sicherheitspatches anwenden, Dienste monitoren. Vier Stunden pro Monat ist die Mindestangabe für eine einfache Self-Hosted-Instanz. Realistischer sind acht bis fünfzehn Stunden, sobald mehrere Dienste betroffen sind. Wer diese Kapazität nicht hat oder nicht aufbauen will, sollte Self-Hosting nicht als Option betrachten.

Frage 3: Haben Ihre Kunden Data-Residency-Klauseln in Ihren Verträgen? Bestimmte Branchen (Finanzdienstleistungen, Gesundheitswesen, öffentlicher Sektor) verlangen vertraglich, dass Daten in definierten Regionen oder unter definiertem Recht verbleiben. Wenn Ihre Kunden solche Klauseln einfordern, ist das kein optionales Differenzierungsmerkmal, sondern eine Mindestanforderung.

Frage 4: Verarbeiten Sie Daten, die unter spezifische Regulierung fallen? Gesundheitsdaten (HIPAA-Äquivalente in AT/DE), Finanztransaktionsdaten, Daten von minderjährigen Personen, behördliche Daten. Diese Kategorien erhöhen den erforderlichen Souveränitätsgrad unabhängig von Produktstrategie und Kundenwünschen.

Frage 5: Können Sie einen Datenzugriff durch US-Behörden gegenüber Kunden rechtfertigen? Diese Frage klingt abstrakt, ist aber praktisch relevant. Wenn der Antwort "Wir verwenden US-Dienste mit EU-SCCs" ein Kunde mit "Das akzeptieren wir nicht" entgegnet: haben Sie dann eine Alternative?

Wer alle fünf Fragen mit Nein beantwortet, kann auf Stufe 1 verbleiben und spart erheblich. Wer zwei oder mehr Fragen mit Ja beantwortet, sollte Stufe 2 oder 3 ernsthaft prüfen.

4. Die wichtigsten Stack-Komponenten im Überblick

Praktisch jeder KI-Stack besteht aus den gleichen Schichten. Hier sind die relevantesten Komponenten mit Optionen nach Souveränitätsstufe.

| Komponente | Stufe 1 (US, EU-Region) | Stufe 2 (EU-Firma) | Stufe 3 (Self-Hosted) | |------------|------------------------|-------------------|----------------------| | Compute | Vercel, Render | Hetzner Cloud, Scaleway | Eigener Server (Hetzner Dedicated) | | Datenbank | Supabase Frankfurt | Hetzner Managed DB | Supabase self-host, Postgres (Docker) | | Auth | Supabase Auth | ZITADEL Cloud (CH) | Supabase self-host, Ory Kratos | | Storage | Supabase Storage | Hetzner Object Storage | Garage (S3-kompatibel) | | LLM (App-Features) | OpenAI, Gemini | Mistral (FR) | Ollama (Llama 3.3, Mistral) | | LLM (Coding) | Claude, GPT-4 | -- | -- | | Analytics | Vercel Analytics | Pirsch (DE), Plausible | Plausible self-host | | Error Tracking | Sentry Cloud | -- | GlitchTip self-host | | E-Mail | Resend, Postmark | Brevo (FR) | Postal (hoher Aufwand) | | Zahlungen | Stripe | -- | -- |

Die harten Einschränkungen

Zwei Bereiche lassen sich nicht vollständig souverän lösen, ohne erhebliche Qualitätseinbußen:

Coding-Assistent. Claude (Anthropic, US) und GPT-4 (OpenAI, US) haben für Coding-Aufgaben keinen vergleichbaren EU-Konkurrenten. Mistral und lokale Modelle sind für App-Features sinnvoll einsetzbar, für komplexe Architektur- und Coding-Entscheidungen im Maschinenraum aber deutlich schwächer. Wer als Entwickler oder Entwicklungsteam auf KI-Assistance angewiesen ist, hat hier eine faktische Abhängigkeit von US-Diensten. Das gilt zumindest bis Ende 2026.

Zahlungsabwicklung. Stripe hat keinen EU-Konkurrenten mit vergleichbarem Feature-Set, Reliability und Entwickler-Erfahrung. Braintree (PayPal, US), Adyen (NL, börsennotiert, internationale Struktur): alle haben Einschränkungen. Für die meisten Projekte ist Stripe die pragmatische Wahl, unabhängig von Souveränitätsambitionen.

Diese Einschränkungen bedeuten nicht, dass ein souveräner Stack unmöglich ist. Sie bedeuten, dass man realistisch damit umgeht: Coding-Assistance und Payments laufen über US-Dienste, alle anderen kritischen Komponenten über EU-Infrastruktur.

5. Drei Referenzszenarien

Abstrakte Architekturprinzipien helfen wenig ohne konkrete Kostenrahmen. Die folgenden drei Szenarien beschreiben reale Muster, die ich in Projekten beobachte.

Szenario A: Souveränität als Produktmerkmal

Wer das wählt: SaaS-Produkte, die an Behörden, Krankenhäuser, Finanzinstitute oder öffentliche Auftraggeber in der DACH-Region verkaufen. Souveränität ist kein optionales Merkmal, sondern Kaufvoraussetzung.

Stack-Profil: Hetzner Cloud Compute, Hetzner Managed PostgreSQL, Supabase self-host oder Neon, Pirsch Analytics, Brevo für E-Mail, Mistral für LLM-App-Features. Compute und Daten vollständig bei EU-Firmen.

Monatliche Infrastrukturkosten: 80-180 Euro, abhängig von Traffic und Datenvolumen.

Ops-Aufwand: 8-15 Stunden pro Monat. Updates, Backups, Monitoring, gelegentliche Konfigurationsanpassungen.

Trade-offs:

• Vorteil: Klare Differenzierung im Vertrieb, keine CLOUD-Act-Exposition für Kundendaten.
• Nachteil: Weniger Managed-Service-Komfort als US-Anbieter, etwas mehr Eigenarbeit beim Setup. LLM-Qualität für komplexe Reasoning-Aufgaben unter US-Niveau.

Wann es sich rechnet: Ab dem ersten Kunden, der "EU-only" als Bedingung formuliert.

Szenario B: Maximale Kontrolle

Wer das wählt: Projekte mit höchsten Datenschutzanforderungen: Gesundheitsdaten, behördliche Daten, oder Projekte, bei denen die Abhängigkeit von Drittanbietern strukturell vermieden werden soll. Auch relevant für Unternehmen mit internem Sicherheitsteam, das External-Cloud-Risiken nicht akzeptiert.

Stack-Profil: Hetzner Dedicated Server, Supabase self-host (PostgreSQL + Auth + Storage), Plausible self-host, GlitchTip, Garage für S3-kompatiblen Object Storage, Postal für E-Mail (mit allen Konsequenzen), Ollama für LLM-Inferenz auf eigenem Hardware.

Monatliche Infrastrukturkosten: 250-600 Euro. Der Hauptkostentreiber ist der Dedicated Server, der für Ollama-Inferenz ausreichend GPU-Kapazität braucht.

Ops-Aufwand: 20-30 Stunden pro Monat. Diese Zahl ist nicht verhandelbar. Self-Hosting mehrerer Dienste bedeutet: Security-Patches prüfen und einspielen, Backup-Konsistenz verifizieren, Dienste nach Updates testen, Monitoring-Alerts auswerten. Wer das nicht einkalkuliert, hat ein Sicherheitsproblem, kein Souveränitätsprojekt.

Trade-offs:

• Vorteil: Maximale Datensouveränität, keine externen Abhängigkeiten für Kerndienste, volle Transparenz über alle Datenflüsse.
• Nachteil: Erheblicher Ops-Aufwand, LLM-Qualität deutlich unterhalb der US-Frontier-Modelle, E-Mail-Zustellbarkeit ist ein eigenes Projekt (IP-Warming, DKIM/DMARC, Blacklist-Management).

Wann es sich rechnet: Bei echter regulatorischer Notwendigkeit oder wenn das interne Security-Team External-Cloud kategorisch ablehnt.

Szenario C: Pragmatischer Hybrid

Wer das wählt: Die meisten Projekte, die ich begleite. Kein spezifisches Souveränitätserfordernis, aber Bewusstsein für das Thema. Ziel ist ein gutes Kosten-Risiko-Verhältnis ohne Ops-Overhead.

Stack-Profil: Vercel für Compute (US, EU-Proxy), Supabase Frankfurt für Datenbank und Auth (US-Firma, EU-Region, SCCs vorhanden), OpenAI oder Anthropic für LLM-Features, Resend für E-Mail, Sentry Cloud für Error Tracking. Pirsch oder Plausible statt Google Analytics.

Monatliche Infrastrukturkosten: 60-160 Euro.

Ops-Aufwand: 3-5 Stunden pro Monat, hauptsächlich für Monitoring und Dependency-Updates.

Trade-offs:

• Vorteil: Niedrigster Aufwand, bestes Entwicklererlebnis, schnellste Time-to-Market.
• Nachteil: CLOUD-Act-Exposition für alle US-Dienste, nur durch SCCs abgemildert. Nicht für regulierte Branchen geeignet.

Wann es sich rechnet: Fast immer, wenn keine konkreten Anforderungen das ausschließen. Souveränität aus Prinzip ohne Anforderung ist kein gutes Argument für den 3-5x höheren Ops-Aufwand von Szenario B.

6. Die ehrliche Kostenseite

Die Infrastrukturkosten sind der sichtbare Teil des Preises. Der eigentliche Kostentreiber ist die Ops-Zeit.

Opportunitätskosten der Ops-Arbeit. Wer als Entwickler oder Gründer 20 Stunden pro Monat mit Server-Administration verbringt, verliert diese Stunden für Produktentwicklung, Kundengespräche oder Vertrieb. Bei einem konservativen Stundensatz von 50 Euro entsprechen 20 Stunden 1.000 Euro monatlich. Nicht als direkte Ausgabe, sondern als entgangene Kapazität.

Das bedeutet: Der Break-even für Self-Hosting liegt nicht bei "spart mir 100 Euro Supabase-Kosten pro Monat", sondern bei "spart mir mehr als 1.000 Euro Opportunitätskosten pro Monat". Das ist selten der Fall, außer bei Projekten mit sehr hohem Datenvolumen oder sehr spezifischen Anforderungen.

Wann Self-Hosting sich tatsächlich rechnet:

| Bedingung | Trifft zu? | |-----------|-----------| | Cloud-Kosten liegen über 500 Euro/Monat | Dann ist Self-Hosting wirtschaftlich prüfenswert | | Interne Ops-Kapazität vorhanden (kein Opportunity-Cost-Problem) | Dann ist der Aufwand kein Kostentreiber | | Regulatorische Pflicht (keine Wahl) | Dann ist der ROI irrelevant | | Souveränität ist Kaufvoraussetzung für Kunden | Dann ist Self-Hosting ein Vertriebsargument |

Für die meisten frühen Projekte trifft keine dieser Bedingungen zu. Szenario C ist dann die richtige Wahl, mit dem Bewusstsein, dass man auf Stufe 2 oder 3 migrieren kann, wenn sich die Anforderungen ändern.

Migrations-Pfad einplanen. Ein häufiger Fehler: Man baut auf US-Cloud-Diensten ohne Datenschicht-Abstraktion. Wenn drei Jahre später ein regulierter Kunde kommt und Souveränität fordert, ist eine Migration aufwendig. Der pragmatische Ansatz: Datenbankzugriff von Anfang an über Repository-Pattern abstrahieren. Migration von Supabase Cloud zu Hetzner Managed PostgreSQL dauert dann Tage, nicht Monate. Wie man ein Softwaresystem von Anfang an so strukturiert, dass es produktionsreif skaliert, beschreibe ich in Von 100+ Prototypen zum Produkt.

7. Die fünf häufigsten Irrtümer

Irrtum 1: "EU-Region = CLOUD-Act-Schutz"

Wie in der Einleitung dargelegt: Nein. Die CLOUD-Act-Pflicht hängt an der Firmenzugehörigkeit, nicht am Serverstandort. AWS Frankfurt, Google Europe, Supabase Frankfurt: alle US-Firmen, alle CLOUD-Act-exponiert. Wer echten Schutz will, braucht EU-Firmen (Stufe 2) oder Self-Hosting (Stufe 3).

Irrtum 2: "Self-Hosting spart Geld"

Selten. Managed Services kosten monatlich, haben aber Operations durch hochqualifizierte Teams eingepreist. Self-Hosting spart die Managed-Service-Gebühr und tauscht sie gegen eigene Ops-Zeit. Bei Projekten unter 500 Euro monatlicher Cloud-Rechnung ist Self-Hosting fast nie günstiger, wenn man die eigene Zeit ehrlich einrechnet.

Irrtum 3: "MinIO ist der Standard für Self-Hosted S3-Storage"

MinIO war lange die erste Wahl für S3-kompatiblen Object Storage in Self-Hosted-Setups. Seit Ende 2025 befindet sich MinIO in einem de-facto-Maintenance-Mode. Aktive Entwicklung und Community-Support haben erheblich nachgelassen. Der empfehlenswertere Nachfolger für neue Self-Hosted-Projekte ist Garage: ein in Rust geschriebener, ressourcenschonender S3-kompatibler Object Storage mit aktiver Entwicklungscommunity. Für bestehende MinIO-Installationen gibt es keinen akuten Handlungsbedarf, für neue Setups ist Garage die bessere Wahl.

Irrtum 4: "Claude ist durch Mistral einfach ersetzbar"

Für App-Features wie Dokumentenanalyse, Textgenerierung oder Klassifizierung ist Mistral Large eine gute EU-souveräne Alternative. Die Qualität ist für die meisten Anwendungsfälle ausreichend, und Mistral ist ein französisches Unternehmen.

Für Coding-Assistance ist die Situation eine andere. Ich setze KI-Coding-Agenten produktiv ein und habe mit verschiedenen Modellen gearbeitet. Für komplexe Architekturentscheidungen, Code-Review und mehrstufige Refactoring-Aufgaben haben Mistral und lokale Modelle aktuell einen messbaren Qualitätsunterschied gegenüber Claude und GPT-4. Das ist kein marketinggetriebenes Urteil, sondern eine technische Beobachtung aus 4.000+ Entwicklungs-Sessions. Die Lücke schließt sich, aber sie ist Ende 2026 noch real.

Irrtum 5: "Self-Hosted E-Mail ist praktikabel"

Transaktions-E-Mail (Passwort-Reset, Bestätigungslinks, Rechnungsversand) über eigene Mailserver zu betreiben ist technisch möglich und operativ aufwendig. Die Herausforderung ist nicht die Software, sondern die Reputation.

IP-Warming (neue IP-Adressen müssen schrittweise aufgebaut werden), DKIM/DMARC/SPF-Konfiguration, Blacklist-Monitoring, Bounce-Management: das ist eine eigene Disziplin. Ein einziger Fehler (zu viele E-Mails zu schnell, falscher Header, Domain auf einer Blacklist) führt zu Zustellproblemen, die tagelang dauern können.

Für Projekte mit hohen Souveränitätsanforderungen ist Brevo (Sendinblue, FR) die pragmatische Lösung: französisches Unternehmen, kein CLOUD-Act-Problem, professionelle Transaktions-E-Mail-Infrastruktur. Für absolute maximale Kontrolle ist Postal self-hosted möglich, aber nur mit dem vollen Bewusstsein über den Aufwand.

8. Entscheidungs-Checkliste und nächste Schritte

Bevor Sie eine Stack-Entscheidung treffen, beantworten Sie diese Fragen:

• Souveränität als Produktmerkmal: Verkaufen Sie an regulierte Branchen oder öffentliche Auftraggeber, die EU-only verlangen?
• Ops-Kapazität: Haben Sie intern die Kapazität und Bereitschaft, 8-30 Stunden pro Monat für Server-Administration aufzuwenden?
• Vertragliche Pflichten: Haben bestehende oder erwartete Kunden Data-Residency-Klauseln in Ihren Verträgen?
• Regulierung: Verarbeiten Sie Gesundheitsdaten, Finanzdaten oder Daten, die unter spezifische Sektorregulierung fallen?
• Migrations-Bereitschaft: Ist Ihr aktueller Stack so strukturiert, dass eine spätere Migration auf EU-Infrastruktur in vertretbarem Aufwand möglich wäre?

Zwei oder mehr Ja-Antworten bedeuten: Stufe 2 oder 3 sollte aktiv geprüft werden, nicht nur theoretisch. Eine oder keine Ja-Antwort bedeutet: Szenario C ist der richtige Ausgangspunkt, mit bewusster Entscheidung für SCCs als Compliance-Instrument.

Souveränität ist keine Frage von Gut und Böse. Es ist eine Frage von Anforderungen, Kosten und realistischer Ops-Kapazität. Die ehrlichste Aussage lautet: Für die meisten Projekte in der DACH-Region ist Szenario C ausreichend. Wer das wissentlich wählt, trifft eine bessere Entscheidung als jemand, der Szenario B aus Prinzip wählt und die Ops-Zeit dann nicht aufbringt.

Wenn Sie konkret einschätzen möchten, welche Stufe zu Ihrem Projekt passt: Lassen Sie uns in einem kurzen Gespräch die Anforderungen durchgehen. Ich arbeite mit 1-2 Kunden gleichzeitig und nehme mir entsprechend Zeit für eine ehrliche Einschätzung. Einen Einstieg bietet mein KI-Einrichtungsangebot, das Stack-Entscheidung, Setup und Übergabe verbindet. Und wer verstehen will, wie ich KI-Agenten dabei über hunderte Sessions konsistent einsetze, findet das in Harness Design für KI-Coding-Agenten beschrieben.