KI-Datenschutz für Unternehmen in der EU: Was passiert mit Daten bei ChatGPT, Claude und AWS Bedrock?

Die häufigste Sorge lautet: „Wenn Mitarbeitende unsere Daten in ChatGPT oder Claude eingeben, kann dann ein anderes Unternehmen danach fragen und bekommt sie angezeigt?“ Bei einem passend eingerichteten Geschäftskonto lautet die praktische Antwort normalerweise: nein. OpenAI und Anthropic sagen für ihre kommerziellen Produkte ausdrücklich, dass Eingaben und Ausgaben standardmäßig nicht zum Training ihrer Modelle verwendet werden. Ein normaler Unternehmenschat wird dadurch nicht zu einer öffentlichen Website oder zu einer frei durchsuchbaren Wissensquelle.

Ganz risikolos ist die Nutzung trotzdem nicht. Eine Freigabe per öffentlichem Link, eine verbundene App, eine Browser-Aktion, ein falsch berechtigtes Projekt oder ein eigenes Protokollsystem kann Daten an andere Stellen bringen. Auch der Anbieter selbst muss Inhalte technisch verarbeiten und kann sie je nach Produkt für eine bestimmte Zeit speichern. Die richtige Frage ist daher nicht nur „Trainiert das Modell damit?“, sondern: Welche Daten verlassen welches System, wer kann sie erhalten, wie lange bleiben sie wo und welche Einstellung gilt tatsächlich?

Vier Fragen, die oft miteinander vermischt werden

Bei KI-Datenschutz hilft eine klare Trennung. „Kein Training“ beantwortet nur eine von mehreren Fragen:

• Verarbeitung: Welche Inhalte werden zur Beantwortung an den Dienst übermittelt und während der Berechnung verarbeitet?
• Speicherung: Bleiben Prompt, Antwort, Datei, Chatverlauf oder technische Protokolle nach der Antwort erhalten?
• Training: Darf der Anbieter diese Inhalte verwenden, um zukünftige allgemeine Modelle zu verbessern?
• Ort und Empfänger: In welcher Region findet Verarbeitung oder Speicherung statt, und erhalten Unterauftragnehmer, Integrationen oder Modellanbieter Daten?

Ein Dienst kann Inhalte beispielsweise 30 Tage für Missbrauchserkennung speichern, ohne sie für Training zu verwenden. Umgekehrt kann ein Chatverlauf dauerhaft im Benutzerkonto liegen, obwohl das Training deaktiviert ist. Diese Unterschiede sind für eine echte Risikobewertung wichtiger als ein einzelnes Datenschutz-Schlagwort.

Welche Daten gehen überhaupt an ein KI-Modell?

Das Modell braucht den Inhalt, aus dem es eine Antwort erzeugen soll. Je nach Produkt kann mehr dazugehören als der Text im letzten Eingabefeld:

• der aktuelle Prompt und die erzeugte Antwort;
• relevante Teile des bisherigen Gesprächs;
• hochgeladene Dokumente, Bilder, Audio oder Tabellen;
• Systemanweisungen, benutzerdefinierte Anweisungen und gespeicherte Erinnerungen;
• Inhalte, die über Google Drive, SharePoint, GitHub, MCP, Websuche oder andere Connectors in den Kontext geholt werden;
• bei agentischen Werkzeugen zusätzlich Bildschirminhalte, Dateien, Werkzeugergebnisse oder Daten aus geöffneten Anwendungen;
• technische Metadaten wie Konto, Zeitpunkt, verwendetes Modell, Tokenmenge, IP- oder Geräteinformationen – abhängig vom jeweiligen Dienst.

Das erklärt auch, warum „Ich habe nur einen harmlosen Satz eingegeben“ nicht immer die ganze Datenmenge beschreibt. Wenn Memory, Chatverlauf oder ein Connector aktiv ist, kann das Produkt zusätzlichen Kontext verwenden. Bei einer selbst entwickelten API-Anwendung kommen außerdem die eigene Datenbank, Protokolle, Fehlerüberwachung und der Hosting-Anbieter hinzu.

OpenAI: Privatkonto, Business und Enterprise sind nicht dasselbe

