Was ist datenschutzwahrendes maschinelles Lernen?

Ein Team beschließt, ein Sprachmodell auf eigenen Servern zu betreiben, statt eine externe API aufzurufen. Die Motivation ist Datenschutz: sensible Daten im Haus behalten und niemals an Dritte geben. Dieser Instinkt ist richtig, und die dadurch gewonnene Kontrolle ist real, aber sie ist auch unvollständig. Ein auf privaten Datensätzen trainiertes Modell lässt sich dazu bringen, preiszugeben, ob der Datensatz einer bestimmten Person in seinen Trainingsdaten war. Föderierte Updates, die nie Rohdaten transportieren, lassen sich zu den Bildern zurückrechnen, die sie erzeugt haben. Ein großes Modell kann Teile seiner Trainingsdaten auswendig lernen und ausgeben. Die Daten blieben im Haus, und das Modell hat trotzdem geleckt.

Genau diese Lücke, zwischen sich privat fühlen und nachweisbar privat sein, adressiert datenschutzwahrendes maschinelles Lernen. Die übliche ML-Pipeline braucht Rohdaten, auf die die Trainingsinfrastruktur zugreifen kann, und das kollidiert mit Datenschutzregulierung, mit Anforderungen an Datensouveränität und mit Partnern, die ihre Datensätze überhaupt nicht teilen. Datenschutzwahrendes maschinelles Lernen ist die Familie von Verfahren, die diese Kollision auflöst.

Die nützliche Unterscheidung verläuft zwischen Verfahren, die Datenbewegung reduzieren, Verfahren, die begrenzen, was Ausgaben preisgeben können, und Verfahren, die Daten während der Berechnung vertraulich halten. Selbst-Hosting tritt neben diese Kontrollen, es ersetzt sie nicht.

Die Kurzfassung

• Datenschutzwahrendes maschinelles Lernen (PPML) ist eine Oberkategorie, keine einzelne Methode. Dieser Artikel konzentriert sich auf vier zentrale Ansätze: föderiertes Lernen, Differential Privacy, homomorphe Verschlüsselung und sichere Mehrparteienberechnung. Auch andere privatsphärenstärkende Architekturen, etwa Trusted Execution Environments, können in PPML-Systemen vorkommen.
• Föderiertes Lernen allein liefert keine formale Datenschutzgarantie. Es hält Rohdaten an der Quelle, aber geteilte Gradienten-Updates lassen sich manchmal zu Trainingsdatensätzen zurückrechnen. Differential Privacy ist ein gängiger Weg, eine formale Leckage-Schranke hinzuzufügen.
• Die Stärke von Differential Privacy wird meist mit Epsilon zusammengefasst. Die Garantie hängt außerdem von Delta ab, von der geschützten Einheit und von der Methode des Privacy Accounting. Eine formale Garantie mit schwachen Parametern bleibt eine Garantie auf dem Papier und ist in der Praxis Theater.
• Homomorphe Verschlüsselung ist real und langsam. Rechnen auf verschlüsselten Daten funktioniert, aber der Mehraufwand beschränkt es heute auf einfachere Modelle, latenztolerante Inferenz und experimentelle Fine-Tuning-Workflows, nicht auf gewöhnliches Training großer Modelle oder vollständiges Pretraining.
• Ein Modell selbst zu hosten ist Datenlokalisierung, kein PPML. Daten auf einer Infrastruktur zu halten, die Sie kontrollieren, regelt, wer sie erreichen kann. Es regelt nicht, was das Modell selbst preisgeben kann.

Hinweis zum Umfang: Das hier ist eine konzeptionelle Einführung, keine Implementierungsanleitung. Sie behandelt weder Library-Setup noch Epsilon-Wahl, regulatorische Compliance oder privates LLM-Fine-Tuning im Detail. Das Ziel hier ist die Landkarte. Die Abbiegehinweise gehören in eigene Implementierungs-Guides.

Wie datenschutzwahrendes maschinelles Lernen Daten schützt

