GDPR-Datenresidenzkontrollen brauchen Nachweise

Eine EU-Regionsauswahl ist nützlich, beweist aber nicht, dass personenbezogene Daten in dieser Region bleiben. Käufer müssen jede Kopie und jede Person nachvollziehen, die darauf zugreifen kann: die aktive Datenbank, Objektspeicher, Protokolle, Sicherungen, Anfragen an Modellanbieter, Telemetrie und Support-Sitzungen. Verlässt nur ein Pfad die zugesagte Grenze, braucht die Residenzaussage einen Übermittlungsmechanismus und belastbare Nachweise.

Deshalb sollten GDPR-Datenresidenzkontrollen als Kette durchsetzbarer Tatsachen geprüft werden. Ein Bildschirmfoto der Konsole zeigt eine Einstellung. Es zeigt weder, was diese Einstellung umfasst, noch ob ein Administrator sie überschreiben kann oder was bei einem Vorfall geschieht. Der Einkauf sollte für jede wesentliche Aussage eine vertragliche Zusage, eine Systembeschreibung und einen wiederholbaren Test verlangen.

Dieser Artikel gibt Käufern einen praktischen Prüfmaßstab für KI-App-Builder. Er ersetzt keine Rechtsberatung zu einer bestimmten Übermittlung, Rechtsordnung oder Risikolage.

Die Regionsbindung muss jede Datenklasse definieren

Eine Regionsbindung ist nur glaubwürdig, wenn der Anbieter sowohl die geografische Grenze als auch die erfassten Daten definiert. "EU-Hosting" kann bedeuten, dass die primäre Datenbank in Frankfurt liegt, während Prompts an einen Modellendpunkt an einem anderen Ort gehen, Protokolle in einem globalen Analysedienst landen und Sicherungen regionsübergreifend repliziert werden. Die Bezeichnung sagt wenig aus, solange der Anbieter die Datenflüsse nicht abbildet.

Fordern Sie einen Datenstandortplan, der für jede Datenklasse das zulässige Land oder die zulässige Ländergruppe nennt. Er sollte mindestens Anwendungsdatensätze, hochgeladene Dateien, Prompts und Modellantworten, Embeddings, Geheimnisse, Authentifizierungsdaten, Protokolle, Metriken, Traces, Absturzberichte, Support-Anhänge und Sicherungen abdecken. Außerdem muss klar sein, ob "EU" die EU, den weiteren EWR oder eine vom Anbieter festgelegte Gruppe mit weiteren Ländern meint.

Die Kontrolle braucht einen eindeutigen Geltungsbereich. Gilt die gewählte Region für den Builder-Arbeitsbereich, die Produktionslaufzeit der erzeugten Anwendung oder für beides? Umfasst sie Vorschauumgebungen, Branch-Deployments, vorübergehende Build-Worker, Warteschlangen, Caches, Suchindizes, Auslieferungscaches und Wiederherstellungskopien? Ein App-Builder kann die fertige Datenbank in einer Region halten und Quellcode, Prompts sowie Build-Ergebnisse dennoch anderswo verarbeiten.

Verlangen Sie, dass der Anbieter Ausnahmen schriftlich benennt. Eine enge Ausnahme kann vertretbar sein, wenn der Käufer Daten, Zweck, Ziel, Aufbewahrungsdauer und Schutzmaßnahme kennt. Eine unbestimmte Klausel wie "Betriebsdaten können weltweit verarbeitet werden" entwertet die Zusage, weil Betriebsdaten häufig Benutzerkennungen, Anfragepfade, Prompt-Ausschnitte und Fehlernutzlasten enthalten.

Die besten Nachweise verbinden drei Ebenen. Vertrag oder Bestellformular nennen die zugesagte Region und das Änderungsverfahren. Architekturunterlagen ordnen jede Datenklasse einem Dienst und Standort zu. Ein technischer Datensatz, etwa eine API-Antwort oder ein Deployment-Eintrag, belegt die Einstellung für den eigenen Mandanten des Käufers.

Bitten Sie den Anbieter beispielsweise um einen Mandanteneintrag mit stabiler Struktur:

{
  "tenant_id": "acme-eu",
  "workspace_region": "eu-central",
  "runtime_region": "eu-central",
  "backup_regions": ["eu-central", "eu-west"],
  "support_access_policy": "eea_only",
  "effective_at": "2026-07-01T00:00:00Z"
}

Die Feldnamen unterscheiden sich je nach Produkt. Entscheidend ist, dass der Datensatz Arbeitsbereich, Laufzeit, Sicherung und Support-Richtlinie trennt, statt alles zu einem grünen "EU"-Hinweis zusammenzufassen. Fragen Sie, wer diese Werte ändern darf, ob der Käufer eine Änderung erkennt und was nach einem Umzug mit vorhandenen Kopien geschieht.

Sicherungen brauchen eine eigene Residenzzusage

Sicherungen müssen einer ausdrücklichen Richtlinie für Standort, Aufbewahrung, Löschung und Wiederherstellung folgen. Sie sind eigenständige Kopien mit eigener Infrastruktur, eigenen Zugriffswegen und eigener Lebensdauer. Ein Anbieter, der nur den Speicherort von "ruhenden Kundendaten" zusagt, hat seine Sicherungstresore, Snapshots oder Notfallreplikate womöglich nicht an dieselbe Grenze gebunden.

Fragen Sie nach dem Standort jeder Sicherungskopie, darunter Datenbank-Snapshots, Objektversionen, replizierte Volumes, Konfigurationssicherungen und vom Provider verwaltete Wiederherstellungskopien. Der Anbieter muss angeben, ob die Replikation in einem Land bleibt, zwischen EWR-Ländern erfolgt oder in ein Drittland führt. Eine Verfügbarkeitsarchitektur kann eine zweite Region rechtfertigen, macht deren Standort aber nicht bedeutungslos.

Angaben zur Aufbewahrung brauchen Zahlen und auslösende Ereignisse. Der Einkauf sollte die reguläre Aufbewahrungsdauer, längere Archivstufen, die Frist bis zur nicht mehr möglichen Wiederherstellung abgelaufener Medien und die Behandlung von Sicherungen nach Vertragsende kennen. "Löschung gemäß Richtlinie" ist nicht prüfbar. Ein Plan mit festgelegter Ablaufzeit für tägliche Wiederherstellungspunkte und einer Frist, nach der Sicherungen gekündigter Mandanten unzugänglich werden und auslaufen, lässt sich testen.

Logische Löschung und physisches Auslaufen unterscheiden sich. Ein gelöschter Datensatz kann in einer verschlüsselten Sicherung bleiben, bis der Wiederherstellungspunkt abläuft. Das kann zu einem dokumentierten Aufbewahrungskonzept passen. Der Anbieter sollte jedoch erklären, wie eine normale Wiederherstellung verhindert, dass gelöschte Daten unbemerkt wieder aktiv werden. Ausgereifte Verfahren spielen Löschmarkierungen erneut ein oder verlangen vor der Wiederinbetriebnahme einen Abgleich.

Fordern Sie einen aktuellen Nachweis über einen Wiederherstellungstest an, wobei sensible Angaben geschwärzt sein dürfen. Er sollte die Quellregion der Sicherung, das Wiederherstellungsziel, beteiligte Personen oder Dienstrollen, die Freigabe und die Beseitigung der wiederhergestellten Kopie nennen. Eine allgemeine Notfallrichtlinie beweist, dass jemand eine Richtlinie geschrieben hat. Ein Wiederherstellungsprotokoll beweist, dass der Betriebsprozess weiß, wohin die Kopie ging.

Verschlüsselung beseitigt die Standortfrage nicht. Sie kann das Risiko senken, besonders bei getrennten Schlüsseln und Verwaltungsrollen. Eine Sicherung in einem Drittland kann trotzdem eine Übermittlung sein, die einen gültigen Mechanismus und eine Bewertung braucht. Der Einkauf sollte Schlüsselinhaber, Schlüsselstandort, Wiederherstellungsrechte und den möglichen Klartextzugriff des Providerpersonals erfassen.

Eine Unterauftragsverarbeiterliste muss die wirkliche Kette zeigen

