Databricks Clean Rooms: Gemeinsame Analysen ohne Rohdaten teilen

Eine Werbeplattform möchte wissen, wie stark sich ihre Zielgruppe mit den eigenen Kunden überschneidet. Eine Tochtergesellschaft soll zu einer Konzernkennzahl beitragen, darf ihre Kundendaten aber nicht zentral abgeben. Ein Forschungspartner benötigt zusammengefasste Auswertungen zu Patientengruppen. Häufig folgt darauf derselbe Ansatz: Daten exportieren, Vertrag unterschreiben und Dateien austauschen.

Dieses Muster wiederholt sich, sobald eine Kollaborations-Anfrage konkret wird. Jeder beteiligte Anbieter empfiehlt zunächst die eigene Lösung, der Datenschutz fragt, was das technisch bedeutet, die Geschäftsleitung fragt, was es vertraglich heißt, und am Ende entsteht häufig eine zusätzliche abgeschottete Umgebung mit kopierten Datensätzen. Die Originaldaten werden an eine andere Organisation oder Umgebung übertragen, später lässt sich nur schwer nachvollziehen, wie das Ergebnis entstanden ist, und technische Kontrollen und Verantwortlichkeiten bleiben dabei häufig unzureichend geregelt.

Vor jeder Kollaboration stehen vier Fragen im Raum:

Welche Daten dürfen überhaupt an die andere Partei übermittelt werden? Welches konkrete Ergebnis benötigen die Beteiligten, und genügen dafür zusammengefasste Kennzahlen statt einzelner Datensätze? Welche technische Plattform nutzt der Partner und lässt sie sich sinnvoll anbinden? Wer ist verantwortlich, wenn sich aus den Ergebnissen einzelne Personen wieder erkennen lassen?

Ein NDA beantwortet diese technischen und datenschutzrechtlichen Fragen nicht. Sie klären auch keine Datentreuhand-Konstrukte, die nur die Rohdaten in eine neutrale Hand verschieben. Dafür braucht es eine abgeschottete Ausführungsumgebung, in der nur vorher festgelegte Ergebnisse herausgegeben werden.

Vier typische Situationen können den zusätzlichen Aufwand rechtfertigen. Für einfachere Fälle reicht meist eine normale Datenfreigabe.

Zielgruppenabgleich mit Werbeplattformen. Eine Werbeplattform will den Audience-Overlap mit den eigenen Kunden auswerten, um Werbekampagnen für gemeinsame Zielgruppen planen. Rohdaten dürfen nicht ausgetauscht werden, aber Die Größe gemeinsamer Zielgruppen und zusammengefasste Merkmale müssen abrufbar sein. Der Clean Room vergleicht geschützte Kundenkennungen und gibt nur zusammengefasste Ergebnisse aus.

Gemeinsames Training eines Modells. Zwei Unternehmen wollen ein Modell trainieren, für das beide Unternehmen Daten beisteuern, etwa ein Risikomodell aus Bank- plus Telco-Daten. Der Clean Room hält beide Trainings-Datasets in der isolierten Umgebung, das Modell wird dort trainiert, und nur das gemeinsam freigegebene Modell wird anschließend herausgegeben.

Gemeinsame Konzernkennzahlen ohne zentrale Rohdatensammlung. Eine Holding will eine Konzern-KPI berechnen, die Tochtergesellschaften dürfen ihre vollständigen Kundendaten nicht an die Holding übertragen, etwa wegen lokaler Aufsicht, vertraglicher Bindung oder gewachsener Trennung. Jede Tochter gibt nur die für die Berechnung benötigten Daten für die geschützte Auswertung frei, die Konzern-Auswertung läuft auf der kombinierten Sicht, und an die Holding wird nur die vereinbarte Kennzahl ausgegeben.

Gemeinsame Forschung mit sensiblen Daten. Klinische Daten, Pharma-Studien-Daten oder Behörden-Daten brauchen häufig aggregierte Auswertungen über Kohorten, ohne dass Forschende direkten Zugriff auf die Patientendaten erhalten. Der Clean Room hält die Daten am Ursprung, die Forschenden reichen ihre Auswertungslogik zur Prüfung ein, und nur geprüfte Ergebnisse dürfen die Umgebung verlassen.

Gemeinsam ist allen Fällen: Die Originaldaten bleiben geschützt, und nur klar festgelegte Ergebnisse werden geteilt.

Am einfachsten ist die Zusammenarbeit, wenn beide Parteien Databricks mit Unity Catalog nutzen (Azure, AWS, GCP). Beide Seiten stellen Daten bereit und stimmen der Auswertungslogik zu. Je nach aktuellem Funktionsumfang können auch mehrere Parteien beteiligt werden. Vor dem Aufbau sollte geprüft werden, welche Funktionen in der jeweiligen Cloud und Region tatsächlich verfügbar sind.

