AWS European Sovereign Cloud: Prompt erstellt deine EU-Migrations-Roadmap

Die erste Region des AWS European Sovereign Cloud (ESC) ist in Brandenburg aktiv. AWS hat dafür 7,8 Milliarden Euro investiert, die Infrastruktur wird ausschließlich von EU-Residenten betrieben, Kundendaten und Metadaten verbleiben physisch und logisch innerhalb der EU – getrennt von allen anderen AWS-Regionen. Für DACH-Unternehmen in regulierten Branchen wie Finanz- oder Gesundheitswesen ist die Frage nicht mehr ob, sondern wann sie migrieren. Der folgende Prompt übernimmt die initiale Readiness-Analyse und baut daraus eine priorisierte Roadmap.

Der Prompt kombiniert Role Prompting, strukturierte XML-Ausgabe und Chain-of-Thought-Sequenzierung. Er ist für GPT-5.4 Pro und Claude Opus 4.6 getestet und liefert plattformübergreifend konsistente Ergebnisse. DSGVO-Guardrails und EU AI Act-Relevanzchecks sind direkt im Prompt verankert – keine separaten Prompts nötig.

ROLE: Du bist ein zertifizierter AWS Cloud Architect mit Spezialisierung auf EU-Datensouveränität und regulatorische Cloud-Compliance im DACH-Raum. Du kennst die technischen Unterschiede zwischen Standard-AWS-Regionen und dem AWS European Sovereign Cloud (ESC) sowie die aktuellen Anforderungen aus DSGVO (Art. 22, Art. 35), EU AI Act (GPAI-Regeln seit Aug 2025) und branchenspezifischen Regulatoriken wie BAFIN-Vorgaben und NIS-2.

KONTEXT: Das Unternehmen [UNTERNEHMEN] aus [BRANCHE] (z. B. Finanzdienstleister, Gesundheitswesen, Öffentlicher Sektor) betreibt aktuell Workloads in der AWS-Region [AKTUELLE_REGION] (z. B. eu-central-1 Frankfurt). Es prüft eine Migration zum AWS European Sovereign Cloud mit erster Region in Brandenburg, Deutschland. Bekannte Workloads: [WORKLOAD_LISTE] (z. B. "ERP auf EC2, Datenbank auf RDS Aurora, ML-Pipeline auf SageMaker, Datenarchiv auf S3").

AUFGABE: Führe eine strukturierte Sovereignty-Readiness-Analyse durch und erstelle eine priorisierte Migrations-Roadmap. Arbeite Schritt für Schritt vor:

Schritt 1 – Workload-Klassifizierung: Kategorisiere jeden genannten Workload nach Datensensitivität (personenbezogen / reguliert / unkritisch) und ESC-Migrationskomplexität (Low / Medium / High). Begründe jede Einstufung kurz.

Schritt 2 – Compliance-Gap-Analyse: Prüfe für jeden Workload, ob er aktuell DSGVO Art. 35 (DSFA-Pflicht), EU AI Act GPAI-Anforderungen (falls KI/ML involviert) oder branchenspezifische Auflagen auslöst. Markiere offene Lücken.

Schritt 3 – Abhängigkeits-Mapping: Identifiziere kritische Service-Abhängigkeiten (z. B. AWS-Services, die im ESC noch nicht verfügbar sind), externe API-Verbindungen und Drittlandtransfer-Risiken.

Schritt 4 – Migrations-Roadmap: Erstelle eine 3-Phasen-Roadmap (Quick Wins 0–3 Monate / Kern-Migration 3–12 Monate / Optimierung 12–24 Monate). Priorisiere nach Regulierungsdruck und Migrationsaufwand.

Schritt 5 – Risiken und Guardrails: Liste die Top-3-Migrationsrisiken auf und empfehle konkrete technische und organisatorische Maßnahmen (TOMs).

OUTPUT-FORMAT:

  [Tabelle mit Workload, Datensensitivität, Komplexität, Begründung]
  [Liste offener Compliance-Punkte je Workload]
  [Kritische Abhängigkeiten und Drittlandrisiken]
  [3-Phasen-Plan mit Meilensteinen und Verantwortlichkeiten]
  [Top-3-Risiken + empfohlene TOMs]


VARIABLEN ZUM ANPASSEN:
- [UNTERNEHMEN]: Name oder Typ deines Unternehmens
- [BRANCHE]: z. B. Banken, Krankenhäuser, Behörden, Industrie
- [AKTUELLE_REGION]: z. B. eu-central-1, eu-west-1
- [WORKLOAD_LISTE]: Kommaseparierte Liste deiner wichtigsten AWS-Workloads

GUARDRAILS: Nenne keine Produktnamen, die im ESC nachweislich nicht verfügbar sind, ohne dies explizit als Risiko zu markieren. Mache keine DSGVO-Compliance-Garantien – formuliere ausschließlich Handlungsempfehlungen. Verweise bei Unklarheiten auf erforderliche juristische Prüfung durch DSGVO-Fachkraft. Berücksichtige den EU AI Act: Seit August 2025 sind GPAI-Regeln und Governance-Pflichten in Kraft; ab August 2026 gelten Hochrisiko-KI-Anforderungen vollständig.

Beispiel-Output (fiktiv, DACH-Kontext):

Unternehmen: Musterbank AG, Frankfurt | Branche: Finanzdienstleister | Region: eu-central-1 | Workloads: Kernbanksystem auf EC2, Kundendatenbank auf RDS Aurora, KYC-ML-Pipeline auf SageMaker, Dokumentenarchiv auf S3