Bei privaten ChatGPT-Konten kann OpenAI Unterhaltungen zur Verbesserung seiner Modelle verwenden. Das lässt sich unter Einstellungen → Datenkontrollen → „Das Modell für alle verbessern“ ausschalten. Die Einstellung gilt laut OpenAI danach für das Konto auf allen Geräten. Für betriebliche Inhalte sollte sie bei persönlichen Konten jedenfalls deaktiviert sein. Besser ist ein vom Unternehmen verwalteter Workspace.

ChatGPT Plus oder Pro sind trotz Bezahlung persönliche Tarife. Ein privates Abo wird nicht dadurch zu einem Geschäftskonto, dass es für die Arbeit bezahlt wurde. ChatGPT Business, Enterprise und Edu sowie die OpenAI API fallen dagegen unter die geschäftlichen Datenschutzbedingungen. OpenAI verwendet deren Ein- und Ausgaben standardmäßig nicht für Training oder Modellverbesserung.

Auch in einem Business-Workspace hat jede Person ihren eigenen Chatverlauf. OpenAI speichert normale Chats grundsätzlich, bis sie gelöscht werden. Nach dem Löschen sind sie sofort aus dem Konto entfernt und laut Chat- und Datei-Aufbewahrungsregeln für die endgültige Löschung innerhalb von 30 Tagen vorgesehen, abgesehen von bereits de-identifizierten Inhalten sowie Sicherheits- oder Rechtspflichten. Archivieren ist keine Löschung.

Chatverlauf, Dateien und Memory sind eigene Speicherorte

Training zu deaktivieren löscht keinen Chat. Auch Memory sollte getrennt betrachtet werden. ChatGPT kann gespeicherte Erinnerungen und – wenn aktiviert – Informationen aus früheren Unterhaltungen für neue Antworten heranziehen. Eine gespeicherte Erinnerung liegt getrennt vom ursprünglichen Chat. Wer eine Information vollständig entfernen möchte, muss deshalb unter Umständen sowohl den Chat als auch die Erinnerung oder andere Quellen wie Dateien und verbundene Apps löschen. OpenAI beschreibt diese Trennung in der Memory-Dokumentation.

Für einzelne sensible Aufgaben gibt es „Temporäre Chats“. Sie erscheinen nicht im Verlauf, erzeugen keine Erinnerungen und werden nicht für das Training verwendet. OpenAI kann dennoch für Sicherheitszwecke bis zu 30 Tage eine Kopie behalten. Sobald ein benutzerdefiniertes GPT eine externe Aktion ausführt oder Daten an eine Drittanbieter-App übermittelt, gelten zusätzlich deren Speicher- und Datenschutzregeln.

Bei ChatGPT Enterprise können Administratoren Aufbewahrungsregeln und Compliance-Funktionen verwalten. Das ist nützlich, aber keine Aufforderung, pauschal alles sofort zu löschen. Manche Unternehmen brauchen einen nachvollziehbaren Verlauf für interne Kontrollen; andere müssen Daten möglichst kurz halten. Die Frist sollte zum Zweck, zu gesetzlichen Pflichten und zur internen Informationsklassifizierung passen.

OpenAI API: kein Training, aber standardmäßig Sicherheitsprotokolle

Daten, die über die OpenAI API gesendet werden, werden standardmäßig nicht zum Training verwendet. Laut aktueller API-Dokumentation zu Datenkontrollen können Missbrauchsprotokolle jedoch Kundeninhalte wie Prompts und Antworten enthalten und grundsätzlich bis zu 30 Tage gespeichert werden. Manche API-Funktionen speichern zusätzlich Anwendungszustand, etwa Dateien, Conversations, Threads oder Vector Stores, bis sie aktiv gelöscht werden.

Für berechtigte Kunden bietet OpenAI „Modified Abuse Monitoring“ oder „Zero Data Retention“ an. Das muss beantragt und passend konfiguriert werden. Zero Data Retention ist außerdem keine pauschale Zusage für jede Funktion: Bestimmte Endpunkte oder Werkzeuge benötigen Anwendungszustand oder sind mit ZDR nicht kompatibel. Eine API-Architektur sollte daher endpointweise dokumentieren, was gespeichert wird.

Anthropic: Claude Pro ist kein Claude-Teamkonto