Ein brauchbares Register verbindet jedes Unternehmen mit Zweck, Datenkategorie, Verarbeitungsort und Übermittlungsgrundlage. Eine Liste von Logos oder juristischen Namen ist ein Inventar, keine Erklärung der Datenbewegung. KI-App-Builder hängen oft von Cloud-Hosting, Modellanbietern, Beobachtungsdiensten, E-Mail-Versand, Authentifizierung, Kundensupport und Missbrauchserkennung ab. Jede Rolle sieht einen anderen Ausschnitt.

Artikel 28 GDPR verlangt, dass ein Auftragsverarbeiter vor der Beauftragung eines weiteren Auftragsverarbeiters eine vorherige besondere oder allgemeine schriftliche Genehmigung einholt. Bei allgemeiner Genehmigung muss er den Verantwortlichen über geplante Ergänzungen oder Ersetzungen informieren, damit dieser widersprechen kann. Der Einkauf sollte daraus eine betriebliche Vorgabe machen: ein stabiles Register, Vorabhinweise über einen tatsächlich überwachten Kanal, eine festgelegte Frist und ein beschriebenes Widerspruchsverfahren.

Das Register sollte für jeden Unterauftragsverarbeiter fünf Punkte beantworten:

• die juristische Person, die Daten erhält oder darauf zugreifen kann
• den Dienst und den eng gefassten Verarbeitungszweck
• die Kategorien personenbezogener Daten und betroffenen Produktfunktionen
• die Länder der Speicherung und des Fernzugriffs
• den Übermittlungsmechanismus und den Weg weiterer Unteraufträge

Akzeptieren Sie bei einem Modelldienst nicht "Cloud-Infrastruktur" als Standort. Fragen Sie, ob Prompts an den Modellanbieter gehen, ob er sie aufbewahrt, ob Menschen sie prüfen dürfen und ob der Käufer einen Anbieter abschalten oder einen Endpunkt wählen kann. Nutzt der Builder mehrere Modelle, zählt die Routinglogik. Eine gewählte Projektregion kann eine Anfrage nicht kontrollieren, die der Router an einen nicht genehmigten Endpunkt sendet.

Eine Änderungsmitteilung muss vor dem Wirksamwerden eintreffen. Eine Webseite, die sich ohne Benachrichtigung ändern kann, zwingt den Einkauf zu dauernder manueller Überwachung. Der Vertrag sollte Inhalt der Mitteilung und Folgen eines begründeten Widerspruchs regeln. Der Anbieter muss keine unveränderliche Lieferkette versprechen, doch der Käufer braucht Zeit zur Bewertung, bevor Daten fließen.

Lassen Sie im Prüfverfahren drei Dinge abgleichen: das öffentliche Register, den DPA-Anhang und ein aktuelles Architektur- oder Datenflussdiagramm. Namen und Standorte weichen nach einem Anbieterwechsel oft voneinander ab. Eine Abweichung bedeutet nicht automatisch Kontrollversagen, aber ohne Aufklärung fehlt dem Käufer ein zuverlässiger Nachweis.

Der DPA muss Einstellungen zu Pflichten machen

Die Auftragsverarbeitungsvereinbarung sollte Verarbeitungsanweisungen, Sicherheitsaufgaben, Löschbedingungen, Prüfrechte und Unterauftragskontrollen für den gekauften Dienst festhalten. Produktdokumentation kann eine Funktion erklären. DPA und Bestelldokumente bestimmen jedoch, was der Anbieter diesem Käufer zugesagt hat.

Artikel 28 Absatz 3 GDPR nennt die Bestandteile eines Vertrags zwischen Verantwortlichem und Auftragsverarbeiter. Dazu gehören Gegenstand und Dauer, Art und Zweck, Datenarten, Kategorien betroffener Personen, Vertraulichkeit, Sicherheitsunterstützung, Löschung oder Rückgabe sowie Informationen zum Compliance-Nachweis. Die EDPB-Leitlinien 07/2020 warnen sinnvollerweise davor, die GDPR nur zu wiederholen. Die Vereinbarung soll konkret beschreiben, wie die Anforderungen erfüllt werden und welches Sicherheitsniveau gilt.