Datenschutzwahrendes maschinelles Lernen ist ein Sammelbegriff für Methoden, die die Preisgabe von Information beim Modelltraining, bei der Inferenz und bei kollaborativer Analyse verringern, einschränken oder formal begrenzen. Dieser Artikel konzentriert sich auf vier zentrale Ansätze: föderiertes Lernen, Differential Privacy, homomorphe Verschlüsselung und sichere Mehrparteienberechnung. Sie schützen unterschiedliche Werte unter unterschiedlichen Bedrohungsmodellen und dürfen deshalb nicht als austauschbare Garantien behandelt werden.

Das Problem ist einfach: Standard-ML-Pipelines setzen meist voraus, dass der Trainingsprozess auf Rohdatensätze zugreifen kann, während Datenschutzregulierung, Anforderungen an Datensouveränität und Partnerverträge genau diesen Zugriff häufig verhindern. Die vier Familien beantworten diese Einschränkung unterschiedlich: die Berechnung zu den Daten bringen statt die Daten zur Berechnung (föderiertes Lernen), kalibriertes Rauschen hinzufügen, damit Ausgaben weniger über eine einzelne Person verraten (Differential Privacy), auf verschlüsselt bleibenden Daten rechnen (homomorphe Verschlüsselung), oder mehrere Parteien gemeinsam ein Ergebnis berechnen lassen, ohne einander ihre Rohdaten offenzulegen (sichere Mehrparteienberechnung).

Das zugrunde liegende Risiko wird deutlich benannt in Googles Leitfaden für verantwortungsvolle KI: Machine-Learning-Modelle können sich Aspekte der Daten merken oder preisgeben, denen sie ausgesetzt waren, und Datenschutzarbeit existiert, um darum Sicherungen zu ziehen. PPML adressiert genau dieses Risiko und unterscheidet sich von bloßer Anonymisierung, aus Gründen, die der nächste Abschnitt konkret macht.

Warum reicht Anonymisierung nicht aus?

Anonymisierte Daten lassen sich weiterhin re-identifizieren. Namen und offensichtliche Identifikatoren aus einem Datensatz zu entfernen, verringert die offenkundige Exposition, garantiert aber keine Privatsphäre, sobald sich die Daten mit externen Informationen verknüpfen lassen. Das ist die wiederkehrende Schwäche von De-Identifikationsansätzen wie k-Anonymität: Sie können Identifizierbarkeit unter bestimmten Annahmen senken, liefern aber nicht die formalen Garantien, die Verfahren wie Differential Privacy oder kryptografische PPML-Methoden bieten.

Diese praktische Unterscheidung ist wichtig für alle, denen gesagt wurde: „Wir haben es anonymisiert, also passt das schon.“ Anonymisierung ist eine Aussage über einen Datensatz in einem bestimmten Kontext und Bedrohungsmodell. Ein Verknüpfungsangriff muss weder Verschlüsselung brechen noch Zugriffskontrollen umgehen. Er braucht nur einen weiteren Datensatz, der sich mit Ihrem überschneidet. Genau das steht direkt in der De-Identifikations-Leitfaden des NIST, wo festgehalten wird, dass de-identifizierte Daten durch Verknüpfung mit Hilfsdatensätzen weiterhin re-identifiziert werden können.

Differential Privacy liefert etwas, das gewöhnliche De-Identifikation nicht liefert: eine mathematische Schranke dafür, wie stark die Daten einer einzelnen Person ein veröffentlichtes Ergebnis beeinflussen können, unter einer definierten Privatsphäreneinheit und einem definierten Bedrohungsmodell. Homomorphe Verschlüsselung und SMPC bieten andere Arten kryptografischer Vertraulichkeit, während föderiertes Lernen vor allem ändert, wo Daten verarbeitet werden. Diese Garantien sind verwandt, aber sie sind nicht dasselbe.

Wie funktioniert föderiertes Lernen, und warum reicht es allein nicht?

Beim föderierten Lernen wird ein globales Modell an lokale Geräte oder Server geschickt, trainiert dort auf den vorhandenen Daten und sendet nur seine Parameter-Updates zurück ans Zentrum. Rohdaten bewegen sich nie. Das ist ein wirklich nützliches Muster, und es läuft in großem Maßstab in Produktion. Es ist für sich genommen aber keine Datenschutzgarantie.