Workload-Klassifizierung:
– Kernbanksystem (EC2): Datensensitivität hoch (reguliert nach MaRisk/BAFIN), Komplexität High – aufgrund enger Abhängigkeit zu Legacy-Middleware und Echtzeit-Settlement-APIs.
– Kundendatenbank (RDS Aurora): Datensensitivität hoch (personenbezogen, DSGVO Art. 35 DSFA-pflichtig), Komplexität Medium – Aurora ist im ESC verfügbar, Replikations-Konfiguration erfordert Anpassung.
– KYC-ML-Pipeline (SageMaker): Datensensitivität sehr hoch (biometrisch/personenbezogen + EU AI Act Hochrisiko ab Aug 2026), Komplexität High – GPAI-Compliance-Prüfung erforderlich. – Dokumentenarchiv (S3): Datensensitivität mittel (teils reguliert), Komplexität Low – ideal als Quick Win.

Phase 1 – Quick Wins (0–3 Monate): Migration Dokumentenarchiv (S3) in ESC-Region Brandenburg. Kosten: ca. 1.200 EUR/Monat Mehraufwand geschätzt. Verantwortlich: Cloud-Ops-Team. Phase 2 – Kern-Migration (3–12 Monate): Kundendatenbank mit DSFA-Dokumentation; paralleler Betrieb während Cutover. BAFIN-Vorabstimmung empfohlen. Top-Risiko: SageMaker-Verfügbarkeit im ESC zum Zeitpunkt der KYC-Pipeline-Migration nicht vollständig bestätigt – juristische Prüfung und AWS-Roadmap-Abgleich erforderlich.

Prompt-Anwendung: Variablen und Iteration

Fülle vor dem ersten Einsatz die vier Variablen aus. [UNTERNEHMEN] und [BRANCHE] setzen den regulatorischen Kontext – ein Krankenhaus löst andere Compliance-Ketten aus als ein SaaS-Startup. [AKTUELLE_REGION] ist entscheidend für das Abhängigkeits-Mapping, da Service-Verfügbarkeit zwischen eu-central-1 und dem ESC abweicht. Die [WORKLOAD_LISTE] ist dein wichtigster Input: Je präziser (inkl. genutzter AWS-Services), desto granularer die Roadmap.

Der Prompt funktioniert in einer einzigen Session mit GPT-5.4 Pro oder Claude Opus 4.6. Für besonders komplexe Workload-Landschaften empfiehlt sich ein iterativer Ansatz: Führe zunächst nur Schritt 1 und 2 aus, validiere die Klassifizierungen intern, und übergib das Ergebnis als Kontext für einen zweiten Prompt-Lauf mit Schritten 3 bis 5. Das reduziert Halluzinations-Risiken bei unbekannten Service-Abhängigkeiten.

Die DSGVO-Guardrails im Prompt sind bewusst defensiv formuliert: Das Modell wird angewiesen, keine Compliance-Garantien auszusprechen. Das schützt dich vor dem klassischen Fehler, KI-Output direkt als Rechtsgutachten zu verwenden. Für Hochrisiko-Workloads im Sinne des EU AI Act – etwa KYC-Systeme oder automatisierte Kreditentscheidungen nach Art. 22 DSGVO – ist ein juristischer Review Pflicht, bevor du die Roadmap operationalisierst.

Prompt-Analyse: Techniken und Effizienz

Der Prompt nutzt drei nachweislich wirkungsvolle Techniken kombiniert. Erstens Role Prompting: Die explizite Zuweisung einer Expertenrolle mit domänenspezifischen Zertifizierungen aktiviert im Modell statistisch häufiger co-auftretende Token aus Fach-Corpora – konkret Cloud-Architektur-Dokumentation, AWS-Whitepapers und Compliance-Frameworks. Das Modell "weiß" dadurch implizit mehr über ESC-spezifische Einschränkungen als bei einem neutralen Prompt.

Zweitens Chain-of-Thought-Sequenzierung: Die fünf expliziten Schritte zwingen das Modell, jeden Reasoning-Schritt separat zu verarbeiten, bevor es zum nächsten übergeht. Ohne diese Sequenzierung würde ein LLM bei komplexen Workload-Landschaften häufig Analyse und Empfehlung vermischen und dabei Abhängigkeiten übersehen. Die Schrittfolge erzwingt kognitives Scaffolding.

Drittens XML-Strukturierung des Outputs: Das vorgegebene <sovereignty_assessment>-Schema erzwingt strukturierte Token-Ausgabe. Das hat zwei Vorteile: Das Modell "weiß" durch das XML-Tag-Framing, welche Informationsdichte pro Sektion erwartet wird – und du kannst den Output direkt in nachgelagerte Tools (Confluence, Jira, Power BI) importieren ohne manuelle Nachbearbeitung. Laut einer Auswertung von Stanford HAI aus 2024 reduziert strukturiertes Output-Prompting den manuellen Nachbearbeitungsaufwand bei Analyse-Prompts um durchschnittlich 40 Prozent.

Die Guardrails-Sektion am Ende des Prompts ist technisch ein Constraint-Layer: Sie definiert, was das Modell explizit nicht tun darf. LLMs folgen Negativ-Constraints bei korrekter Formulierung zuverlässig – die Formulierung "Nenne keine Produktnamen, die im ESC nachweislich nicht verfügbar sind, ohne dies als Risiko zu markieren" ist präziser und effektiver als ein generisches "Sei vorsichtig mit Empfehlungen".