Wie datenschutzwahrend ist Federated Learning wirklich? Secure Aggregation und Differential Privacy

Federated Learning (FL) wird oft mit einem einfachen Versprechen verkauft: „Die Daten verlassen das Haus nie.” Das stimmt – und führt trotzdem in die Irre, wenn man es als vollständige Datenschutzgarantie versteht. Denn ausgetauscht werden ja nicht nichts, sondern Modell-Updates. Und die sind nicht automatisch harmlos.

Dieser Beitrag erklärt, was an reinem FL offenbleibt und mit welchen zwei Verfahren – Secure Aggregation und Differential Privacy – die Lücke geschlossen wird. Wer die Idee von FL zuerst auffrischen möchte: Was ist Federated Learning?

Das Missverständnis: „lokal” heißt nicht „unsichtbar”

Bei FL trainiert jeder Teilnehmer das gemeinsame Modell auf seinen eigenen Daten und schickt nur die gelernten Anpassungen (Gewichte bzw. Gradienten) an einen Koordinator. Die Rohdaten bleiben lokal – so weit, so gut.

Das Problem: Diese Updates sind aus den Daten berechnet und tragen Spuren von ihnen. In der Forschung ist gut dokumentiert, dass sich unter bestimmten Umständen aus Gradienten Rückschlüsse ziehen lassen:

• Membership Inference: War ein bestimmter Datensatz im Training? Schon das kann sensibel sein – etwa, ob ein bestimmter Kunde im Datenbestand war.
• Rekonstruktion: Unter ungünstigen Bedingungen lassen sich Teile der Eingabedaten näherungsweise zurückrechnen.

Das heißt nicht, dass FL unsicher ist – sondern dass „Rohdaten bleiben lokal” und „über die Personen dahinter wird nichts preisgegeben” zwei verschiedene Aussagen sind. Genau hier setzen die beiden folgenden Verfahren an.

Secure Aggregation: nur die Summe ist sichtbar

Die erste Frage lautet: Muss der Koordinator die Updates der einzelnen Teilnehmer überhaupt im Klartext sehen? Für Federated Averaging braucht er nur ihre Summe (genauer: den Mittelwert). Das Einzelupdate ist nur Mittel zum Zweck.

Secure Aggregation nutzt genau das: Die Teilnehmer verschleiern ihre Updates mit paarweise abgestimmten Zufallsmasken, die sich beim Aufsummieren über alle Teilnehmer gegenseitig aufheben. Der Koordinator erhält am Ende die korrekte Summe – kann aber kein einzelnes Update rekonstruieren. Der Beitrag des einzelnen Versorgers verschwindet in der Menge, bevor irgendjemand hinschaut.

Das adressiert das Vertrauen in den Koordinator und gegenüber den anderen Teilnehmern. Was es nicht löst: Wenn das aggregierte Gesamtmodell selbst noch zu viel über einzelne Datensätze verrät, hilft die Geheimhaltung der Einzelupdates nicht. Dafür braucht es das zweite Werkzeug.

Differential Privacy: messbares Rauschen statt Bauchgefühl

Differential Privacy (DP) geht das Problem von der mathematischen Seite an. Die Idee: Man fügt dem Lernprozess gezielt Rauschen hinzu – so dosiert, dass das Ergebnis sich praktisch nicht ändert, egal ob ein einzelner Datensatz dabei war oder nicht. Wenn die Anwesenheit einer Person das Modell nicht erkennbar beeinflusst, kann das Modell auch nichts über sie verraten.

Der Clou ist die Messbarkeit: DP liefert mit dem sogenannten Privacy-Budget (ε, „Epsilon”) eine harte Obergrenze dafür, wie viel Information maximal abfließen kann. Datenschutz wird damit von einer Behauptung zu einer quantifizierbaren Garantie. Kleines ε = starker Schutz, aber mehr Rauschen; großes ε = genaueres Modell, aber schwächerer Schutz.

Es gibt keinen Schutz zum Nulltarif

Beide Verfahren kosten – und das ehrlich zu benennen gehört dazu:

• Differential Privacy tauscht Genauigkeit gegen Schutz. Zu viel Rauschen, und das Modell wird unbrauchbar; zu wenig, und die Garantie ist wertlos. Die richtige Balance ist eine fachliche Entscheidung, kein Default.
• Secure Aggregation kostet Koordinationsaufwand und Kommunikation und reagiert empfindlich auf Teilnehmer, die mitten in der Runde ausfallen.
• Beide erhöhen die Komplexität eines ohnehin nicht trivialen Systems.

Deshalb sind sie kein Automatismus, sondern eine bewusste Wahl je nach Schutzbedarf. Für unkritische Maschinendaten mag reines FL genügen; bei personenbezogenen Verbrauchs- oder Kundendaten wird man genauer hinsehen.

Was das für die Energiewirtschaft heißt

Die Kernbotschaft ist keine Entwarnung und keine Warnung, sondern eine Einordnung: Federated Learning ist der Baustein, der Rohdaten lokal hält – Secure Aggregation und Differential Privacy sind die Bausteine, die das Restrisiko der Update-Übertragung adressieren. Erst zusammen ergeben sie ein Schutzniveau, das man gegenüber Datenschutzbeauftragten und Aufsicht belastbar vertreten kann.

Für die Praxis bedeutet das vor allem: Datenschutz früh als Designfrage behandeln, nicht als nachträgliches Häkchen. Welche Verfahren in welchem Anwendungsfall nötig sind, hängt von der Datenart und vom Rechtsraum ab – und ist damit wieder eine Frage des passenden Zuschnitts der Kooperation.

---

Wie sich das im Recht spiegelt, steht im Beitrag DSGVO, AI Act und Federated Learning. Neue Grundlagenbeiträge können Sie per RSS-Feed abonnieren.