Der Mechanismus lautet Modell-zu-Daten statt Daten-zu-Modell. Googles Gboard-Deployment betreibt über 30 Sprachmodelle direkt auf dem Gerät, in über 7 Sprachen und über 15 Ländern, und trainiert auf Text, der das Telefon nie verlässt. Das ist föderiertes Lernen, das hält, was es verspricht: Die Tastatur wird besser, ohne dass Google einsammelt, was Sie getippt haben.

Das Problem ist, was in den Updates mitreist. Gradienten tragen Information über die Daten, die sie erzeugt haben, und diese Information lässt sich zurückgewinnen. Zhu, Liu und Han haben das gezeigt in Deep Leakage from Gradients (NeurIPS 2019) und demonstrierten Gradient-Inversion-Angriffe, die private Trainingsbeispiele aus geteilten Modell-Updates rekonstruieren, in ihren Experimenten mit pixelgenauer Bildwiederherstellung und tokengenauer Übereinstimmung bei Text. Föderiertes Lernen hat die Datenbewegung reduziert. Das Leckage-Risiko hat es nicht beseitigt.

Wenn das Ziel ist, zu begrenzen, was die Teilnahme preisgeben kann, ist Differential Privacy eine gängige Ergänzung. Secure Aggregation adressiert ein anderes Risiko, indem sie einzelne Client-Updates vor dem koordinierenden Server verbirgt. Gboard kombiniert föderiertes Lernen mit formaler Differential Privacy, statt sich allein auf die Föderation zu verlassen.

Hinweis: Föderiertes Lernen wird häufig als „privat“ beschrieben, weil Rohdaten an der Quelle bleiben. Diese Beschreibung ist irreführend. Ohne zusätzlichen Schutz können föderierte Updates genug Signal tragen, um Trainingsdatensätze zu rekonstruieren. DP-FL fügt eine formale Differential-Privacy-Garantie hinzu, statt sich allein auf die Föderation zu verlassen. Föderation für sich ist eine Entscheidung über den Umgang mit Daten, kein Datenschutzbeweis.

Was ist Differential Privacy, und was steuert Epsilon eigentlich?

Differential Privacy ist eine mathematische Definition, die begrenzt, wie stark sich eine Analyse ändern kann, wenn eine Privatsphäreneinheit hinzugefügt oder entfernt wird. Viele Mechanismen erreichen diese Garantie durch kalibrierte Zufälligkeit. Epsilon ist ein sichtbarer Parameter, aber eine aussagekräftige Garantie hängt außerdem von der Privatsphäreneinheit ab, von der DP-Variante und etwaigen weiteren Parametern wie Delta sowie von Komposition, Accounting und Implementierungsdetails.

Epsilon wird als Privacy-Budget beschrieben in NVIDIAs Glossar: Niedrigere Werte bedeuten stärkeren Datenschutz, aber mehr Rauschen; höhere Werte erhalten die Genauigkeit auf Kosten schwächerer Garantien. Ein gängiger Weg, Differential Privacy im Deep-Learning-Training anzuwenden, ist DP-SGD, differentially private stochastic gradient descent: jeden Gradienten pro Beispiel auf eine beschränkte Größe kappen, kalibriertes Gaußsches Rauschen hinzufügen, dann aggregieren. Das Kappen begrenzt, wie stark ein einzelnes Beispiel das Modell beeinflussen kann. Das Rauschen verdeckt den verbleibenden Einfluss.

Dieses Budget verbraucht sich. Der Mechanismus wird beschrieben in die Dokumentation von Tumult Analytics zu Privacy-Budgets: Jede Abfrage gegen einen geschützten Datensatz verbraucht einen Teil des Privacy-Budgets. Wie sich diese Ausgaben summieren, ist Standardtheorie der Differential Privacy, dargelegt in The Algorithmic Foundations of Differential Privacy von Dwork und Roth: Bei einfacher Komposition summieren sich k Abfragen mit jeweils Parameter Epsilon zu einem Gesamt-Privacy-Verlust von k mal Epsilon, und erweiterte Kompositionssätze liefern engere Schranken. Sie bekommen keine unbegrenzten Fragen. Sie bekommen ein Budget, und Sie geben es aus.