Diese Genauigkeit ist für Residenz wichtig. Fügen Sie einen Plan mit gewählten Regionen, erfassten Umgebungen, genehmigten Ländern für Fernzugriff, Sicherungsstandorten und zugelassenen Unterauftragsverarbeitern an. Der Anbieter darf diese Standorte nicht wesentlich erweitern, ohne das vereinbarte Mitteilungs- oder Änderungsverfahren einzuhalten. Verspricht der Vertrieb "nur EU", während der DPA Verarbeitung überall erlaubt, wo Anbieter oder verbundene Unternehmen arbeiten, gilt im Konfliktfall der Vertrag.

Prüfen Sie auch die Rollen. Bei Kundeninhalten, die nur nach Weisung zur Dienstbereitstellung genutzt werden, handelt der Anbieter meist als Auftragsverarbeiter. Für Abrechnung, Kontosicherheit, Betrugsbekämpfung oder eigene Rechtspflichten kann er eine eigene Verantwortlichenrolle beanspruchen. Lehnen Sie nicht jeden separaten Zweck pauschal ab. Verlangen Sie eine Benennung von Zweck, Datenkategorien, Rechtsgrundlage, Aufbewahrung und Weitergabe, statt ein breites Nutzungsrecht für sämtliche Dienstdaten zu akzeptieren.

KI-Training braucht eine eindeutige Klausel. Fragen Sie, ob Anbieter oder Modellprovider Prompts, Anwendungsdaten, Quellcode oder Ausgaben zum Training oder zur Verbesserung allgemeiner Modelle nutzen. Lautet die Antwort nein, gehört die Beschränkung in den DPA oder die maßgeblichen Produktbedingungen und muss auch Unterauftragsverarbeiter binden. Hängt die Antwort von einer Einstellung ab, dokumentieren Sie Standardwert, Administrator, Geltungsbereich und Prüfspur.

Prüfklauseln sollten brauchbare Nachweise ermöglichen, ohne unbeschränkten Zutritt zu einer mandantenfähigen Anlage zu verlangen. Unabhängige Prüfberichte, Zusammenfassungen von Penetrationstests, Sicherheitsunterlagen und gezielte schriftliche Antworten können Routineprüfungen abdecken. Der Käufer braucht einen Weg zu weiteren Informationen oder einer verhältnismäßigen Prüfung, wenn Unterlagen eine wesentliche Sorge nicht klären oder ein Vorfall die Kontrolle infrage stellt.

SCCs lösen nur den vertraglichen Teil einer Übermittlung

Standardvertragsklauseln können ein Instrument nach Artikel 46 bereitstellen. Ihre Unterschrift beweist jedoch nicht, dass jede Übermittlung rechtmäßig oder ausreichend geschützt ist. Käufer müssen das richtige Modul wählen, Anhänge ausfüllen, Weiterübermittlungen erfassen und beurteilen, ob die Klauseln für Ziel und Daten praktisch wirken.

Die SCCs der Europäischen Kommission von 2021 enthalten vier Module nach den Rollen der Parteien. Ein typischer EWR-Kunde, der Daten an einen Auftragsverarbeiter außerhalb des EWR sendet, kann Modul 2 verwenden. Ein Auftragsverarbeiter, der Daten an einen Unterauftragsverarbeiter in einem Drittland sendet, kann Modul 3 benötigen. Die Wahl hängt davon ab, wer exportiert, wer importiert und ob der Importeur für diese Verarbeitung bereits der GDPR unterliegt. Rechtsberater sollten die Kette bestätigen, statt Modul 2 in jeden Vertrag zu kopieren.

Ausgefüllte Anhänge sind Nachweise. Sie sollten Parteien, betroffene Personen, Datenkategorien, sensible Daten und Schutzmaßnahmen, Häufigkeit, Zweck, Aufbewahrung, zuständige Aufsichtsbehörde, technische und organisatorische Maßnahmen sowie Unterauftragsverarbeiter nennen. Leere Anhänge, allgemeine Angaben wie "alle Kundendaten" oder ein späteres Ausfüllversprechen lösen die Klauseln vom echten Dienst.

