Data Residency

Einfach erklärt

Data Residency bestimmt, wo Daten physisch oder logisch gespeichert und verarbeitet werden dürfen oder sollen.

Beispielhafte Residency-Anforderung:
Personenbezogene Daten → freigegebene Region ✓
Personenbezogene Daten → nicht geprüfte Drittregion ⚠️ zusätzliche Prüfung nötig

Technischer Deep Dive

Cloud-Regionen

Anbieter	Regionale Optionen
Cloud-Anbieter	wählbare Regionen und Availability Zones
SaaS-Anbieter	Datenresidenz- oder Tenant-Optionen je nach Vertrag
Self-Hosted	eigener Standort oder kontrollierte Infrastruktur

Terraform Beispiel

provider "cloud" {
  region = var.allowed_region
}

resource "storage_bucket" "regional_data" {
  bucket = var.bucket_name
  
  # Replikation nur in erlaubte Regionen konfigurieren
}

Wo Daten unbemerkt die Region verlassen

Die eigentliche Speicherung ist oft der einfachste Teil – kritischer sind die Nebenwege:

Datenweg	Typisches Risiko
Backups & Replikation	Standardmäßig regionsübergreifend konfiguriert
Logs & Monitoring	Telemetrie-Dienste speichern zentral, nicht regional
Support-Zugriffe	Anbieter-Support greift aus anderen Ländern zu
CDN & Caching	Inhalte werden an Edge-Standorten weltweit vorgehalten
SaaS-Subprozessoren	Dienstleister des Dienstleisters sitzen woanders

Data Residency erfordert deshalb eine vollständige Datenflussanalyse: Nicht nur “Wo liegt die Datenbank?”, sondern “Wohin fließen Kopien, Metadaten und Zugriffe?”.

Data Residency bei KI- und LLM-Diensten

KI-Anwendungen machen Residency-Fragen besonders anspruchsvoll:

• Inferenz ist Verarbeitung: Auch wenn ein LLM-Anbieter Prompts nicht dauerhaft speichert, findet die Verarbeitung in einer bestimmten Region statt. Wer personenbezogene Daten in Prompts einbettet, muss den Verarbeitungsort und die Transfermechanismen prüfen.
• Regionale Endpunkte nutzen: Viele LLM-Provider und Cloud-Plattformen bieten inzwischen regionale Inferenz-Endpunkte (etwa in der EU) an. Vertraglich zugesicherte Verarbeitungsregionen und Zero-Retention-Optionen sind zentrale Auswahlkriterien.
• RAG-Pipelines im Blick behalten: Vektordatenbanken, Embedding-Dienste und Dokumentenspeicher sind eigene Verarbeitungsorte – jede Komponente der Pipeline braucht eine Residency-Bewertung.
• Trainings- vs. Inferenzdaten: Ob Eingaben zum Modelltraining verwendet werden dürfen, ist eine separate vertragliche Frage – für Unternehmensdaten sollte dies ausgeschlossen sein.

Typische Stolperfallen

Fehler	Besser
Nur die Primärdatenbank regional festlegen	Auch Backups, Replikate, Logs und Caches einbeziehen
Residency mit Souveränität verwechseln	Prüfen, welchem Rechtsrahmen der Anbieter unterliegt – nicht nur, wo Server stehen
Einmalige Prüfung statt laufender Kontrolle	Policies technisch durchsetzen (z. B. Organisations-Policies, die Regionen einschränken)
Schatten-KI ignorieren	Mitarbeitende nutzen öffentliche KI-Tools ohne Residency-Prüfung – Richtlinien und freigegebene Alternativen schaffen
Vertragslage ungeprüft übernehmen	Auftragsverarbeitungsverträge, Subprozessor-Listen und Transfermechanismen aktiv prüfen

Abgrenzung zu verwandten Begriffen

• Data Sovereignty fragt, welches Recht auf die Daten anwendbar ist – ein Server in der EU nützt wenig, wenn der Betreiber ausländischen Zugriffsgesetzen unterliegt.
• Data Localization ist die strengste Form: Daten müssen per Gesetz im Land bleiben, wie es einige Staaten für bestimmte Datenkategorien vorschreiben.
• Datenschutz (DSGVO) regelt den Umgang mit personenbezogenen Daten insgesamt – Residency ist dabei nur ein Baustein neben Rechtsgrundlagen, Betroffenenrechten und Sicherheitsmaßnahmen.