Die Wahl der Parameter entscheidet also, ob die Garantie in der Praxis etwas bedeutet. Eine begutachtete Kritik an Datenschutzansätzen im maschinellen Lernen argumentiert, dass die mathematische Rahmung einen „Anstrich von Objektivität“ verleihen kann, mit dem ein Projekt reingewaschen wird. Setzen Sie die Datenschutzparameter schwach genug, und die Garantie kann nahezu bedeutungslos werden, während ein Team weiterhin behaupten darf, Differential Privacy erfüllt zu haben. Die Garantie ist echt. Ihre praktische Stärke ist eine Designentscheidung.

Hinweis: Eine Differential-Privacy-Garantie ist nur dann aussagekräftig, wenn Sie die Datenschutzparameter und die Einheit kennen, die sie schützen. Ein sehr hohes Epsilon, ein lockeres Delta oder unklares Accounting können eine technisch gültige Garantie praktisch wirkungslos machen. „Dieses System nutzt Differential Privacy“ zu lesen, sagt für sich genommen fast nichts: Die Bedeutung tragen die Datenschutzparameter, worüber sie gemessen wurden und wie sie sich zusammensetzen. Konkrete Deployments machen das greifbar. Google berichtet für sein System Provably Private Insights ein Epsilon von 1 auf Nutzerebene, aber das ist die Wahl eines Deployments für einen Anwendungsfall, keine Zahl zum Abschreiben.

Wie rechnet homomorphe Verschlüsselung auf Daten, die sie nie entschlüsselt?

Vollständig homomorphe Verschlüsselung (FHE) lässt einen Server Berechnungen direkt auf verschlüsselten Daten ausführen und ein verschlüsseltes Ergebnis zurückgeben, das nur der Dateneigentümer entschlüsseln kann. Der Server erledigt die Arbeit, ohne je den Klartext zu sehen. Es ist eines der stärksten Datenschutzwerkzeuge des Felds, aber der Preis ist die Performance.

Die nützliche Analogie ist ein verschlossener Handschuhkasten mit eingebauten Handschuhen: Eine Arbeiterin kann hineingreifen und den Inhalt bearbeiten, ohne die Box je zu öffnen oder etwas herauszunehmen. Den einzigen Schlüssel hat der Dateneigentümer. Die Berechnung passiert am versiegelten Inhalt, und nur der Eigentümer kann die Box öffnen, um das Ergebnis zu lesen. Genau das leistet FHE mathematisch: auf Chiffretext operieren, sodass das Entschlüsseln der Ausgabe dieselbe Antwort liefert wie eine Berechnung auf dem Klartext.

Der Haken ist der Aufwand. Concrete ML von Zama wandelt scikit-learn- und PyTorch-Modelle in FHE-kompatible Äquivalente um, ohne dass Nutzer direkt mit kryptografischen Primitiven arbeiten müssen, und Version v1.9 erschien am 10. April 2025. Doch die eigenen Benchmarks des Projekts zeigen den Mehraufwand: Ein CIFAR10-Bildklassifikationsnetz läuft unter FHE mit rund 4 Minuten pro Bild. Für manche latenztolerante Inferenz, für einfachere Modelle und für experimentelles verschlüsseltes Fine-Tuning ist das in Ordnung. Ein praktikabler Weg zu vollständigem Pretraining großer Modelle oder zu gewöhnlichen Trainings-Workloads ist es weiterhin nicht. FHE ist heute ein Präzisionsinstrument für ein schmales Aufgabenfeld, keine Allzweck-Datenschutzschicht.

Was ist sichere Mehrparteienberechnung im maschinellen Lernen?

Sichere Mehrparteienberechnung (SMPC) lässt mehrere Parteien gemeinsam eine Funktion über ihre kombinierten privaten Eingaben berechnen, ohne dass eine Partei die Rohdaten der anderen sieht. Die Eingabe jeder Partei bleibt geheim. Bekannt wird nur das vereinbarte Ergebnis. SMPC lässt sich mit Techniken wie Secret Sharing, Garbled Circuits, Oblivious Transfer und deren Kombinationen bauen. In Secret-Sharing-Protokollen werden private Werte in Anteile zerlegt, sodass ein einzelner Anteil die Eingabe nicht preisgibt. Garbled-Circuit-Protokolle arbeiten anders: Sie kodieren eine Berechnung so, dass die Parteien sie auswerten können, ohne ihre privaten Eingaben offenzulegen.