Die EDPB-Empfehlungen 01/2020 beschreiben sechs Schritte: Übermittlungen kennen, Instrument bestimmen, Recht und Praxis des Drittlands bewerten, nötige ergänzende Maßnahmen ergreifen, formelle Schritte erledigen und in angemessenen Abständen neu prüfen. Die Empfehlungen behandeln auch Fernzugriff aus einem Drittland als Übermittlung. Diesen Punkt übersehen Käufer, die nur auf die Speicherkarte schauen.

Eine Transferfolgenabschätzung sollte zum Dienst passen und kein allgemeines Rechtsmemorandum sein. Sie sollte Importeur und Ziel, Daten und Betroffene, Zugriffswege, geltendes Recht und Praxis, Risiko staatlichen Zugriffs, Weiterübermittlungen und ergänzende Maßnahmen festhalten. Dokumentieren Sie Genehmiger und Auslöser einer Neubewertung.

Verschlüsselung hilft nur, wenn ihr Entwurf das Zugriffsrisiko trifft. Muss ein Dienst Prompts für einen Supportmitarbeiter oder Modellendpunkt im Zielland entschlüsseln, hindert Transportverschlüsselung den Empfänger nicht am Lesen. Geeignete Ergänzungen können strikte Zugriffstrennung, Pseudonymisierung ohne Zuordnungsdaten beim Empfänger, kundengeführte Schlüssel für undurchsichtige Workloads, Zugriffsprotokolle sowie Pflichten zur Anfechtung oder Benachrichtigung im rechtlich zulässigen Rahmen sein.

Ein Angemessenheitsbeschluss kann den Rechtsweg für ein Ziel ändern, beseitigt aber weder die Pflicht, das Ziel zu kennen, noch die Kontrolle des Auftragsverarbeiters. Der Anbieter sollte angeben, welche Übermittlungen auf Angemessenheit und welche auf SCCs oder einem anderen Mechanismus beruhen. Diese Antwort gehört ins Transferinventar, nicht in den Pauschalsatz, der Anbieter "halte die GDPR ein".

Supportzugriff ist Verarbeitung am Standort der handelnden Person

Fernzugriff von außerhalb des EWR ist eine Datenübermittlung, wenn die handelnde Person personenbezogene Daten sehen kann, auch wenn die Datenbank ihre EU-Region nie verlässt. Behandeln Sie Supportstandort, Genehmigung und Sitzungsnachweise als Residenzkontrollen. Speicherort und menschlicher Zugriff beantworten verschiedene Fragen.

Der Anbieter sollte Routine-Support von privilegiertem Technikzugriff trennen. Ein Mitarbeiter der ersten Ebene braucht möglicherweise Kontometadaten, aber keine Produktionsinhalte. Ein Bereitschaftstechniker kann bei einem schweren Vorfall vorübergehend Zugriff benötigen. Jede Rolle sollte nur die geringste nötige Datenmenge für die kürzeste nötige Zeit erhalten, mit stärkerer Genehmigung für Produktion.

Verlangen Sie benannte Zugriffsländer oder eine durchsetzbare Regionsrichtlinie, nicht "globalen Rund-um-die-Uhr-Support" ohne Länderliste. Der Anbieter sollte Mitarbeiter, verbundene Unternehmen und Auftragnehmer mit möglichem Produktionszugriff, deren Arbeitsländer und den Mechanismus für jeden Weg außerhalb des EWR offenlegen. Kann Notfallzugriff eine Standortbeschränkung übergehen, dokumentieren Sie Auslöser, Genehmiger, Dauer und Kundenhinweis.

Testen Sie den Supportzugriff vor Freigabe oder in einem Pilotprojekt:

1. Erstellen Sie einen Testmandanten in der vertraglichen EU-Region und fügen Sie einen eindeutigen synthetischen Kundendatensatz hinzu.
2. Öffnen Sie einen Supportfall, der normalerweise eine Prüfung verlangt, ohne den Datensatz ins Ticket zu kopieren.
3. Lassen Sie sich Zugriffsantrag, Genehmiger, Land der handelnden Person, erteilte Rolle und Ablauf zeigen.
4. Prüfen Sie, ob das Sitzungsprotokoll Mandant, Aktion, Zeit und Grund erfasst, ohne sensible Inhalte ins Protokoll zu kopieren.
5. Widerrufen Sie den Zugriff und verlangen Sie den Nachweis, dass Rolle oder Sitzung den Mandanten nicht mehr erreichen.

