Wer auf AWS, Azure oder GCP hostet, unterliegt dem CLOUD Act — unabhängig davon, ob die Server in Frankfurt oder Dublin stehen. Gleichzeitig enthält KI-generierter Code systematische Sicherheitslücken. Beides sind lösbare Probleme: Die Migration auf EU-souveräne Infrastruktur beseitigt das rechtliche Risiko, und ein Security-Review schließt die technischen Lücken.
Das Problem: US-Cloud + KI-Code = doppeltes Risiko
Rechtliches Risiko: CLOUD Act und DSGVO
Der CLOUD Act verpflichtet US-Anbieter, Daten auf Anfrage von US-Behörden herauszugeben — auch wenn die Daten physisch in der EU liegen. Ein internes Gutachten des Bundesministeriums des Innern bestätigt: Der US-Behördenzugriff auf Daten bei US-Cloud-Anbietern „kann nicht zuverlässig ausgeschlossen werden." Igor's Lab: BMI-Gutachten zu US-Datenzugriff (2025)
Das betrifft nicht nur Großkonzerne. Jedes Unternehmen, das personenbezogene Daten auf US-Infrastruktur verarbeitet, hat ein DSGVO-Problem — ob es davon weiß oder nicht.
Technisches Risiko: KI-generierter Code
Laut Veracodes GenAI Code Security Report (2025) enthält 45% des KI-generierten Codes Sicherheitslücken — mit 2,74× mehr Schwachstellen als manuell geschriebener Code. Veracode: GenAI Code Security Report 2025 Die häufigsten Probleme:
- Exponierte Secrets: Hardcodierte API-Keys, Datenbankpasswörter im Frontend-Code, Secrets in der Git-History
- Fehlende Authentifizierung: Offene Admin-Routen, ungeschützte API-Endpunkte
- Input-Validierung: SQL-Injection, Cross-Site Scripting, fehlende serverseitige Validierung
- Dependency-Risiken: Veraltete Pakete mit bekannten CVEs
Wer einen Prototyp mit Cursor, Copilot oder v0 gebaut hat, hat mit hoher Wahrscheinlichkeit mehrere dieser Lücken im Code.
Die Lösung: Migration auf EU-Infrastruktur mit Security-Härtung
Die Migration besteht aus zwei parallelen Arbeitssträngen: der Verlagerung auf EU-souveräne Infrastruktur und der Absicherung des Codes.
Infrastruktur-Migration
- Compute: Von Vercel/AWS/Netlify auf Hetzner Cloud (Rechenzentrum Deutschland) — bei containerisierten Anwendungen mit K3s-Cluster-Setup
- Datenbank: Managed PostgreSQL auf Hetzner oder Self-Hosted
- DNS und TLS: Korrekte Konfiguration mit HSTS und aktuellen Zertifikaten
- Storage: S3-kompatibles Object Storage auf Hetzner, falls benötigt
Security-Härtung
- Kritische Schwachstellen schließen und Secrets rotieren
- Authentifizierung und Autorisierung prüfen und absichern — bei Bedarf Migration auf Keycloak als Self-Hosted Identity Provider (Magic Links, Passwordless Auth, SSO)
- Input-Validierung serverseitig implementieren
- Dependencies aktualisieren und gegen bekannte CVEs prüfen
DSGVO-konforme Konfiguration
- Datenverarbeitung ausschließlich in der EU — kein Drittlandtransfer
- Verschlüsselung at rest und in transit
- Logging ohne PII — personenbezogene Daten raus aus den Logfiles
- Cookie-Consent und Datenschutzhinweise technisch korrekt implementiert
CI/CD und Monitoring
- Automatisierte Deployments über GitHub Actions und ArgoCD (GitOps) mit Quality Gates
- Staging-Umgebung für sicheres Testen vor dem Go-Live
- Monitoring mit OpenTelemetry, Grafana und Prometheus — Health Checks, Alerting und Tracing bei Ausfällen oder Performance-Problemen
Was sich konkret ändert
Das Ergebnis ist kein PDF mit Empfehlungen, sondern eine funktionierende Anwendung auf europäischer Infrastruktur. Die kritischen Sicherheitslücken sind geschlossen, die CI/CD-Pipeline deployt automatisch, und das Monitoring zeigt den Status in Echtzeit.
Kostenvorteil: Hetzner vs. AWS
Die Migration ist nicht nur eine Compliance-Maßnahme — EU-Infrastruktur ist deutlich günstiger als vergleichbare US-Cloud-Ressourcen:
| Kriterium | Hetzner (DE) | AWS Frankfurt |
|---|---|---|
| 8 vCPU / 16 GB RAM | ~€12/Monat (CX43, Shared) | ~€155/Monat (m6i.xlarge On-Demand) |
| 8 vCPU / 32 GB RAM (dediziert) | ~€62/Monat (CCX33) | ~€309/Monat (m6i.2xlarge) |
| 1 TB Block Storage | ~€57/Monat | ~€88/Monat (gp3) |
| Traffic (20 TB/Monat) | Inklusive | ~€1.660 (Egress-Kosten) |
| Self-hosted PostgreSQL (16 GB) | ~€31/Monat (CCX23) | Ab ~€265/Monat (RDS Managed) |
| CLOUD Act Exposition | Keine | Vollständig |
Typischer Ablauf
| Phase | Was passiert | Dauer |
|---|---|---|
| Assessment | Code-Review und Erstgespräch | Vor Projektstart |
| Security-Fixes | Kritische Schwachstellen schließen, Secrets rotieren | Woche 1–2 |
| Infrastruktur-Setup | Hetzner-Server, Datenbank, Netzwerk, Firewall | Woche 2–3 |
| Migration | Anwendung deployen, Daten migrieren, DNS umstellen | Woche 3–4 |
| CI/CD & Monitoring | Pipeline einrichten, Health Checks, Alerting | Woche 4–5 |
| Stabilisierung | Monitoring, Performance-Check, Übergabe | Woche 5–6 |
Der genaue Zeitrahmen hängt von der Komplexität der Codebasis ab. Einfache Next.js-Apps auf Vercel sind in 2–3 Wochen migriert. Komplexere Setups mit mehreren Services und Datenbanken brauchen 4–6 Wochen.
Wann ist eine Migration sinnvoll?
- Prototyp auf US-Cloud: Die App funktioniert, aber DSGVO-Konformität fehlt und der Code ist nicht produktionsreif.
- DSGVO-Anforderungen von Kunden oder Investoren: Datensouveränität wird explizit gefordert.
- Kein internes DevOps-Team: Frontend und Geschäftslogik sind abgedeckt, aber Infrastruktur und Security nicht.
- NIS2-Vorbereitung: Die NIS2-Richtlinie verlangt dokumentierte Sicherheitsmaßnahmen — gehärteter Code auf EU-Infrastruktur ist ein konkreter erster Schritt. BSI: NIS2-Umsetzung
Abgrenzung: Migration vs. Neuentwicklung
Eine Migration setzt voraus, dass der Prototyp im Kern funktioniert und die Geschäftslogik stimmt. Wenn die Codebasis grundlegend re-architektoniert werden muss, Performance-Probleme tief in der Architektur sitzen oder Authentifizierung und Datenmodell von Grund auf neu gebaut werden müssen, ist eine Migration nicht ausreichend — dann ist ein MVP-Engineering-Projekt der richtige Ansatz.
Wir schauen uns Ihre Codebasis an und sagen Ihnen, was nötig ist. Schreiben Sie uns eine kurze Projektbeschreibung, und wir melden uns innerhalb von 24 Stunden.