Der natürliche Anwendungsfall ist organisationsübergreifende Zusammenarbeit. Mehrere Krankenhäuser wollen ein Modell auf ihren gemeinsamen Patientendaten trainieren, aber keines darf die Akten rechtlich mit den anderen teilen. SMPC lässt sie das gemeinsame Modell berechnen, als wären die Daten zusammengelegt, während die Akten jedes Hauses bei ihm versiegelt bleiben. Der SMPC-Mehraufwand hängt stark vom Protokoll ab, vom Sicherheitsmodell, von den Netzbedingungen, der Zahl der Parteien und der ausgewerteten Funktion. Viele Protokolle sind kommunikationsintensiv, deshalb muss man Performance an der konkreten Zusammenarbeit messen, statt sie pauschal gegen Differential Privacy oder FHE zu ranken. Genau dieses Muster für maschinelles Lernen im Gesundheitswesen behandelt ein Übersichtsartikel von 2025 in WIREs Computational Statistics.

Kann ein Machine-Learning-Modell seine Trainingsdaten preisgeben?

Ja. Ein trainiertes Modell kann seine Trainingsdaten auf mehreren verschiedenen Wegen verraten: Membership Inference zeigt, ob ein bestimmter Datensatz in den Trainingsdaten war, Modellinversion und Gradienten-Leckage können Datensätze rekonstruieren, und große Sprachmodelle können Teile ihrer Trainingsdaten auswendig lernen und wörtlich ausgeben. Das sind keine Hypothesen. Es sind demonstrierte Angriffe, und sie sind der Grund, warum es die obigen Verfahren gibt.

Das grundlegende Ergebnis ist Membership Inference. Shokri und Kolleginnen zeigten in Membership Inference Attacks Against Machine Learning Models (IEEE S&P 2017), dass eine Angreiferin, die das Vorhersageverhalten eines Modells beobachtet, feststellen kann, ob ein bestimmter Datensatz Teil der Trainingsdaten war. Das klingt abstrakt, bis die Trainingsmenge „Patientinnen mit einer bestimmten Diagnose“ ist, denn dann ist die Zugehörigkeit selbst die sensible Tatsache. Modellinversion und die zuvor besprochenen Gradienten-Leckage-Angriffe erweitern das von „war dieser Datensatz dabei“ zu „rekonstruiere den Datensatz“.

Die Front sind große Sprachmodelle, und dort passen ältere PPML-Rahmenwerke am schlechtesten. Forschung zu LLMs, die Trainingsdaten ausgeben belegt, dass große Modelle Teile ihres Trainingskorpus auswendig lernen und dazu gebracht werden können, ihn zu reproduzieren, wobei Extraktionsangriffe wörtliche und nahezu wörtliche Trainingsdaten zurückholen. DP-SGD lässt sich auf privates Fine-Tuning anwenden, doch die Genauigkeits- und Rechenkosten im Maßstab großer Modelle sind hart, was mit ein Grund dafür ist, dass Apples PPML-Workshop 2026 eine ganze Track-Reihe zu Foundation Models und Datenschutz hatte. Verteidigungen, die für einen Logistic-Regression-Klassifikator sauber funktionieren, übertragen sich nicht gratis auf ein Modell mit Milliarden Parametern.

PPML und selbst gehostete KI: Was lokale Inferenz Ihnen bringt und was nicht

Ein Modell selbst zu hosten hält Ihre Daten auf einer Infrastruktur, die Sie kontrollieren. Das ist ein echter Gewinn bei Zugriffskontrolle und Datenlokalisierung: Die Daten reisen nicht zu Dritten, und Sie entscheiden, wer die Maschine erreicht, auf der es läuft. Es ist aber kein datenschutzwahrendes maschinelles Lernen. Lokale Inferenz tut für sich genommen nichts gegen Membership Inference auf das Modell, und sie hindert ein Modell nicht daran, preiszugeben, was es sich gemerkt hat.

Die beiden lösen unterschiedliche Hälften des Problems, und sie zu vermengen ist ein verbreiteter Fehler in diesem Feld. Datenlokalisierung regelt, wer an die Daten herankommt: eine Perimeterfrage, beantwortet davon, wo die Bytes liegen und wer die Schlüssel zum Raum hat. PPML regelt, was das Modell selbst preisgeben kann, eine Frage der Informationsleckage, beantwortet von den vier obigen Verfahren. Ein Modell auf dem eigenen Server zu betreiben ist eine starke Antwort auf die erste Frage und überhaupt keine auf die zweite.