Auch bei Anthropic muss zwischen Konsumenten- und Geschäftstarifen unterschieden werden. Claude Free, Pro und Max sind persönliche Produkte. Nutzer können in den Datenschutzeinstellungen festlegen, ob neue oder fortgesetzte Chats und Coding-Sitzungen zur Verbesserung von Claude verwendet werden dürfen. Wer diese Freigabe erteilt, muss laut Anthropic mit einer Aufbewahrung de-identifizierter Trainingsdaten von bis zu fünf Jahren rechnen. Gelöschte Chats werden nicht für zukünftiges Training verwendet; bereits laufende Trainingsläufe oder bereits trainierte Modelle lassen sich dadurch naturgemäß nicht zurückdrehen.

Für Claude for Work, Team, Enterprise und die Anthropic API gilt dagegen: Anthropic verwendet Eingaben und Ausgaben standardmäßig nicht zum Modelltraining. Ausnahmen bestehen, wenn ein Kunde ausdrücklich Daten freigibt oder Feedback beziehungsweise einen Fehlerbericht sendet. Beim Daumen-hoch-/Daumen-runter-Feedback kann die gesamte zugehörige Unterhaltung gespeichert und zur Verbesserung verwendet werden. In verwalteten Workspaces lässt sich diese Feedback-Funktion administrativ deaktivieren.

Für die Anthropic API werden Eingaben und Ausgaben standardmäßig innerhalb von 30 Tagen aus den Backend-Systemen gelöscht, sofern keine längere kundengesteuerte Funktion, eine abweichende Vereinbarung, eine Richtlinienprüfung oder eine gesetzliche Pflicht greift. In Claude for Work bleiben gespeicherte Chats für die Produktfunktion erhalten, bis sie gelöscht werden. Bei Claude Enterprise können Eigentümer eine eigene Aufbewahrungsdauer ab 30 Tagen festlegen; ohne eigene Einstellung ist die Aufbewahrung derzeit unbefristet.

Der Sonderfall Claude Fable 5

Claude Fable 5 ist ein gutes Beispiel dafür, warum Unternehmen nicht nur den Anbieter, sondern auch das konkrete Modell prüfen müssen. Anthropic führt Fable 5 derzeit als „Covered Model“ mit besonderen Sicherheitsregeln. Prompts und Modellantworten werden auf allen angebotenen Plattformen grundsätzlich 30 Tage aufbewahrt, um komplexe Missbrauchsmuster und Jailbreaks zu erkennen. Bei einer Sicherheitsuntersuchung oder gesetzlichen Pflicht kann eine längere Aufbewahrung nötig sein. Laut Anthropic werden diese Daten nicht zum Training neuer Claude-Modelle und nicht für andere Zwecke als Sicherheit verwendet. Menschlicher Zugriff ist für Sicherheitsprüfungen möglich und soll protokolliert werden.

Der Hintergrund sind vor allem besonders leistungsfähige Fähigkeiten in Bereichen wie Cybersecurity und Biologie. Automatische Klassifikatoren prüfen Anfragen und Ausgaben. Bei Fable können bestimmte Anfragen blockiert oder von einem anderen Modell beantwortet werden. Anthropic begründet die 30-Tage-Frist damit, dass Angriffe oft erst als Muster über viele einzelne Anfragen sichtbar werden. Das ist keine versteckte Trainingsfreigabe, aber sehr wohl eine bewusste Ausnahme von Zero Data Retention.

Diese Ausnahme gilt auch bei Nutzung über Amazon Bedrock. AWS verlangt für Fable eine ausdrückliche Konfiguration für Datenweitergabe an den Modellanbieter. Danach werden Prompts und Antworten bis zu 30 Tage gespeichert und für Missbrauchserkennung sowie mögliche menschliche Prüfung an Anthropic geteilt. Anthropic erklärt für seine kommerziellen Dienste derzeit, dass Kundendaten in den USA gespeichert werden. Deshalb kann ein Fable-Aufruf selbst dann einen Datenfluss in die USA auslösen, wenn die eigentliche Modellberechnung über eine europäische AWS-Konfiguration gestartet wurde.

Wer diese Weitergabe nicht akzeptieren kann, sollte Fable nicht für diesen Datenbestand verwenden und ein Modell wählen, das mit Zero Data Retention kompatibel ist. AWS blockiert Fable-Aufrufe, wenn das Konto oder Projekt auf ZDR steht und die notwendige Datenweitergabe nicht erlaubt wurde. Die AWS-Aufbewahrungsdokumentation macht diese Abweichung ausdrücklich sichtbar.