Nutzen Sie synthetische Daten, weil ein Prüfungstest keine neue Offenlegung schaffen soll. Erwartet wird ein kleines Nachweispaket: Ticketkennung, Freigabeereignis, vorübergehende Berechtigung, Sitzungsereignisse und Widerruf. Kann der Anbieter in einem geteilten Dienst keinen Live-Test durchführen, fordern Sie ein aktuelles geschwärztes Muster und eine Erläuterung anhand der dokumentierten Kontrolle.

Auch Notfallzugriff braucht dieselbe Prüfung. Er darf normale Freigaben zur Wiederherstellung überspringen, niemals aber Identität, Protokollierung, Ablauf und nachträgliche Kontrolle. Fragen Sie, wie der Anbieter den Einsatz von Notfallrollen für gewöhnliche Fehlersuche verhindert und wie der Käufer davon erfährt.

Verlangen Sie nicht standardmäßig eine Bildschirmaufzeichnung. Sie kann eine weitere gehaltvolle Kopie personenbezogener Daten und Zugangsdaten schaffen. Strukturierte Ereignisse liefern oft bessere Nachweise bei geringerer Offenlegung: wer auf welchen Mandanten zugriff, aus welchem Land, unter welchem Ticket, mit welcher Rolle, wie lange und für welche Aktionskategorien.

Nachweise müssen Änderungen und Vorfälle überdauern

Der Einkauf sollte jeden Nachweis mit Verantwortlichem, Datum, Geltungsbereich und Aktualisierungsauslöser sammeln. Eine überzeugende Vertriebsantwort altert, wenn der Anbieter einen Modellprovider ergänzt, sein Supportteam verlagert, die Sicherungsarchitektur ändert oder eine Region startet. Nachweisverwaltung gehört zur Kontrolle.

Verwenden Sie im Freigabedatensatz eine Kontroll-Nachweis-Matrix. Jeder Eintrag erhält vier Felder: Aussage, Vertragsnachweis, technischer Nachweis und Aktualisierungsauslöser.

1. Für genehmigte Arbeitsbereichs- und Laufzeitregionen stehen Bestellformular und Standortplan neben Mandanteneintrag und Datenflusskarte. Nach einer Regions- oder Architekturänderung werden sie erneuert.
2. Für Sicherungsorte wird der Sicherungs- und Löschplan mit einem Wiederherstellungstest verbunden. Eine Änderung des Backup-Providers oder der Notfallarchitektur löst die Prüfung aus.
3. Für die Unterauftragskette steht die Genehmigungsklausel neben dem mit der Architektur abgeglichenen Register. Ergänzungs- oder Ersetzungshinweise lösen die Prüfung aus.
4. Für Drittlandtransfers stehen SCCs oder Angemessenheitsverweis neben Transferinventar und Bewertung. Ziel-, Rechts- oder Zugriffsänderungen lösen eine Prüfung aus.
5. Für Supportstandorte stehen der Zugriffsplan und Protokolle zu Freigabe, Sitzung und Widerruf zusammen. Neue Länder oder Rollen lösen die Aktualisierung aus.

Weisen Sie jede Zeile auf beiden Seiten einer Person zu. Der Verantwortliche des Anbieters beantwortet Änderungen und Nachweisanfragen. Der Verantwortliche des Käufers entscheidet, ob Datenschutz, Sicherheit, Technik oder Recht prüfen muss. Ein gemeinsames Postfach ohne zuständigen Prüfer ist keine betriebliche Kontrolle.

Definieren Sie Schwellenwerte für Hinweise. Ein neuer Unterauftragsverarbeiter, der nur Status-E-Mails sendet, kann eine leichtere Prüfung brauchen als ein Modellanbieter, der Prompts erhält. Ein neues Sicherungsland, ein zusätzlicher Supportstandort, eine geänderte Trainingsnutzung oder das Übergehen der Vertragsregion sollte neue sensible Deployments bis zur Bewertung stoppen.