Wenn Sie abwägen, ob Sie das Modell überhaupt selbst betreiben sollen, ist die Kostenseite dieser Entscheidung eine eigene Analyse: siehe Eine Open-Weight-LLM selbst hosten vs. eine API: Die echte Kostenrechnung.

Für Plattform- oder Infrastruktur-Engineering lautet die operative Lesart: „Es läuft auf unserem eigenen Server“ kann manche Anforderungen an Datenlokalisierung und Zugriffskontrolle erfüllen, beschränkt aber für sich genommen nicht, was das Modell preisgeben kann. Sobald das Modell oder seine Ausgaben je geteilt werden, ob teamübergreifend, mit Partnern oder in einem Produkt, folgt der um die Hardware gebaute Perimeter dem Modell nicht zur Tür hinaus. Die Architekturentscheidungen, die die Garantie wirklich verschieben, sind die PPML-Entscheidungen: Differential Privacy auf veröffentlichten Ausgaben, DP-FL für Training über Standorte, die Sie nicht zentralisieren können, verschlüsselungsbasierte Berechnung dort, wo Daten nicht einmal der eigenen Infrastruktur offenstehen dürfen. Googles Provably Private Insights ist gerade deshalb lehrreich, weil es Kontrollen kombiniert, Differential Privacy, Trusted Execution Environments und vertrauliche föderierte Analytik, statt sich auf eine einzige zu verlassen. Lokalisierung ist Teil einer echten Architektur. Sie ist nicht die ganze.

Wann sollten Sie welche PPML-Technik einsetzen?

Die Auswahllogik folgt der Randbedingung, nicht der Mode. Nutzen Sie föderiertes Lernen, wenn die Daten nicht zentralisiert werden können. Nutzen Sie Differential Privacy, wenn Sie eine formale Garantie darüber brauchen, was das Modell preisgibt. Nutzen Sie homomorphe Verschlüsselung, wenn die Berechnung auf nie entschlüsselten Daten stattfinden muss und die Latenz es zulässt. Nutzen Sie sichere Mehrparteienberechnung, wenn mehrere Parteien gemeinsam rechnen müssen, ohne ihre Eingaben zu teilen.

Die Verfahren lassen sich auch kombinieren. DP-FL ist das klarste Beispiel: Wählen Sie die Kontrollen nach den Garantien, die das System braucht, statt das Problem in ein einziges Verfahren zu pressen.

Die Abwägungen auf einen Blick:

Diese Einschätzungen stammen aus einem IoT-fokussierten PPML-Übersichtsartikel vom März 2026, aus Zamas Concrete ML-Benchmarks und aus der Literatur zur Re-Identifikation.

Die Tabelle ist nur ein Ausgangspunkt. Reale Systeme kombinieren häufig Verfahren: Ein standortübergreifendes Trainingsproblem, das zusätzlich eine formale Datenschutzgarantie braucht, ist meist ein DP-FL-Problem und keine Wahl zwischen föderiertem Lernen und Differential Privacy. Wer die Entscheidung strenger strukturieren will, kann sich durch das strukturierte Entscheidungshilfe-Framework für Entwickler arbeiten, das Ende 2024 veröffentlicht wurde.

Zum Tooling: TensorFlow Federated bietet ein Open-Source-Framework für föderiertes Lernen und Berechnungen auf dezentralen Daten. TensorFlow Privacy liefert Werkzeuge für differentiell privates Training, Googles Differential-Privacy-Bibliotheken decken differentiell private Statistik und Aggregation ab, und Concrete ML liefert den FHE-Weg. PySyft konzentriert sich inzwischen breiter auf datenschutzwahrende Remote Data Science, bei der Berechnungen gegen Daten laufen, die beim Eigentümer bleiben, und nur freigegebene Ergebnisse geteilt werden. Das sind die Namen und was sie tun. Das Setup gehört in eigene Implementierungs-Guides, nicht hierher. Die wiederkehrende Lehre lautet: Die Mathematik kann stimmen, während die Implementierung trotzdem scheitert. Die Garantie zählt nur, wenn das System um das richtige Bedrohungsmodell herum gebaut ist und die Datenschutzparameter zum geschützten Risiko passen.