AWS Bedrock: Modelle nutzen, ohne Daten standardmäßig an den Modellanbieter zu geben

Amazon Bedrock ist kein persönliches Chat-Abo, sondern ein AWS-Dienst, über den Unternehmen Modelle verschiedener Anbieter in eigene Anwendungen einbauen. Für viele Modelle arbeitet Bedrock standardmäßig mit „Zero Operator Access“ und „Zero Data Retention“: AWS-Mitarbeitende können Modell-Ein- und -Ausgaben nicht einsehen, und Bedrock speichert sie standardmäßig nicht dauerhaft. Retained Inputs werden grundsätzlich nicht mit dem Drittanbieter des Modells geteilt, außer der Kunde stimmt einer solchen Weitergabe ausdrücklich zu. Fable ist die oben beschriebene wichtige Ausnahme.

Fable ist derzeit nicht die einzige dokumentierte Abweichung von der allgemeinen Bedrock-Regel. Bei OpenAI GPT-5.4 und GPT-5.5 kann AWS vom Klassifikator markierte Ein- und Ausgaben bis zu 30 Tage für automatisierte Missbrauchserkennung speichern. AWS teilt diese Daten nicht automatisch mit OpenAI. Berechtigte Kunden können laut AWS für diese Modelle vollständiges ZDR über ihr Account-Team anfragen. Welche Regel gilt, muss daher für jede verwendete Modellversion geprüft werden.

Bedrock bietet drei technisch unterschiedliche Möglichkeiten für den Ort der Berechnung:

• Single Region: Die Anfrage wird vollständig in der ausgewählten AWS-Region verarbeitet. Das ist die strengste regionale Auswahl, sofern das gewünschte Modell dort verfügbar ist.
• Geografisches EU-Inference-Profil: Bedrock darf die Anfrage zwischen den im EU-Profil festgelegten AWS-Regionen routen, aber nicht außerhalb dieser Geografie.
• Globales Inference-Profil: Bedrock kann weltweit in unterstützte kommerzielle AWS-Regionen routen. Das bringt mehr Kapazität, passt aber nicht zu einer Vorgabe „Verarbeitung nur in der EU“.

AWS weist darauf hin, dass Prompts und Antworten bei geografischem Cross-Region Inference innerhalb der gewählten Geografie bewegt werden können. Bei globalen Profilen gibt es keine entsprechende regionale Beschränkung. Unternehmen sollten deshalb nicht nur „eu-central-1“ im Konto sehen, sondern auch die tatsächlich aufgerufene Modell-ID und das verwendete Inference-Profil prüfen.

Ein weiterer oft übersehener Punkt liegt im eigenen AWS-Konto: Das Bedrock Model Invocation Logging ist standardmäßig aus. Wenn es aktiviert wird, können vollständige Prompts, Antworten und Metadaten in CloudWatch Logs oder S3 landen. Dann bestimmt die eigene Log-Konfiguration, Verschlüsselung, Berechtigung und Aufbewahrungsfrist einen wesentlichen Teil des Datenschutzes. EU-Verarbeitung beim Modell nützt wenig, wenn eine Anwendung denselben Prompt gleichzeitig in einem globalen Fehlerdienst protokolliert.

OpenAI bietet inzwischen ebenfalls europäische Daten- und Inferenzresidenz

AWS Bedrock ist nicht der einzige Weg zu regionaler Verarbeitung. OpenAI bietet für neue, berechtigte ChatGPT-Enterprise- und Edu-Workspaces Datenresidenz in Europa – definiert als EWR plus Schweiz – und für unterstützte Workloads auch Inferenzresidenz in dieser Region. Darunter fallen laut OpenAI unter anderem Gespräche, Dateien, Memory, benutzerdefinierte GPTs und bestimmte Analyse-Artefakte. Die OpenAI API unterstützt für berechtigte Kunden regionale Speicherung und Verarbeitung über den europäischen API-Endpunkt.

Auch diese Zusage hat Grenzen. OpenAI hält ausdrücklich fest, dass Accountdaten, Abrechnung, Nutzungsstatistiken, Workspace-Metadaten und bestimmte nicht GPU-basierte Verarbeitung außerhalb der Region liegen können. Apps, Websuche, MCP-Server und andere externe Integrationen folgen ihren eigenen Bedingungen. Datenresidenz bedeutet daher nicht „kein einziges Byte verlässt jemals Europa“, sondern eine genau definierte Standortzusage für bestimmte Kundeninhalte und Verarbeitungsschritte.