Vorfallnachweise müssen zeigen, ob die Residenzgrenze hielt. Der Prozess des Anbieters sollte Regionskonfiguration, administrative Änderungen, Supportzugriffe, Exportereignisse und beteiligte Unterauftragsverarbeiter sichern. Der DPA regelt Mitteilung und Zusammenarbeit, während das Ablaufhandbuch die Datensätze benennt, die Speicher- und Sichtungsorte beantworten.

Zertifizierungen können diese Akte stützen, ersetzen aber keine dienstspezifischen Antworten. Ein Prüfbericht kann Zugriffsverwaltung und Sicherungskontrollen testen, ohne etwas über die für einen Mandanten gekauften Regionen zu sagen. Ordnen Sie Umfang und Ausnahmen der passenden Kontrolle zu und schließen Sie Lücken mit Vertrags- oder Mandantennachweisen.

Anforderungen sollten prüfbare Antworten erzeugen

Formulieren Sie Residenzanforderungen so, dass der Anbieter mit ja, nein oder nicht anwendbar antworten und einen benannten Nachweis anhängen kann. Breite Fragen führen zu breiten Zusicherungen. "Beschreiben Sie Ihren GDPR-Ansatz" ergibt mehrere glatte Seiten und kaum Freigabenachweise. Eine Anforderung mit Daten, Ort, Verhalten und Beleg deckt Lücken schneller auf.

Eine brauchbare Hostingvorgabe lautet: "Der Anbieter speichert und verarbeitet produktive Kundeninhalte, Prompts, erzeugten Quellcode und Authentifizierungsdaten nur in den in Anlage A aufgeführten Ländern, mit Ausnahme der in Anlage B aufgeführten Übermittlungen." Anlage A definiert die zulässige Grenze. Anlage B zwingt beide Seiten, Ausnahmen zu benennen, statt sich auf ein allgemeines Recht an anderer Stelle zu verlassen.

Nutzen Sie getrennte Anforderungen für getrennte Kontrollen. Diese Fragen eignen sich für Ausschreibung oder Sicherheitszusatz:

• Nennen Sie jede Dienstkomponente, die die gewählte Mandantenregion nicht übernimmt, samt Daten, Land, Zweck und Aufbewahrung.
• Nennen Sie alle Länder, aus denen Personal Produktionsinhalte erreichen kann, und fügen Sie den Freigabe- und Protokollierungsstandard bei.
• Geben Sie alle Sicherungs- und Notfallstandorte, Aufbewahrungsfristen, Löschereignisse und zulässigen Wiederherstellungsziele an.
• Legen Sie das aktuelle Unterauftragsregister vor und markieren Sie Empfänger von Prompts, Quellcode, Anwendungsdaten oder Support-Anhängen.
• Ordnen Sie jede Drittlandübermittlung einer Angemessenheit, einem SCC-Modul oder anderem Mechanismus zu und nennen Sie Prüfer und Prüfdatum.

Vermeiden Sie absolute Formulierungen, die die Architektur nicht sinnvoll erfüllen kann. "Keine Daten verlassen jemals Deutschland" könnte schon eine E-Mail an einen Administrator des Käufers im Ausland oder den Zugriff eines reisenden berechtigten Nutzers untersagen. Definieren Sie, ob die Vorgabe vom Anbieter gesteuerte Speicherung und Verarbeitung, Netzübertragung, Zugriff durch Benutzende des Käufers oder alles umfasst. Genauigkeit stärkt den Schutz, weil ein Verstoß erkennbar wird.

Trennen Sie Pflichtkontrollen vor Versand des Fragebogens von Wünschen. Ist Supportzugriff nur aus der EU zwingend, sagen Sie es und lehnen widersprechende Entwürfe ab. Ist er nur erwünscht, bewerten Sie einen dokumentierten Drittlandweg mit Instrument und Schutzmaßnahmen. Antworten werden unzuverlässig, wenn Käufer jede Frage als "kritisch" markieren und später die Hälfte in der Verhandlung aufgeben.

