AWS Bedrock in EU-Regionen: CLOUD Act, FISA 702, Schwachstellen und Beratungsoptionen
Zweck dieses Bausteins
Dieses Kompendium dient als belastbare Beratungsgrundlage fuer Gespraeche mit Unternehmen (insb. regulierte Branchen), die GenAI mit AWS Bedrock in Europa einsetzen wollen.
Executive Aussage (kurz)
- Die Aussage “EU-Hosting bringt nichts” ist zu absolut.
- Die Aussage “EU-Hosting loest alles” ist ebenfalls falsch.
- Korrekt ist:
EU-Regionreduziert Datenabflussrisiken und ist compliance-relevant, neutralisiert aber US-Zugriffsregime (CLOUD Act/FISA 702) nicht vollstaendig, wenn der Anbieter US-jurisdiktionsgebunden ist. - Daraus folgt kein automatischer Verstoss gegen den EU AI Act.
1) Rechtsrahmen: Was greift tatsaechlich?
1.1 CLOUD Act (US)
Kernpunkt: US-Provider koennen zur Herausgabe von Daten verpflichtet werden, die unter ihrer “possession, custody, or control” stehen, auch wenn diese ausserhalb der USA gespeichert sind.
Beraterrelevanz:
- Speicherort allein (
Frankfurt,Irland) ist kein vollstaendiger Souveraenitaetsschutz. - Jurisdiktion folgt der kontrollierenden Rechtsperson, nicht nur dem Rack-Standort.
1.2 FISA Section 702 (US)
Kernpunkt: US-Nachrichtendienstliche Erhebung gegen Nicht-US-Personen ausserhalb der USA unter Beteiligung verpflichteter Kommunikations-/Cloud-Provider.
Wichtig zur Einordnung:
- Nicht “jederzeit alles ohne Regeln”.
- Aber aus EU-Sicht seit
Schrems IIein struktureller Problemraum (Proportionalitaet, Rechtsschutzfragen).
1.3 EU-Seite (GDPR Art. 48, Schrems II, EDPB-Linie)
GDPR Art. 48: Drittstaatliche Offenlegungsanordnungen sind nicht einfach direkt in der EU durchsetzbar; internationale Rechtsgrundlage ist zentral.Schrems II: US-Überwachungszugriffsrahmen war Kernargument fuer die Aufhebung frueherer Transferrahmen.- EDPB-Linie: Transfer- und Zugriffsriskiken muessen in TIA/Supplementary-Measures-Logik sauber adressiert werden.
1.4 DPF (EU-US Data Privacy Framework)
- DPF ist derzeit ein gueltiger Transfermechanismus fuer zertifizierte US-Organisationen.
- DPF beseitigt jedoch nicht jede Restunsicherheit fuer alle Use Cases (insb. bei hohen Schutzbedarfen).
Beraterformel:
Gueltiger Transfermechanismus != Null-Zugriffsrisiko.
2) Bedrock-spezifische Realitaet (EU-Hosting)
2.1 Was EU-Hosting real verbessert
- Datenresidenz (at-rest in gewaehlter Region).
- Steuerbarkeit von Region/Netzwerkpfaden (z. B. PrivateLink, IAM/SCP-Restriktionen).
- Compliance-Nachweisbarkeit in Audits verbessert sich deutlich.
2.2 Was EU-Hosting nicht automatisch loest
- US-Rechtszugriffsrisiko auf Provider-Ebene.
- Fehlkonfigurationen (Cross-Region-Inference, unklare Logging/Retention-Settings).
- Modellspezifische Data-Share-/Retention-Besonderheiten.
2.3 Kritischer Praxispunkt fuer Berater
Bei einzelnen Modell-/API-Modi kann Datenweitergabe oder befristete Aufbewahrung abweichen. Das muss pro Modellfamilie, Retention-Mode und Account-Policy explizit geprueft werden.
3) Gap- und Schwachstellenanalyse (Was oft uebersehen wird)
3.1 Juristische Gaps
- “EU-Region reicht”-Trugschluss ohne Transfer-/Zugriffsbewertung.
- DPA/SCC/DPF zwar vorhanden, aber keine belastbare TIA-Argumentation fuer den konkreten Datenfluss.
- Unklare Verantwortlichkeiten zwischen Fachbereich, Legal, CISO, Datenschutz.
3.2 Technische Gaps
- Kein hartes Region-Guardrail (SCP/IAM) -> versehentliche Ausleitung.
- Fehlende Prompt-Data-Policy (PII/Bankgeheimnis/Kundendaten in Klartext).
- Keine verbindliche Redaction-/Pseudonymisierungsschicht vor Modellaufruf.
- Unzureichendes Logging fuer Nachweis und Incident-Response.
3.3 Operative Gaps
- Use Cases werden nicht nach Kritikalitaet klassifiziert.
- Kein Freigabeverfahren je Datenklasse.
- Kein Exit-/Portabilitaetsplan bei regulatorischer Neubewertung.
3.4 Kommunikations-Gaps (Management)
- Entweder “alles verboten” oder “alles kein Problem”.
- Fehlende Risiko-Normalisierung: Es geht um Restrisiko-Steuerung, nicht um absolute Eliminierung.
4) Was geht / was geht nicht (praxisnah)
Geht gut (bei solider Governance)
- Interne Wissensassistenten mit nicht-hochsensiblen Daten.
- Coding-/Produktivitaets-Copilots ohne produktive Kundendaten.
- Marketing-/Dokumentations-Use-Cases mit redigierten Inhalten.
Geht bedingt (nur mit starker Kontrollebene)
- Kundenservice-Assistenz mit PII in minimierter Form.
- Finanz-/Risikotext-Generierung fuer interne Vorlagen.
- RAG auf kontrollierten, klassifizierten Quellen.
Geht nicht (oder nur nach sehr hoher Huerde)
- Ungefilterte Eingabe von hochsensiblen Kunden-/Kontodaten.
- Regulatorisch kritische Entscheidungen ohne Human Oversight.
- Einsatz ohne dokumentierte Rechtsgrundlage, TIA und Kontrollarchitektur.
5) Alternativenanalyse
A) AWS Bedrock EU-Hosting + starke Zusatzkontrollen
Staerken
- Breites Modellangebot, Enterprise-Integration, skalierbarer Betrieb.
- Gute technische Sicherheitsbausteine verfuegbar.
Schwaechen
- Jurisdiktionsdebatte bleibt.
- Governance-Aufwand hoch.
Geeignet wenn
- Unternehmen cloud-reif ist und Governance diszipliniert umsetzt.
B) EU-native AI-Provider (oder EU-jurisdiktionsfokussierte Plattformen)
Staerken
- Einfachere Souveraenitaetsnarrative gegenueber Stakeholdern.
- Potenziell geringerer Rechtskonflikt-Druck.
Schwaechen
- Je nach Anbieter weniger Oekosystemtiefe/Features.
- Modellportfolio/Leistungsprofil kann enger sein.
Geeignet wenn
- Jurisdiktions-/Souveraenitaetsanforderungen strategisch Vorrang haben.
C) Hybrid-/Dual-Vendor-Strategie
Staerken
- Datenklassen-spezifische Zuordnung (sensitive Workloads EU-nativ, andere auf Hyperscaler).
- Bessere Verhandlungsmacht und Exit-Faehigkeit.
Schwaechen
- Hoehere Betriebs- und Integrationskomplexitaet.
Geeignet wenn
- Reife Plattform-Teams und klare Architekturgovernance vorhanden sind.
6) Beratungs-Entscheidungslogik (empfohlene Aussage)
Empfohlene Beratungsposition:
- Nicht ideologisch, sondern risikobasiert argumentieren.
- EU-Hosting als notwendige, aber nicht hinreichende Bedingung einordnen.
- Jurisdiktionsrestrisiko transparent benennen.
- Freigabe an harte Kontrollen koppeln:
- Datenklassifikation
- Region-/Egress-Guardrails
- Redaction/Pseudonymisierung
- TIA + Rechtsgrundlagen
- Logging/Auditierbarkeit
- Human Oversight
Kernaussage fuer Management: “Die Frage ist nicht, ob Restrisiko existiert, sondern ob das Restrisiko fuer den konkreten Use Case nachweisbar beherrscht wird.”
7) Red Flags (Sofort-Eskalation)
- “Wir haben EU-Region, also sind wir safe”.
- Keine dokumentierte Datenklassifikation fuer Prompts/Outputs.
- Unklare Modell-/Retention-Policies.
- Kein nachweisbarer Kontrollrahmen fuer Regulatoren.
8) Due-Diligence-Checkliste (Kurz)
- Use Case-Klassifizierung (niedrig/mittel/hochkritisch)
- Datenarten und Verbotszonen definiert
- Region-/Cross-Region-Policies technisch erzwungen
- Modell- und Retention-Modi je Use Case freigegeben
- Transfermechanismus + TIA dokumentiert
- Rollen/RACI zwischen Legal, Datenschutz, CISO, Fachbereich geklaert
- Logging, Monitoring, Incident-Prozess vorhanden
- Review-Zyklus (quartalsweise oder regulatorisch getrieben) etabliert
9) Positionierung fuer Beratungsgespraeche (sprechfaehige Formulierung)
“Bedrock in EU-Regionen ist kein No-Go und kein Auto-Pass. Es ist ein kontrollierbares Setup mit juristischem Restrisiko, das nur mit sauberer Governance, technischer Begrenzung und belastbarer Dokumentation tragfaehig ist.”
10) Quellenanker (Primarquellen)
- EU-Kommission, Durchfuehrungsbeschluss (EU) 2023/1795 (DPF)
- EDPB Information Note zum DPF (2023)
- EDPB Guidelines 02/2024 zu Art. 48 GDPR
- EDPB Recommendations 01/2020 (v2.0, Supplementary Measures)
- US Congress CRS: CLOUD Act (R45173)
- US Congress / Statut zu FISA 702
- AWS Bedrock FAQ + Bedrock User Guide (Data Retention / Data Protection)
Hinweis
Dies ist eine fachliche Arbeitsgrundlage, keine individuelle Rechtsberatung. Fuer konkrete Mandate ist eine juristische Einzelfallpruefung erforderlich.
11) Erklärung in einfacher Sprache (als wäre man 12)
Merksatz: Es geht nicht um „sicher oder unsicher“. Es geht um: Wer kann unter welchen Regeln an meine Daten? Und: Habe ich das schriftlich geprüft und abgesichert?
Die drei Begriffe als Alltagsbild
| Begriff | Einfaches Bild | Was es wirklich heißt |
|---|---|---|
| EU-Hosting | Dein Tagebuch liegt in einem Schließfach in Frankfurt. | Daten werden in einer EU-Region verarbeitet/gespeichert. |
| CLOUD Act | Der Schließfach-Anbieter hat seinen Firmensitz in den USA. US-Behörden können ihn unter bestimmten Regeln auffordern, Inhalte herauszugeben – auch wenn das Schließfach in Frankfurt steht. | US-Recht kann US-Firmen zur Herausgabe von Daten verpflichten, die sie kontrollieren – unabhängig vom Speicherort. |
| FISA 702 | Ein anderes US-Gesetz für Geheimdienste (nicht normale Polizei auf der Straße). Betroffene Firmen können unter strengen, aber aus EU-Sicht kritischen Regeln zur Mithilfe verpflichtet werden. | US-Geheimdienste dürfen unter Auflagen Daten von Nicht-US-Personen im Ausland erheben, oft mit Hilfe von Tech-Firmen. |
| TIA | Bevor du jemandem im Ausland etwas Anvertrauust, schreibst du auf: Was könnte schiefgehen? Was machst du dagegen? Reicht das? | Transfer Impact Assessment: dokumentierte Risikoprüfung bei Datentransfers in Drittländer. |
Warum „Frankfurt reicht nicht“ – aber auch nicht „alles verboten“
Stell dir vor:
- Du legst Fotos von deinem Geburtstag (unkritisch) in ein US-Unternehmens-Schließfach in Frankfurt.
- Oder du legst deinen Ausweis + Kontonummer + Gesundheitsdaten (sehr kritisch) dort hinein.
Gleicher Anbieter. Gleiche Stadt. Völlig anderes Risiko.
Deshalb sagen Banken nicht pauschal „AWS = verboten“. Sie sagen eher: Welche Daten? Welcher Use Case? Welche Schutzmaßnahmen? Haben wir das dokumentiert?
12) Was ist eine TIA? (Transfer Impact Assessment)
In einem Satz
Eine TIA ist ein schriftlicher Sicherheitscheck, bevor personenbezogene Daten in ein Land außerhalb der EU/EWR geschickt oder dort von einem Anbieter verarbeitet werden.
Die TIA als 5 Schritte (Kindgerecht → Berater-tauglich)
Schritt 1 – Was wird verschickt?
- Beispiel: Nur interne FAQ-Texte ohne Namen → niedriges Risiko.
- Beispiel: Kundenname + IBAN + Beratungsprotokoll → hohes Risiko.
Schritt 2 – Wohin geht es (rechtlich)?
- Technisch: Frankfurt (
eu-central-1). - Rechtlich: Anbieter ist US-Mutterkonzern → US-Gesetze können trotzdem relevant sein.
Schritt 3 – Gibt es ein „Erlaubnis-Ticket“?
- Z. B. Standardvertragsklauseln (SCC), DPA, ggf. DPF-Zertifizierung.
- Das Ticket sagt: „Transfer ist grundsätzlich erlaubt – wenn du zusätzlich prüfst.“
Schritt 4 – Was könnte in dem Land schiefgehen?
- Könnte eine US-Behörde Zugriff verlangen?
- Wie wahrscheinlich ist das für genau diesen Use Case?
- Was wäre der Schaden, wenn es passiert?
Schritt 5 – Was machst du dagegen?
- Weniger sensible Daten senden (Pseudonymisierung).
- Verschlüsselung, wo du den Schlüssel selbst hältst.
- Region fest einstellen, Cross-Region verbieten.
- Logging, Freigaben, menschliche Kontrolle.
Ergebnis der TIA:
- ✅ „Für diesen Use Case tragfähig“
- ⚠️ „Nur mit Extra-Maßnahmen“
- ❌ „Nicht freigeben“
Mini-TIA-Beispiel (ausgefüllt)
| Feld | Inhalt |
|---|---|
| Use Case | Interner HR-Chatbot für Urlaubsregeln |
| Daten | Keine Kundendaten, keine Gesundheitsdaten, keine Namen in Prompts |
| Anbieter | AWS Bedrock, Region Frankfurt |
| Transfergrundlage | AWS DPA + SCC |
| Risiko US-Zugriff | Theoretisch vorhanden, praktisch gering wegen Datenarmut |
| Maßnahmen | Region-Lock, Prompt-Filter, keine PII, Logging |
| Entscheidung | ✅ Freigabe mit Review alle 6 Monate |
Was eine TIA nicht ist
- Kein „Papier für die Schublade“.
- Kein Ersatz für Anwalt/Datenschutz bei hochkritischen Fällen.
- Kein Garantie-Zertifikat „100 % sicher“.
13) Konkrete Beispiele (3 Unternehmen, 3 Entscheidungen)
Beispiel A – Versicherung, interner Wissens-Assistent
Situation: Mitarbeiter fragen Bedrock: „Wie ist unsere Schadenregel bei Hagelschäden?“ Daten: Nur interne Handbücher, keine Kundennamen. Entscheidung: ✅ Meist unkritisch. Warum: Wenig personenbezogene Daten, hoher Nutzen, überschaubares Risiko. TIA-Fazit: Einfach, aber trotzdem dokumentieren.
Beispiel B – Bank, Kundenservice-Copilot
Situation: Berater lässt sich Antworten für Kunden-Mail vorschlagen. Daten: Name, Kontonummer, Transaktionsdetails im Prompt. Entscheidung: ⚠️ Nur mit harten Regeln. Pflicht-Maßnahmen:
- Automatische Schwärzung von IBAN/Name vor dem API-Call
- Nur freigegebene Modelle/Retention-Modi
- Mensch prüft jede Antwort vor Versand
- TIA + Datenschutz-Freigabe TIA-Fazit: Möglich, aber nicht „einfach anmachen“.
Beispiel C – Bank, Kreditentscheidung per KI
Situation: Modell soll Kreditanträge automatisch bewerten. Daten: Einkommen, Schufa, Bonität, vollständige Kundenprofile. Entscheidung: ❌ Mit Bedrock/US-Cloud in dieser Form meist No-Go. Warum: Extrem hoher Schaden bei Fehlern + regulatorischer Druck + kaum vertretbares Restrisiko. Alternative: EU-nativer Anbieter, On-Prem, oder gar kein Auto-Scoring.
14) Fragen & Antworten (FAQ für Beratungsgespräche)
Grundlagen
F: Heißt EU-Hosting, dass die NSA nichts sieht? A: Nein, das garantiert niemand. EU-Hosting hilft bei Speicherort und Kontrolle – aber US-Anbieter können unter US-Recht weiterhin relevant sein. Entscheidend ist: welche Daten und welche Schutzmaßnahmen.
F: Verstoßen Banken gegen den EU AI Act, wenn sie Bedrock nutzen? A: Nicht automatisch. Der AI Act regelt Pflichten je nach Risikoklasse und Rolle (Anbieter/Nutzer). US-Herkunft allein ist kein Verstoß.
F: Ist AWS Bedrock deshalb illegal in Europa? A: Nein, pauschal nicht. Legalität hängt vom konkreten Use Case, der Datenart und der dokumentierten Compliance ab.
TIA
F: Brauche ich immer eine TIA? A: Sobald personenbezogene Daten in Drittländer fließen oder dort verarbeitet werden und du nicht nur auf einen reinen Angemessenheitsbeschluss ohne Zusatzprüfung setzt, ist eine Transfer-Risikobewertung üblich – praktisch oft als TIA.
F: Wer schreibt die TIA? A: Typisch: Datenschutz/Legal + IT/CISO + Fachbereich. Du als Berater lieferst Struktur, Use-Case-Fakten und Maßnahmenvorschläge.
F: Wie lang muss eine TIA sein? A: Nicht 100 Seiten. Für einfache Fälle reichen 2–5 Seiten. Für Banken-High-Risk eher mehr – mit klarer Begründung.
F: Reicht DPF statt TIA? A: DPF kann den Transfer erleichtern, ersetzt aber nicht immer die eigene Risikoabwägung – besonders bei sensiblen Daten.
Technik & Praxis
F: Was ist der häufigste Fehler? A: „Region Frankfurt eingestellt“ – aber Cross-Region-Inference aktiv oder Kundendaten ungefiltert im Prompt.
F: Was ist der beste schnelle Schutz? A: Keine sensiblen Daten in den Prompt. Klingt banal, wirkt am stärksten.
F: Was sage ich dem Vorstand in 20 Sekunden? A: „Wir können das nutzen, aber nur datensparsam, dokumentiert und mit klaren Grenzen – nicht als Black Box für Kundendaten.“
15) Entscheidungsbaum (simpel)
Start: Will das Unternehmen Bedrock nutzen?
│
├─ Enthält der Use Case Kundendaten/PII?
│ ├─ Nein → meist OK mit Basis-Governance + kurze TIA
│ └─ Ja → weiter prüfen
│
├─ Sind es hochsensible Daten (Finanz, Gesundheit, Kinder)?
│ ├─ Ja → nur mit starken Maßnahmen oder Alternative
│ └─ Nein → mittleres Risiko, TIA Pflicht
│
├─ Gibt es Pseudonymisierung + Human Review?
│ ├─ Nein → Freigabe stoppen
│ └─ Ja → weiter
│
├─ Region technisch erzwungen + Logging aktiv?
│ ├─ Nein → nachrüsten, nicht live gehen
│ └─ Ja → TIA abschließen
│
└─ TIA-Ergebnis dokumentiert?
├─ Ja → kontrolliert starten (Pilot)
└─ Nein → nicht starten
16) Sprechfertige Sätze für dich als Berater
- „EU-Region ist ein wichtiger Baustein, aber kein Zauberschild.“
- „Die eigentliche Frage ist nicht AWS ja/nein, sondern welcher Use Case mit welchen Daten.“
- „Eine TIA ist unser schriftlicher Reality-Check vor dem Go-Live.“
- „Wir reduzieren Risiko, wir eliminieren es nicht vollständig – außer wir senden gar keine sensiblen Daten.“
- „Wenn der Use Case hochkritisch ist, brauchen wir eher EU-native oder On-Prem – nicht nur eine andere Region.“
17) Nächster Lernschritt (für dich)
Wenn du willst, ergänze ich als Folge-Baustein:
- TIA-Vorlage zum Ausfüllen (Copy-Paste für Mandate)
- Rollenspiel-Skript (CISO vs. Fachbereich vs. Legal, 15 Minuten)
- Banken-Checkliste Ampel (Grün/Gelb/Rot je Datenklasse)
18) Vertragspartner vs. Mutterkonzern vs. Rechenzentrum (AWS Bedrock Europe)
Kurzantwort: Ja — hinter
AWS Bedrock Europesteht rechtlich eine US-Firma. Technisch läuft es in der EU, vertraglich oft über Luxemburg, kontrolliert von Amazon USA.
Die drei Ebenen (nicht verwechseln!)
| Ebene | Was es ist | Bei AWS Bedrock Europe typisch |
|---|---|---|
| 1. Rechenzentrum | Wo die Daten physisch verarbeitet/gespeichert werden | z. B. Frankfurt (eu-central-1), Irland (eu-west-1) |
| 2. Vertragspartner | Mit wem du den Vertrag schließt | Oft AWS EMEA SARL (Luxemburg) |
| 3. Mutterkonzern | Wer die Kontrolle hat | Amazon.com, Inc. (USA, Delaware) |
Merksatz:
Rechenzentrum in EU ≠ Anbieter ohne US-Jurisdiktion
Einfaches Bild (Schließfach-Analogie)
┌─────────────────────────────────────────────────────────┐
│ DU (Unternehmen in DE/EU) │
│ legst Daten in Bedrock-Prompts / Speicher │
└──────────────────────────┬──────────────────────────────┘
│ Vertrag
▼
┌─────────────────────────────────────────────────────────┐
│ VERTRAGSPARTNER: AWS EMEA SARL (Luxemburg) │
│ „Mit wem steht der DPA/Vertrag?“ │
└──────────────────────────┬──────────────────────────────┘
│ gehört zu / wird gesteuert von
▼
┌─────────────────────────────────────────────────────────┐
│ MUTTER: Amazon.com, Inc. (USA) │
│ „Wer ist US-jurisdiktionsgebunden?“ │
└──────────────────────────┬──────────────────────────────┘
│ betreibt
▼
┌─────────────────────────────────────────────────────────┐
│ RECHENZENTRUM: EU-Region (z. B. Frankfurt) │
│ „Wo liegen die Daten physisch?“ │
└─────────────────────────────────────────────────────────┘
Was bedeutet das praktisch?
| Frage | Antwort |
|---|---|
| Liegen meine Daten in der EU? | Ja, wenn du EU-Region korrekt konfigurierst und Cross-Region vermeidest. |
| Ist der Anbieter trotzdem US-Firma? | Ja, über die Mutter Amazon.com, Inc. |
| Heißt das automatisch „illegal“? | Nein. Es heißt: Transfer-/Zugriffsrisiko muss bewertet und dokumentiert werden (TIA). |
| Was hilft EU-Region dann wirklich? | Datenresidenz, weniger Datenfluss, bessere Audit-Story — aber kein juristisches Null-Risiko. |
Sprechsatz für Mandantengespräch
„Wir nutzen Bedrock in Frankfurt — das ist gut für den Datenstandort. Aber rechtlich hängt das Setup an einer US-Mutter. Deshalb klassifizieren wir Use Cases und Daten, statt nur die Region zu nennen.“
Typischer Fehler in Diskussionen
❌ „Wir haben EU-Hosting, also ist der Anbieter europäisch.“
✅ „Wir haben EU-Hosting und haben die US-Jurisdiktionsfrage für unseren Use Case geprüft.“
19) M365-Parität: gleiches Risiko, andere Aufmerksamkeit
Ehrliche Kernfrage: Wenn ein Unternehmen Outlook/M365 mit Kundendaten nutzt, hat es in der Cloud-Variante strukturell ein sehr ähnliches US-Jurisdiktions-Thema wie bei AWS Bedrock EU.
Vergleichstabelle (Cloud vs. Cloud)
| Kriterium | Microsoft 365 / Outlook (Cloud) | AWS Bedrock (EU-Region) |
|---|---|---|
| US-Mutter dahinter | ✅ Microsoft (USA) | ✅ Amazon (USA) |
| Daten können in EU liegen | ✅ (Tenant/Region-Setup) | ✅ (eu-central-1, eu-west-1) |
| CLOUD-Act-/FISA-Debatte relevant | ✅ grundsätzlich ja | ✅ grundsätzlich ja |
| Breite Produktivnutzung im Markt | ✅ sehr verbreitet | ⚠️ oft neu, stärker im Fokus |
| Management-Aufmerksamkeit | eher „etabliert“ | oft „neu & kritisch“ |
Berater-Merksatz: Wer Bedrock pauschal ablehnt „wegen US-Jurisdiktion“, aber M365 mit Kundendaten seit Jahren nutzt, sollte die Policy-Konsistenz erklären können.
Warum KI trotzdem oft härter diskutiert wird
- Neuer Use Case → neue Freigabe-/TIA-Logik
- Prompts enthalten oft ungefilterte Daten (höheres Fehlerrisiko)
- Modell-/Retention-Settings können je nach Setup zusätzliche Pfade eröffnen
- Regulatorischer und öffentlicher Fokus auf KI ist aktuell höher
- „Black-Box“-Wahrnehmung im Management
Das rechtfertigt mehr Kontrollen bei KI, aber nicht automatisch ein pauschales Verbot.
20) Gegenbeispiel: wirklich andere Architektur (On-Prem / Self-Hosted)
Wenn man das US-Jurisdiktionsargument wirklich vermeiden will, braucht man nicht nur „EU-Region“, sondern eine andere Kontroll- und Eigentümerstruktur.
Mail-Gegenbeispiel
| Variante | Was anders ist | Rest-Risiko |
|---|---|---|
| Outlook in M365 Cloud | US-Hyperscaler, EU-Rechenzentrum möglich | US-Jurisdiktionsdebatte bleibt |
| Outlook/Exchange on-prem in Frankfurt | Eigener Server, eigener Betrieb, eigene Kontrolle | Deutlich weniger US-Provider-Exposure; dafür eigener Betriebs-/Security-Aufwand |
Bild: Nicht mehr „Schließfach bei US-Anbieter in Frankfurt“, sondern „Tresor im eigenen Haus in Frankfurt“.
KI-Gegenbeispiel
| Variante | Was anders ist | Rest-Risiko |
|---|---|---|
| AWS Bedrock EU-Region | Managed AI bei US-Mutter, EU-Betrieb | Juristisches Restrisiko + Governance nötig |
| Eigen gehostetes Modell (On-Prem / Private Cloud EU) | Modell läuft auf eigener Infrastruktur oder EU-kontrolliertem Setup | Geringeres Provider-Jurisdiktionsrisiko; dafür höherer Betriebsaufwand, Modellpflege, Security-Verantwortung |
Bild: Statt „KI-Service mieten“ → „KI-Maschine selbst betreiben“.
Wichtige Nuance (ehrlich)
Auch On-Prem/Self-Hosted ist nicht Risiko-Null:
- Software-Updates, Support-Verträge, Telemetrie, externe APIs können wieder Drittland-Pfade öffnen
- Operativer Aufwand und Fachkompetenz steigen stark
- Qualität/Feature-Tempo oft schlechter als bei Hyperscaler-Modellen
Merksatz:
On-Prem reduziert vor allem das Provider-Jurisdiktionsrisiko, nicht automatisch alle Risiken.
21) Workshop-Fragen für Kunden (Konsistenz-Check)
Nutze diese 5 Fragen in Beratungsgesprächen:
-
„Nutzen wir heute M365/Outlook mit Kundendaten in der Cloud?“
→ Wenn ja: US-Jurisdiktionsdebatte ist meist schon im Unternehmen vorhanden. -
„Welche Transfer-/TIA-Logik haben wir für M365 dokumentiert?“
→ Zeigt Reifegrad und Vergleichsmaßstab für KI. -
„Warum soll KI strenger behandelt werden als Mail?“
→ Zwingt zu einer bewussten, nicht emotionalen Begründung. -
„Welche Datenklassen sind bei uns generell tabu für US-Hyperscaler?“
→ Ohne diese Klassen ist jede Tool-Diskussion beliebig. -
„Wann zahlen wir bewusst Mehrkosten für On-Prem/Self-Hosted?“
→ Trennt Ideologie von echter Risikostrategie.
Empfohlene Antwortlogik im Workshop
- Cloud + US-Hyperscaler: akzeptabel für viele Standard-Use-Cases mit klarer Governance
- Cloud + hochsensible Use-Cases: nur mit harten Zusatzkontrollen oder Ablehnung
- On-Prem/Self-Hosted: sinnvoll, wenn Jurisdiktions- und Kontrollanforderungen strategisch Vorrang vor Convenience haben
Sprechsatz für Entscheider
„Wir müssen nicht bei jedem Tool neu über US-Recht diskutieren. Wir brauchen eine einheitliche Daten- und Anbieterpolitik – und wenden sie auf Mail und KI gleichermaßen an.“
22) Betriebsgeheimnisse (nicht nur personenbezogene Daten)
Wichtig: Bisher ging es stark um personenbezogene Daten (DSGVO).
Betriebsgeheimnisse sind ein eigenes Schutzthema – mit ähnlichem Cloud-Risiko, aber anderen Pflichten.
Kurz in einfacher Sprache
- Personenbezogene Daten: Daten über Menschen (Name, E-Mail, Konto etc.) → DSGVO/TIA-Logik
- Betriebsgeheimnisse: Geheime Unternehmensinfos (Strategie, Quellcode, Preislogik, interne KPIs, Produkt-Roadmap) → GeschGehG + Verträge + Technik
Merksatz: Auch ohne DSGVO kann ein Leak schlimm sein – manchmal wirtschaftlich sogar schlimmer.
Rechtlicher Rahmen (DE/EU, pragmatisch)
| Thema | Was gilt typischerweise |
|---|---|
| GeschGehG (DE) | Schutz von Geschäftsgeheimnissen, wenn sie geheim + wirtschaftlich wertvoll + angemessen geschützt sind |
| DSGVO | Greift nur, wenn personenbezogene Daten betroffen sind |
| TIA | Primär DSGVO-Thema bei Drittlandtransfer personenbezogener Daten |
| Verträge (NDA/AV/Cloud-Vertrag) | Zentral für Betriebsgeheimnisse |
| EU Data Act (nicht-personenbezogene Daten) | Zusätzliche Schutzlogik gegen unzulässigen Zugriff Drittländer auf in EU gespeicherte nicht-personenbezogene Daten (je nach Konstellation) |
Ehrliche Einordnung: Bei reinen Betriebsgeheimnissen ohne Personenbezug ist die Diskussion weniger „TIA-Pflicht“, aber nicht risikofrei.
Gleiches US-Jurisdiktionsproblem wie bei M365/Bedrock?
Ja, grundsätzlich ähnlich.
Wenn vertrauliche Unternehmensdaten bei einem US-Hyperscaler liegen (M365, Bedrock, etc.), kann das Zugriffsrecht-Thema (CLOUD Act/FISA-Debatte) auch für nicht-personenbezogene Inhalte relevant sein.
| Beispiel-Inhalt | Personenbezug? | Typisches Risiko |
|---|---|---|
| Interne Produkt-Roadmap | meist nein | Betriebsgeheimnis |
| Kundensegment-Analyse ohne Namen | oft nein | Betriebsgeheimnis |
| Vertragstext mit Kundennamen | ja | DSGVO + Betriebsgeheimnis |
| Quellcode + Architekturdiagramm | meist nein | Betriebsgeheimnis / IP |
Was heißt das für AWS Bedrock konkret?
Szenario A: Prompt enthält nur Betriebsgeheimnisse (keine Personen)
- Keine klassische DSGVO-TIA-Pflicht nur deshalb
- Aber: hohes wirtschaftliches Schadenspotenzial
- Freigabe nur mit klarer Geheimhaltungsstrategie
Szenario B: Prompt mischt Betriebsgeheimnis + Personenbezug
- DSGVO und Geheimhaltung gelten parallel
- Strengere Gesamtbewertung
Szenario C: Hochkritische IP (z. B. Kernalgorithmus, M&A-Plan)
- Cloud-US-Hyperscaler oft unattraktiv
- eher On-Prem/Self-Hosted oder isolierte Private-Cloud-Strategie
Schutzmaßnahmen für Betriebsgeheimnisse (praxisnah)
- Datenklassifikation (öffentlich / intern / vertraulich / streng vertraulich)
- Need-to-know (nur berechtigte Rollen dürfen Prompts mit Top-Secret-Inhalten senden)
- Prompt-Hygiene (keine vollständigen Strategiepapiere ungefiltert)
- Redaction/Chunking (nur notwendige Ausschnitte statt Gesamtdokument)
- Region-/Netzwerk-Grenzen (EU-Region, PrivateLink, restriktive Policies)
- Vertragliche Absicherung (Geheimhaltung, Unterauftragnehmer, Audit-Rechte)
- Logging & Nachweis („angemessene Geheimhaltungsmaßnahmen“ nach GeschGehG)
- Human Review bei sensiblen Outputs
Vergleich: Mail vs. KI bei Betriebsgeheimnissen
| Situation | Risiko |
|---|---|
| M365-Mail mit vertraulicher Strategie-PDF | bereits heute vorhanden |
| Bedrock-Prompt mit gleicher Strategie-PDF | gleiches Grundrisiko, oft weniger etablierte Kontrollen |
| On-Prem Mailserver Frankfurt | geringeres Provider-Jurisdiktionsrisiko |
| Self-hosted Modell Frankfurt | geringeres Provider-Jurisdiktionsrisiko, mehr Betriebsaufwand |
Berater-Sprechsatz: „Auch ohne DSGVO kann ein Prompt teuer werden – Betriebsgeheimnisse brauchen dieselbe Disziplin wie Kundendaten.“
Mini-FAQ Betriebsgeheimnisse
F: Brauche ich für Betriebsgeheimnisse eine TIA? A: Nicht klassisch nach DSGVO, wenn keine personenbezogenen Daten betroffen sind. Aber du brauchst trotzdem eine dokumentierte Risiko- und Schutzentscheidung.
F: Sind Betriebsgeheimnisse weniger kritisch als personenbezogene Daten? A: Nicht automatisch. Für viele Firmen sind IP/Strategie wirtschaftlich kritischer.
F: Reicht EU-Region für Betriebsgeheimnisse? A: Hilft, reicht allein nicht – vor allem bei US-Mutter bleibt Jurisdiktionsdebatte.
F: Was ist der schnellste Schutz? A: Keine hochsensiblen Inhalte in den Prompt. Punkt.
Empfehlung für Policy (einfach)
Drei Zonen definieren:
- 🟢 Grün: allgemeine interne Infos, keine Geheimnisse
- 🟡 Gelb: vertrauliche Inhalte nur mit Freigabe + Kontrollen
- 🔴 Rot: streng vertrauliche Betriebsgeheimnisse nicht in US-Hyperscaler-GenAI
Damit wird die Diskussion konsistent für Personenbezug + Betriebsgeheimnisse.