Häufig gestellte Fragen

Was bedeutet PPML?

Datenschutzwahrendes maschinelles Lernen ist ein Sammelbegriff für Methoden, die die Preisgabe von Information während des maschinellen Lernens verringern, einschränken oder formal begrenzen. Zu den wichtigsten Ansätzen zählen föderiertes Lernen, Differential Privacy, homomorphe Verschlüsselung und sichere Mehrparteienberechnung, doch sie schützen unterschiedliche Werte und liefern unterschiedliche Arten von Garantien.

Reicht föderiertes Lernen aus, um die Privatsphäre zu schützen?

Nein. Föderiertes Lernen hält Rohdaten an der Quelle, aber die geteilten Parameter-Updates lassen sich per Gradient-Inversion-Angriff zu Trainingsdatensätzen zurückrechnen. Für sich genommen liefert es keine formale Datenschutzgarantie. Differential Privacy kann eine formale Leckage-Schranke hinzufügen, und daraus entsteht die Kombination, die man üblicherweise DP-FL nennt.

Welchen Epsilon-Wert sollte ich für Differential Privacy verwenden?

Es gibt keinen universellen Wert. Epsilon ist einer der Hauptparameter im Abtausch zwischen Privatsphäre und Genauigkeit: Niedrigere Werte bedeuten in der Regel mehr Privatsphäre und mehr Rauschen, höhere Werte in der Regel weniger Privatsphäre und weniger Rauschen. Die richtige Einstellung hängt von der Sensibilität der Daten ab und vom Risiko, das Sie akzeptieren können. Es gibt keine universelle Schwelle, die einen Epsilon-Wert „sicher“ macht. Bewerten Sie Epsilon zusammen mit der Privatsphäreneinheit, der DP-Variante und etwaigen weiteren Parametern wie Delta, der Kompositionsmethode und dem Bedrohungsmodell des Systems.

Was ist der Unterschied zwischen PPML und Anonymisierung?

Anonymisierung entfernt Identifikatoren aus einem Datensatz, aber anonymisierte Datensätze lassen sich durch Verknüpfung mit Zusatzdaten aus anderen Quellen re-identifizieren. Manche PPML-Verfahren liefern formale Garantien, die gewöhnliche Anonymisierung nicht bietet. Differential Privacy kann begrenzen, wie stark die Daten einer Person ein veröffentlichtes Ergebnis beeinflussen, während FHE und SMPC andere Formen kryptografischer Vertraulichkeit bieten.

Kann man Trainingsdaten aus einem Machine-Learning-Modell extrahieren?

Ja. Membership-Inference-Angriffe zeigen, ob ein bestimmter Datensatz in den Trainingsdaten war, Modellinversion und Gradienten-Leckage können Datensätze rekonstruieren, und große Sprachmodelle können Trainingsdaten auswendig lernen und wörtlich ausgeben. Das sind demonstrierte, in der Sicherheitsliteratur dokumentierte Angriffe, keine hypothetischen Risiken.

Garantiert Selbst-Hosting eines Modells Datenschutz?

Nein. Selbst-Hosting hält Daten auf einer Infrastruktur, die Sie kontrollieren, also Zugriffskontrolle und Datenlokalisierung, ein echter Gewinn dabei, zu steuern, wer an die Daten kommt. Es ist kein datenschutzwahrendes maschinelles Lernen und stoppt weder Membership Inference noch Leckage durch Memorierung. Es passt gut zu PPML-Verfahren, ersetzt sie aber nicht.

Welche Open-Source-Werkzeuge gibt es für datenschutzwahrendes maschinelles Lernen?

Mehrere Open-Source-Werkzeuge decken verschiedene Teile von PPML ab. TensorFlow Federated unterstützt föderiertes Lernen und Berechnungen über dezentrale Daten, TensorFlow Privacy liefert Werkzeuge für differentiell privates Training, und Concrete ML deckt maschinelles Lernen mit FHE ab. PySyft konzentriert sich inzwischen auf datenschutzwahrende Remote Data Science, bei der Berechnungen gegen Daten laufen, die deren Eigentümer kontrolliert, und nur freigegebene Ergebnisse geteilt werden.