Verlangen Sie aktuelle Nachweise. Architekturdiagramme und Register brauchen ein Wirksamkeitsdatum. Vertragsanhänge sollten Dienstversion oder Angebot nennen. Betriebsbeispiele müssen aus der aktuellen Kontrolle stammen. Legen Sie Ablauf oder ereignisbezogene Prüfung für veränderliche Belege fest, während dauerhaft unterzeichnete Bedingungen bis zur Änderung gelten.

Machen Sie Konflikte sichtbar. Der Anbieter sollte jede Antwort kennzeichnen, die von einem höheren Tarif, einer optionalen Einstellung, einer Kundenhandlung oder einer geplanten Funktion abhängt. Der Einkauf kann die Voraussetzung in die Bestellung aufnehmen und an den Umsetzungsverantwortlichen übergeben. Eine einstellungsabhängige Kontrolle scheitert, wenn niemand weiß, wer sie einschalten muss.

Bewerten Sie die Aussage, nicht die Vertriebssprache

Ein Käufer kann die Residenzbereitschaft danach bewerten, ob jeder wesentliche Datenpfad drei Belegformen besitzt: bindende Zusage, aktuelle Systembeschreibung und mandantenspezifischen oder jüngsten Betriebsnachweis. Fehlt eine Ebene, entsteht eine genaue Rückfrage statt eines unklaren Streits über "GDPR-Konformität".

Verwenden Sie vier Entscheidungszustände:

• Verifiziert: Die Nachweise stimmen überein, umfassen den gekauften Dienst und werden aktualisiert.
• Bedingt genehmigt: Eine begrenzte Lücke hat Verantwortlichen, Termin und Ausgleichskontrolle.
• Beschränkt: Der Dienst verarbeitet nur Daten eines definierten risikoärmeren Einsatzes.
• Abgelehnt: Ein wesentlicher Transfer- oder Zugriffspfad bleibt unbekannt, unbegrenzt oder entgegen der Käuferanforderung vertraglich erlaubt.

Dieser Ansatz verhindert zwei schlechte Gewohnheiten. Die erste ist, einen globalen Anbieter allein wegen Personals außerhalb Europas abzulehnen, obwohl dieses den Mandanten nicht erreichen kann. Die zweite ist, ein "EU-gehostetes" Produkt ohne Prüfung von Modellrouting und Supportzugriff freizugeben. Die Rechtsordnungspräsenz liefert Kontext. Tatsächliche Datenflüsse und durchsetzbare Kontrollen bestimmen die Exposition.

Bewerten Sie die genaue gekaufte Ausgabe und Konfiguration. Kontrollen aus einer Enterprise-Präsentation fehlen möglicherweise in einem kostenlosen oder selbst bedienten Tarif. Die Region kann nur für die gehostete Produktion gelten, während Vorschauen oder Builder-Arbeitsbereich einem Standardstandort folgen. Halten Sie Voraussetzungen, Tarifgrenzen und Einstellungen in der Bestellung fest, damit Freigabe und Deployment übereinstimmen.

Koder.ai kann Anwendungen auf AWS-Infrastruktur in verschiedenen Ländern ausführen. Ein Käufer sollte das gewählte Land, die erfassten Komponenten und Zugriffswege trotzdem in seinem Nachweispaket verlangen. Die Produktfähigkeit eröffnet das Gespräch, der Beschaffungsnachweis schließt es.

Akzeptieren Sie keine Roadmap-Zusage für eine Kontrolle, die vor der ersten Verarbeitung personenbezogener Daten nötig ist. Eine Roadmap kann eine spätere Neubewertung stützen. Bis die Funktion existiert und der Anbieter sie binden, beschreiben und vorführen kann, beschränken Sie die Arbeitslast oder wählen einen anderen Entwurf.

Der Freigabedatensatz sollte mit dem Restrisiko enden, nicht mit einem Marketingurteil. Nennen Sie erlaubten grenzüberschreitenden Zugriff, Rechtsweg, betroffene Daten, ergänzende Maßnahmen und die Person, die das Risiko annahm. Damit erhält der Datenschutz eine vertretbare Akte und die Technik eine tatsächlich betreibbare Grenze.