Differential Privacy

In SQL-Abfragen auf sensiblen Daten. "Gib mir das Durchschnittsgehalt." Differential Privacy addiert ein kleines "Rauschen" (Noise) zum Ergebnis, z. B. +/- 5 Euro. Das Ergebnis ist immer noch nützlich (Statistik), aber niemand kann Re-Identifizierung betreiben ("Differencing Attack"). Bibliotheken: Google Differential Privacy (C++/Go/Java), OpenDP.

1. Epsilon ($\epsilon$)

Der Privacy-Parameter. Kleines $\epsilon$ (z. B. 0.1) = Viel Lärm, hohe Privatsphäre, schlechte Datenqualität. Großes $\epsilon$ (z. B. 10) = Wenig Lärm, geringe Privatsphäre, gute Datenqualität. Es ist ein "Budget". Jede Abfrage verbraucht Privacy. Wenn das Budget leer ist, darfst du keine Fragen mehr stellen.

2. Laplace Mechanism

Wie fügt man Lärm hinzu? Man zieht eine Zufallszahl aus der Laplace-Verteilung. Die Breite der Verteilung hängt von der Sensitivity der Funktion ab. "Wie stark kann sich das Ergebnis ändern, wenn eine Person fehlt?" Bei COUNT ist Sensitivity 1. Bei MAX kann sie unendlich sein (gefährlich).

1. Privatsphäre-Budget ($\epsilon$) als Metrik der Verschlechterung

Die Brillanz von DP liegt in ihrem kompositionellen Charakter: Man kann den Worst-Case-Leak mathematisch limitieren. Die Grundformel lautet $Pr[\mathcal{K}(D) \in S] \le \exp(\epsilon) \times Pr[\mathcal{K}(D') \in S]$. Die Wahrscheinlichkeit, dass der Algorithmus $\mathcal{K}$ einen bestimmten Output auf dem Datensatz $D$ liefert, darf maximal um den Faktor $\exp(\epsilon)$ abweichen, falls eine Person ($D'$) entfernt wurde.
Das Problem: Wenn Forscher 10 verschiedene SQL-Abfragen auf derselben Datenbank machen, addieren sich ihre Epsilons ($\epsilon_{total} = \sum \epsilon_i$). Irgendwann ist das "Privacy Budget" aufgebraucht, die Datenbank muss hart gesperrt werden. Um diesem Rapid-Exhaustion zu entgehen, nutzt man den Gaussian Mechanism, der ($\epsilon$, $\delta$)-DP garantiert, wodurch das Rauschen auf große Abfragenmengen sublinear langsamer wächst, man aber eine kleine Fehlerquote ($\delta$, "catastrophic failure") für völligen Leak akzeptiert.

2. Local vs. Global Differential Privacy

Der Ansatz teilt sich diametral nach Vertrauen in die Architektur. Global DP: Das Krankenhaus hält die unmaskierte Datenbank. Dem Server wird zu 100% vertraut. Das Rauschen wird erst im Moment der Abfrage ins SQL-Ergebnis beigemischt. Gut für präzise Algorithmen, schlecht bei Database-Hacks. Local DP (LDP): Wenn Apple Emoji-Trends oder Google Chrome Startseite-Raten sammelt, trauen sie sich selbst nicht The-Man-in-the-Middle zu sein. Hier fügt das Smartphone selbst das Laplacian-Rauschen (Local Randomized Response) hinzu, bevor es die Daten übers Internet an Apple funkt. Apple sammelt Milliarden völlig unbrauchbarer Mülldaten in ihrer Cloud, deren reiner aggregierter Rausch-Mittelwert aber asymptotisch das wahre Verhalten der Nutzerbasis offenlegt.

3. Gradient Perturbation in Deep Learning (PATE & DP-SGD)

Beim Trainieren riesiger LLMs speichern Netze unabsichtlich sensible Details (SSN, Telefonnummern), die man später gezielt aus ihnen herausprompten kann ("Model Inversion Attack"). Um DP in Pytorch zu packen, wird DP-SGD (Differentially Private Stochastic Gradient Descent) verwendet. Bei jedem Backpropagation-Schritt wird nicht nur das Gewichtungs-Update (Gradient) hart gekappt (Clipping auf Max-Norm), um Ausreißer zu bestrafen, sondern danach brutales Gauss-Rauschen auf den Gradienten-Tensor addiert. Das Modell lernt die "Population Patterns", verliert aber physisch die Fähigkeit, das Gesicht eines einziges Individuums zu "memorizen".