EU-Datenschutz: Ein EU-Server allein reicht nicht

Sobald personenbezogene Daten verarbeitet werden, bleibt die DSGVO anwendbar. Die österreichische Datenschutzbehörde weist ausdrücklich darauf hin, dass für die Verarbeitung zumindest eine Rechtsgrundlage nach Artikel 6 DSGVO erforderlich ist; bei sensiblen Daten gelten zusätzlich die Anforderungen des Artikels 9.

Für Unternehmen ergeben sich daraus praktische Prüfungen:

• Ist der Zweck der KI-Nutzung klar und gibt es eine passende Rechtsgrundlage?
• Werden nur die wirklich notwendigen personenbezogenen Daten übermittelt?
• Gibt es einen Auftragsverarbeitungsvertrag, eine aktuelle Liste der Unterauftragsverarbeiter und passende technische Maßnahmen?
• Welche Übermittlungsgrundlage gilt für Datenflüsse außerhalb des EWR, etwa Angemessenheitsbeschluss oder Standardvertragsklauseln?
• Muss die Verarbeitung im Verzeichnis von Verarbeitungstätigkeiten ergänzt oder bei hohem Risiko eine Datenschutz-Folgenabschätzung durchgeführt werden?
• Wie können Auskunft, Berichtigung und Löschung praktisch erfüllt werden?

Die Europäische Kommission nennt für Drittlandtransfers mehrere zulässige Instrumente, darunter Angemessenheitsbeschlüsse und Standardvertragsklauseln. Ob ein konkreter Einsatz zulässig ist, hängt trotzdem von Daten, Zweck, Vertrag, Empfängern und Schutzmaßnahmen ab. „Server in Frankfurt“ ist ein hilfreicher Baustein, aber keine vollständige DSGVO-Prüfung.

Reine Unternehmensgeheimnisse ohne Personenbezug fallen nicht automatisch unter die DSGVO. Sie können dennoch geschäftskritisch sein. Vertraulichkeitsvereinbarungen, Geschäftsgeheimnisschutz, Berufsgeheimnisse, Kundenverträge oder interne Sicherheitsvorgaben können strengere Grenzen setzen als das Datenschutzrecht.

Eine sinnvolle Risikostaffelung für den Alltag

Nicht jeder Prompt braucht dieselbe technische Lösung. Eine einfache Staffelung verhindert sowohl Leichtsinn als auch unnötige Angst:

• Niedriges Risiko: öffentliche Informationen, allgemeine Formulierungshilfe, erfundene Beispieldaten. Ein freigegebenes Standardwerkzeug reicht oft.
• Mittleres Risiko: interne Prozessbeschreibungen, Entwürfe, nicht öffentliche Kennzahlen. Geschäftskonto, klare Regeln, begrenzte Aufbewahrung und Entfernung unnötiger Details.
• Hohes Risiko: Kundenakten, Beschäftigtendaten, Gesundheitsdaten, Zugangsdaten, vollständige Verträge, Quellcode mit Geheimnissen. Nur nach dokumentierter Prüfung, mit geeigneter Rechtsgrundlage, minimalen Daten, strengem Zugriff und passender technischer Architektur.
• Nicht eingeben: Passwörter, API-Schlüssel, private Schlüssel und Daten, für deren Verarbeitung weder Berechtigung noch klarer Zweck besteht.

Oft reicht Pseudonymisierung: Namen durch Fallnummern ersetzen, irrelevante Spalten entfernen, nur den benötigten Vertragsabschnitt senden oder mit synthetischen Testdaten beginnen. Das ist meist wirksamer als eine lange Richtlinie, die im Alltag niemand anwenden kann.

Praktische Mindestmaßnahmen für OpenAI und Anthropic