Aufwendiger wird es, wenn eine beteiligte Partei Databricks nicht nutzt. Sie können über offene Delta-Sharing-Schnittstellen angebunden werden. Dabei stehen jedoch möglicherweise nicht alle Freigabe- und Kontrollfunktionen zur Verfügung; die volle Output-Kontrolle setzt voraus, dass beide Seiten innerhalb der Databricks-Clean-Room-Mechanik arbeiten.

Bei der Auswahl sind vor allem zwei Fragen wichtig: Welche Plattformen nutzen die Beteiligten, und wie stark müssen die Ergebnisse kontrolliert werden?

Eine erste Einordnung ist vergleichsweise klar. Nutzen beide Parteien Databricks, lässt sich die Databricks-Lösung am einfachsten in Berechtigungen, Lineage und Audit integrieren. Nutzt der Partner überwiegend Snowflake oder AWS, kann die dort native Lösung weniger Integrationsaufwand verursachen. Wenn mehrere unterschiedliche Plattformen beteiligt sind oder keine Partei die technische Umgebung kontrollieren soll, können plattformunabhängige Anbieter besser geeignet sein.

Mindestgrößen verhindern, dass Ergebnisse für sehr kleine Personengruppen ausgegeben werden, aus denen Einzelpersonen rekonstruierbar wären. Dies ist eine vergleichsweise einfache Schutzmaßnahme und für viele Anlässe ausreichend.

Differenzielle Privatsphäre bietet einen weitergehenden mathematischen Schutz. Dazu werden Ergebnisse gezielt und kontrolliert leicht verändert, so soll verhindert werden, dass sich aus dem Ergebnis sicher ableiten lässt, ob eine bestimmte Person im Datensatz enthalten ist. Die Stärke dieses Schutzes wird über ein festgelegtes Datenschutzbudget beschrieben. Dieses Verfahren bietet stärkere Garantien, ist aber schwerer umzusetzen und zu erklären.

Die Faustregel: Wenn nur zusammengefasste Ergebnisse für ausreichend große Gruppen benötigt werden, können Mindestgrößen je nach Risiko und Rechtslage ausreichend sein. Wenn ein mathematisch nachweisbares Schutzniveau erforderlich ist, etwa bei sensiblen Gesundheitsdaten oder bei Veröffentlichung von Statistiken, muss differenzielle Privatsphäre zusätzlich umgesetzt werden. Spezialanbieter wie Decentriq integrieren Confidential Computing und DP von Haus aus; auf Databricks lässt sich DP über Bibliotheken auf der Output-Schicht ergänzen, diese Funktion ist in Databricks Clean Rooms nicht automatisch enthalten.

Clean Rooms eignen sich nicht für jede Form der Zusammenarbeit. Vor dem Aufbau sollten vier Einschränkungen geprüft werden.

Komplexe Modelltrainings. Notebook- und SQL-Workloads sind gut abgedeckt, aufwendige Trainings mit speziellen Bibliotheken, GPUs und vielen Testläufen können in der isolierten Umgebung nur eingeschränkt geeignet sein. Vor einem gemeinsamen Modellprojekt muss geprüft werden, ob die benötigten Trainingsverfahren unterstützt werden.

Geschwindigkeit der Zusammenarbeit. Neue Abfragen und Programme müssen in der Regel zunächst geprüft und genehmigt werden, jedes Ergebnis durchläuft den Output-Genehmigungs-Schritt. Das passt gut zu klar definierten Analysen, aber weniger zu spontanen und häufig wechselnden Experimenten. Die Beteiligten sollten deshalb festlegen, wie schnell neue Auswertungen geprüft werden.

Zusammenarbeit mit mehr als zwei Beteiligten. Die Zusammenarbeit zwischen zwei Parteien ist in der Regel der einfachste Fall; bei mehreren Beteiligten müssen Funktionsumfang, Rollen und Freigaben genauer geprüft werden.

Zusammenarbeit über unterschiedliche Datenplattformen hinweg. Wenn die Gegenseite auf Snowflake, AWS oder einer reinen Werbe-Plattform sitzt, kann eine Databricks-Lösung zusätzlichen Integrationsaufwand verursachen. Zusätzliche Schnittstellen können Betrieb und Ergebniskontrolle erschweren. Hier lohnt der Vergleich mit Spezialanbietern, die Cross-Stack ausgelegt sind.

Ohne eine konkrete Fragestellung kann ein Clean Room zu einer zusätzlichen Plattform mit eigenem Betriebs- und Governance-Aufwand werden. Ein technischer Pilot ohne festgelegte Analyse und Ergebnisdefinition erzeugt leicht mehr Abstimmungs- und Betriebsaufwand als Nutzen.