• Keine betrieblichen Daten in unverwalteten Privatkonten verarbeiten.
• Bei privaten Konten die Modellverbesserung deaktivieren und Trainingseinstellungen regelmäßig prüfen.
• Business-, Team- oder Enterprise-Workspace mit zentraler Benutzerverwaltung, MFA beziehungsweise SSO und geregeltem Offboarding verwenden.
• Chatverlauf, Memory, Dateien, Projekte, Feedback und Connectors als getrennte Datenbestände behandeln.
• Aufbewahrungsfrist bewusst festlegen; Archivieren nicht mit Löschen verwechseln.
• Öffentliche Freigabelinks und unkontrollierte GPTs, Apps oder MCP-Verbindungen einschränken.
• Für APIs sowohl Anbieterprotokolle als auch eigene Logs, Datenbanken, Caches und Backups dokumentieren.
• Bei EU-Vorgaben Speicherung, Inferenz, Metadaten, Supportzugriff und Drittanbieter separat prüfen.
• Besondere Modelle wie Claude Fable 5 nicht unter die allgemeinen Anbieterregeln subsumieren.
• Mit Datenklassen und konkreten Beispielen schulen: Was ist erlaubt, was braucht Freigabe, was bleibt verboten?

Welche Lösung passt zu welchem Unternehmen?

Ein kleines Team mit normalen Bürodaten ist häufig mit ChatGPT Business oder Claude Team gut bedient, wenn Training ausgeschlossen, Konten zentral verwaltet und sensible Datenklassen klar geregelt werden. Nicht jeder Betrieb braucht sofort eine eigene Cloud-Architektur.

Ein Unternehmen mit strenger Aufbewahrung oder EU-Standortvorgabe sollte Enterprise-Angebote mit konkreten Retention- und Residency-Zusagen oder eine API-Architektur prüfen. OpenAI Enterprise mit europäischer Daten- und Inferenzresidenz kann passend sein. AWS Bedrock kann eine noch gezieltere Auswahl von Region, Modell, Logging und ZDR ermöglichen.

Ein stark regulierter oder besonders sensibler Anwendungsfall braucht eine technische und rechtliche Einzelfallprüfung. Möglich sind Pseudonymisierung vor dem Modellaufruf, ZDR-fähige API-Endpunkte, EU-only Routing, eigene Verschlüsselungs- und Logging-Regeln oder ein lokal beziehungsweise in eigener Infrastruktur betriebenes Modell. Ein lokales Modell ist allerdings nicht automatisch sicher: Betrieb, Updates, Zugriffe und Protokolle bleiben die eigene Verantwortung.

Fazit: Die Daten werden nicht automatisch öffentlich – aber die Konfiguration entscheidet

Die pauschale Angst, jede Eingabe in ChatGPT oder Claude lande sofort im Internet, trifft die übliche Nutzung eines korrekt eingerichteten Geschäftskontos nicht. OpenAI und Anthropic trainieren ihre allgemeinen Modelle standardmäßig nicht mit Geschäftskundendaten. AWS Bedrock bietet für viele Modelle zusätzlich eine Architektur ohne dauerhafte Speicherung und ohne Weitergabe der Prompts an den Modellanbieter.

Genauso falsch wäre die Aussage, damit sei Datenschutz erledigt. Chats können im Verlauf bleiben, Memory kann Informationen getrennt speichern, APIs führen Sicherheitsprotokolle, Connectors schaffen neue Datenflüsse und einzelne Modelle haben Sonderregeln. Claude Fable 5 zeigt das besonders deutlich: kein Training, aber verpflichtende 30-Tage-Aufbewahrung und mögliche Sicherheitsprüfung – auch über Bedrock.

Eine gute Unternehmenslösung besteht deshalb aus drei Teilen: dem passenden Vertrag und Tarif, einer nachvollziehbaren technischen Konfiguration und einfachen Regeln für Mitarbeitende. Dann lässt sich generative KI produktiv nutzen, ohne bei jeder internen Information entweder sorglos oder grundsätzlich ablehnend zu reagieren.

Offizielle Quellen und weiterführende Dokumentation

• OpenAI: Datenschutz für Geschäftsdaten
• OpenAI: Daten- und Inferenzresidenz für ChatGPT
• OpenAI API: Datenkontrollen und Aufbewahrung nach Endpunkt
• Anthropic: Training mit Geschäftskundendaten
• Anthropic: Aufbewahrung von Organisationsdaten
• Anthropic: Aufbewahrung bei Covered Models wie Fable 5
• AWS: Missbrauchserkennung und Ausnahmen von ZDR in Bedrock
• AWS: geografisches Cross-Region Inference
• Datenschutz-Grundverordnung im Wortlaut