--- service: "Publicasta" schema_version: "1.0" article_id: 762 title: "Googles überprüfbares föderiertes Lernen verändert die Datenschutzfrage für KI-Käufer" language: "de" default_language: "en" canonical_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=de" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=de" api_url: "https://publicasta.com/api/public/v1/channels/ai_practice/articles/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=de" channel_url: "https://publicasta.com/api/public/v1/channels/ai_practice" channel_articles: "https://publicasta.com/api/public/v1/channels/ai_practice/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-10-04T10:24:51+00:00" updated_at: "2026-10-04T10:24:51+00:00" translations: - language: "ar" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ar" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=ar" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=ar" - language: "de" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=de" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=de" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=de" - language: "en" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=en" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=en" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=en" - language: "es" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=es" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=es" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=es" - language: "fr" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=fr" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=fr" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=pl" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=pl" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ru" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=ru" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=zh" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=zh" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=zh" --- # Googles überprüfbares föderiertes Lernen verändert die Datenschutzfrage für KI-Käufer > Googles neues TEE-basiertes System macht Datenschutzversprechen beim föderierten Lernen überprüfbarer. Für Unternehmen zählt deshalb nicht nur, wo Rohdaten liegen, sondern welche Verarbeitung technisch erzwungen wird und was das System weiterhin verrät. Googles jüngste Arbeit am föderierten Lernen lässt sich leicht unter Infrastruktur-Forschung ablegen. Damit würde man den praktischen Kern verfehlen. Die entscheidende Veränderung besteht nicht nur darin, dass ein Modell aus Daten lernen kann, die auf Telefonen oder bei verschiedenen Organisationen bleiben. Der Server-seitige Trainingsprozess wird vielmehr so entworfen, dass externe Parteien prüfen können, welche Workloads ausgeführt werden dürfen, die Identität der Software verifizieren und kontrollieren können, dass nur anonymisierte Ergebnisse veröffentlicht werden. ![Redaktionelle Visualisierung von Smartphones und institutionellen Knoten, die verschlüsselte Daten an eine attestierte sichere Rechenumgebung für datenschutzfreundliches föderiertes Lernen senden.](https://publicasta.com/storage/projects/8/pages/762/2026/10/d3e4cd7a-818f-4aa7-8478-47402f347374.webp) Am 2. Oktober stellte Google Research ein neues System für föderiertes Lernen vor, das auf Trusted Execution Environments (TEEs), öffentlichen Transparenzprotokollen, verschlüsselten Uploads und differenzieller Privatsphäre beruht. Nach Angaben von Google wird es bereits für die englischen und japanischen Modelle zur Vorhersage des nächsten Wortes in Gboard eingesetzt. Gegenüber dem früheren Aufbau soll es schneller trainieren und ein besseres Verhältnis zwischen Datenschutz und Nutzen erreichen. Das begleitende Paper beschreibt die Architektur und ihren Einsatz in der Produktion. Das bedeutet nicht, dass föderiertes Lernen plötzlich eine universelle Antwort auf private KI geworden ist. Es bedeutet, dass sich das Einkaufsgespräch von einem vertrauten Versprechen — „Die Rohdaten bleiben, wo sie sind“ — zu einer schwierigeren Frage verschiebt: Kann die Organisation beweisen, was der Trainingsdienst mit den Daten tun durfte, nachdem sie dort angekommen waren? Für Unternehmen, die KI auf sensible Texte, Gesundheitsinformationen, Finanzunterlagen, industrielle Telemetrie oder Daten mehrerer Institutionen anwenden wollen, ist diese Unterscheidung nützlich. Ein System kann auf ein zentrales Rohdatenarchiv verzichten und dennoch Informationen über Updates, Protokolle, Teilnahmemuster, das Modellverhalten oder schwache Betriebskontrollen preisgeben. Datenschutz ist eine Eigenschaft des gesamten Workflows, nicht die Folge eines modischen Architekturbegriffs. ## Was Google tatsächlich angekündigt hat Föderiertes Lernen verteilt Teile des Modelltrainings auf mehrere Clients. In einem bekannten gerätebasierten Aufbau berechnen Telefone oder andere Endpunkte lokale Updates aus lokalen Daten, senden geschützte Updates an einen Koordinator und erhalten ein überarbeitetes Modell. Der Dienstanbieter muss die ursprünglichen Beispiele nicht in einer gemeinsamen konventionellen Trainingsdatenbank sammeln. Google führte diesen Ansatz 2017 ein und nutzt ihn laut [Forschungsankündigung](https://research.google/blog/toward-provably-private-learning-from-federated-data/) unter anderem für Gboards Vorhersage des nächsten Wortes, Smart Compose, Antwortvorschläge und Smart Text Selection. Der neue Entwurf verändert, wo ein Teil der aufwendigen Arbeit stattfindet. Client-Geräte laden verschlüsselte Trainingsbeispiele hoch, während serverseitige TEEs das Trainingsprogramm ausführen. Ein TEE ist eine hardwaregestützte, isolierte Umgebung, die Vertraulichkeit und Integrität von Code und Daten während der Berechnung gewährleisten soll. Sie kann außerdem Remote Attestation unterstützen: Ein Prüfer kann kontrollieren, ob ein bestimmter zugelassener Workload läuft, bevor Schlüssel oder Daten freigegeben werden. Googles System verbindet diese Eigenschaft mit einer Zugriffspolitik. Die Policy legt fest, welche serverseitigen Workloads einen Upload verarbeiten dürfen. Das Gerät autorisiert die Policy, bevor es die verschlüsselten Daten sendet, und ein Schlüsselverwaltungsdienst gibt Entschlüsselungsschlüssel nur an einen Workload frei, der zur Policy passt. Google zufolge werden diese Policies in Rekor, einem öffentlichen Transparenzprotokoll, veröffentlicht. Prüfer können dadurch beobachten, an welchen serverseitigen Workloads Geräte teilnehmen konnten. Zum System gehören außerdem ein in einem TEE betriebener Schlüsselverwaltungsdienst, ein Root-Processing-TEE, Worker-TEEs für parallele Aufgaben und verschlüsselter Wiederherstellungszustand für Fehlertoleranz. Die Trainingslogik wird in Federated Language formuliert, einer Open-Source-Orchestrierungssprache, die von TensorFlow Federated abgeleitet ist. Die für die Betreiber sichtbaren Ergebnisse sollen auf Metriken und differenziell private Modellgewichte beschränkt sein, nicht auf einzelne Trainingsbeispiele. Das ist eine konkretere Kontrollfläche als eine Datenschutzerklärung in einer Produktbroschüre. Es geht nicht mehr nur darum, ob ein Anbieter verspricht, Daten nicht einzusehen. Entscheidend wird, ob Daten ausschließlich von einem attestierten Workload entschlüsselt werden können, ob der erlaubte Workload protokolliert wird, ob der Build reproduzierbar ist und ob der Freigabemechanismus begrenzt, was die geschützte Umgebung verlässt. ## Warum „Die Daten verlassen das Gerät nie“ nie genügte Föderiertes Lernen wird oft mit dem Satz erklärt, man bringe das Modell zu den Daten. Als Kurzfassung für das Grundprinzip ist das hilfreich, doch mehrere Fehlerquellen bleiben dabei unsichtbar. Ein Trainingsupdate kann Informationen über die Beispiele enthalten, aus denen es entstanden ist. Ein Aggregationsdienst kann Updates möglicherweise vor ihrer Zusammenführung einsehen. Ein böswilliger oder kompromittierter Koordinator könnte den Trainingscode verändern. Protokolle können verraten, wer wann oder wie häufig teilgenommen hat. Ein Modell ohne ausreichende Datenschutzgarantie kann Angreifern Rückschlüsse auf seinen Trainingsbestand erlauben. Selbst eine scheinbar private Zwischenstruktur kann Informationen leaken, wenn sie wiederholt abgefragt oder mit externem Wissen kombiniert wird. Deshalb verbindet datenschutzschonendes föderiertes Lernen üblicherweise mehrere Techniken, statt sich auf eine einzige zu verlassen. Secure Aggregation kann verhindern, dass der Koordinator einzelne Client-Updates sieht; allein garantiert sie aber nicht, dass das fertige Modell keine Informationen preisgibt. Differenzielle Privatsphäre setzt eine formale Grenze für den Einfluss der Daten einer Person oder Gruppe auf ein veröffentlichtes Ergebnis. Der Nutzenverlust hängt jedoch vom Workload, Datenvolumen, Stichprobendesign und Datenschutzbudget ab. TEEs können Code und Daten innerhalb eines Enklaven schützen, beseitigen aber weder Hardware-Schwachstellen noch Seitenkanäle, Implementierungsfehler, Fehler in der Schlüsselverwaltung oder einen zu weit gefassten Workload. Googles Ankündigung ist bedeutsam, weil sie diese Ebenen miteinander verknüpfen will. Das TEE kontrolliert Ausführung und Schlüsselvergabe. Policy und Transparenzprotokoll liefern eine Prüfspur. Differenzielle Privatsphäre begrenzt die veröffentlichten Modellgewichte. Reproduzierbare Builds schaffen eine Möglichkeit, Quellcode und eingesetzte Binärdateien zu vergleichen. Der Entwurf versucht, das Vertrauen in den Betreiber zu verringern und die verbleibenden Annahmen sichtbar zu machen. Der Vorbehalt ist wichtig. Google selbst beschreibt die Garantien der TEEs als abhängig von den Einschränkungen der aktuellen Generation. Das Unternehmen erklärt außerdem, dass datenschutzrelevante Logik im Python-Trainingsprogramm fest verdrahtet bleiben muss, wenn proprietäre Modellarchitekturen oder Vorverarbeitungsdetails dynamisch nachgeladen werden. Für Prüfer entsteht dadurch eine Grenze, die sie verstehen müssen: Nicht jeder Parameter und nicht jede Komponente eines Produktions-Workloads ist zwangsläufig genauso überprüfbar wie der Datenschutzmechanismus selbst. ## Der nützliche Wechsel von Serververtrauen zu Workload-Verifikation Bei der Beschaffung gehosteter KI wird traditionell gefragt, wo der Anbieter Daten speichert, wie lange er Prompts aufbewahrt, ob Kundeninhalte zum Training verwendet werden und welche Administratoren Zugriff auf die Umgebung haben. Diese Fragen bleiben notwendig. Wenn ein Dienst Berechnungen über verschlüsselten oder verteilten Daten ausführt, reichen sie jedoch nicht aus. Eine anspruchsvollere Prüfung fragt, was der Dienst technisch daran gehindert wird zu tun. Beispiele dafür sind: - Welche exakt bestimmten Programme dürfen Daten entschlüsseln und verarbeiten? - Können der Kunde oder ein unabhängiger Prüfer die Workload-Identität vor der Schlüsselvergabe verifizieren? - Ist die Autorisierung für einen Trainingslauf unveränderlich, oder kann ein privilegierter Betreiber sie später ändern? - Werden Policy-Änderungen in einem öffentlichen oder für Kunden sichtbaren Transparenzprotokoll festgehalten? - Werden die Trainings-Binärdateien reproduzierbar aus einsehbarem Quellcode erstellt? - Welche Informationen werden in jeder Phase veröffentlicht: einzelne Updates, aggregierte Updates, Metriken, Checkpoints, Embeddings oder nur ein fertiges Modell? - Welche Abrechnung für differenzielle Privatsphäre wird verwendet, und berücksichtigt sie wiederholte Veröffentlichungen über die Zeit? - Was passiert, wenn ein Worker ausfällt, ein Wiederherstellungs-Snapshot eingespielt oder ein Modell zurückgesetzt wird? Das sind operative Fragen, keine theoretische Dekoration. Ein System, das sie präzise beantwortet, lässt sich leichter steuern, weil seine Aussagen mit Artefakten abgeglichen werden können: signierten Binärdateien, Attestation-Aufzeichnungen, Schlüsselvergabeprotokollen, Datenschutzbilanzen, Quellcode-Repositories und Verfahren für Sicherheitsvorfälle. Wer nur eine allgemeine Zusicherung der Vertraulichkeit liefert, macht den Kunden weiterhin vom internen Prozess des Anbieters abhängig. Google nutzt Rekor für das Transparenzprotokoll und erklärt, dass KMS sowie die Binärdateien zur Datenverarbeitung reproduzierbar aus Open-Source-Code im Repository Confidential Federated Compute erstellt werden können. Das ist noch keine unabhängige Prüfung jeder Bereitstellung. Es gibt Prüfern aber mehr an die Hand als ein Absatz aus einer Richtlinie: einen Weg, die erlaubten Workloads zu untersuchen und die Implementierung mit dem beschriebenen Entwurf zu vergleichen. Die Unterscheidung ähnelt dem Unterschied zwischen einer verschlüsselten Datenbank und einer überprüfbaren Datenzugriffsrichtlinie. Verschlüsselung schützt Inhalte in bestimmten Zuständen. Eine Policy erklärt, wer zu welchem Zweck zugreifen darf. Verifikation gibt einer anderen Partei die Möglichkeit zu testen, ob das System diese Policy einhält. Reife Datenschutztechnik braucht alle drei Ebenen. ## Der praktische Vorteil, Berechnungen zurück auf den Server zu verlagern Der kontraintuitivste Teil von Googles Ankündigung ist, dass stärkere Datenschutzgarantien mit mehr serverseitiger Berechnung einhergehen können. Frühere föderierte Systeme hingen stark von Geräteverfügbarkeit, lokaler Rechenleistung, Netzwerkbedingungen und der Konkurrenz mit anderen Aufgaben ab. War eine nützliche Gruppe von Geräten nicht verfügbar, konnten Trainingsrunden länger dauern oder schwächere Ergebnisse liefern. Google zufolge brauchten einige frühere föderierte Gboard-Modelle ein bis zwei Monate für das Training. Die neue Architektur sammelt zunächst verschlüsselte Uploads und wählt anschließend innerhalb des geschützten Workloads einen serverseitigen Teilnahmeplan. So kann das System Geräteauswahl und Parameter der differenziellen Privatsphäre optimieren, nachdem die Verfügbarkeit bekannt ist. Der Ablauf wird nicht mehr vollständig davon bestimmt, welche Telefone zufällig online sind. Google berichtet, dass heute die Verfügbarkeit von TEE-Ressourcen und nicht die Berechnung auf den Geräten den Engpass bildet. Das ist ein wesentlicher technischer Zielkonflikt. Wenn Berechnungen auf Endpunkten bleiben, kann ein zentraler Dienst weniger sehen; zugleich werden Modellgröße, Algorithmuswahl, Energieverbrauch und Zeitplanung eingeschränkt. Werden Berechnungen in eine geschützte Serverumgebung verlagert, kann das Training planbarer werden und womöglich größere Modelle unterstützen. Die Datenschutzargumentation hängt dann von der Absicherung dieser Umgebung ab: Attestation, Schlüsselvergabe, Policy-Durchsetzung, Ausgabekontrollen und das Bedrohungsmodell für die Hardware. Für Unternehmen bedeutet das: „föderiert“ darf nicht als Synonym für „auf dem Gerät“ behandelt werden. Ein Produktionssystem kann eine verteilte Datensammelphase, eine verschlüsselte Transferphase, eine serverseitige Phase mit vertraulicher Berechnung und eine Phase zur differenziell privaten Veröffentlichung umfassen. Jede Phase hat eigene Fehlerbilder und Kosten. ## Was differenzielle Privatsphäre beiträgt — und was nicht Differenzielle Privatsphäre ist ein mathematischer Rahmen zur Quantifizierung von Datenschutzverlust. NIST beschreibt sie in [SP 800-226](https://csrc.nist.gov/pubs/sp/800/226/final) als Möglichkeit, zu untersuchen, wie sich die An- oder Abwesenheit der Daten einer Einheit auf ein Ergebnis auswirkt, warnt aber zugleich vor den zahlreichen Gefahren und Designentscheidungen realer Implementierungen. Praktisch begrenzt ein Training mit differenzieller Privatsphäre, wie stark die Daten eines Teilnehmers ein veröffentlichtes Ergebnis beeinflussen können. Übliche Verfahren beschneiden den Einfluss einzelner Updates und fügen kalibriertes Rauschen hinzu. Ein kleineres Datenschutzbudget bedeutet im Allgemeinen eine stärkere formale Garantie; zu viel Rauschen kann jedoch die Genauigkeit verringern. Der Zielkonflikt wird unter anderem durch die Zahl der Teilnehmer, die Wiederverwendung von Daten, die Datenschutzeinheit — Datensatz, Nutzer, Gerät oder Organisation — und die Zahl der veröffentlichten Ergebnisse bestimmt. Gerade der letzte Punkt wird leicht übersehen. Ein Modell kann für einen Trainingslauf eine Datenschutzgarantie besitzen, während eine Folge von Checkpoints, Analyse-Dashboards, Experimenten oder Modellvarianten zusätzliches Budget verbraucht. Die Organisation braucht daher eine Bilanz und eine Veröffentlichungsrichtlinie, nicht nur einen einmaligen Epsilon-Wert in einem Forschungspapier. Außerdem muss sie festlegen, wessen Privatsphäre geschützt wird. Datenschutz auf Nutzerebene ist eine andere Aussage als Datenschutz auf Ereignisebene; den Einfluss eines einzelnen Tastendrucks zu begrenzen ist nicht dasselbe wie den Einfluss aller Beiträge einer Person über Monate zu begrenzen. Differenzielle Privatsphäre löst auch keine Fragen der Daten-Governance vor dem Training. Sie entscheidet nicht, ob die Organisation eine rechtmäßige Grundlage für die Datenerhebung hatte, ob Betroffene über die Nutzung informiert wurden, ob die Labels fair sind oder ob das fertige Modell sicher eingesetzt werden kann. Sie verhindert nicht automatisch, dass ein autorisierter Workload das falsche Ziel lernt. Sie ist eine Einschränkung des Informationslecks aus Ergebnissen, kein Ersatz für Zweckbindung, Zugriffskontrolle, Aufbewahrungsregeln oder einen klaren Löschprozess. Die richtige Käuferfrage lautet deshalb nicht: „Wird hier differenzielle Privatsphäre verwendet?“ Sie lautet: „Was ist die Datenschutzeinheit, wie groß ist das Budget, welche Veröffentlichungen verbrauchen es, wer prüft die Abrechnung und welcher Nutzenverlust wurde für unsere Aufgabe gemessen?“ ## Wo TEEs helfen und wo Vertrauen bestehen bleibt Ein TEE kann den Bedarf verringern, Cloud-Betreibern während der Verarbeitung Klartextdaten anzuvertrauen. Das ist wertvoll, wenn der Anbieter Berechnungen ausführen muss, der Kunde aber verhindern möchte, dass gewöhnliche Host-Administratoren, benachbarte Mandanten oder der Betreiber die Daten einsehen. Remote Attestation kann die Entscheidung über eine Schlüsselvergabe an eine gemessene Softwareidentität knüpfen. Ein TEE ist jedoch keine magische Datenschutzbox. Käufer sollten mindestens fünf Anschlussfragen stellen. Erstens: Welche Hardware und Firmware fallen in den Geltungsbereich? TEEs hängen von Prozessorfunktionen, Firmware, kryptografischen Schlüsseln und Sicherheitsupdates des Herstellers ab. Das Bedrohungsmodell kann bestimmte privilegierte Akteure ausschließen oder voraussetzen, dass bestimmte Seitenkanäle nicht ausnutzbar sind. Zweitens: Welcher Code wird gemessen und attestiert? Die Antwort sollte die Betriebsumgebung, die Schlüsselverwaltungslogik, das Trainingsprogramm, relevante Bibliotheken und dynamisch geladene Komponenten einschließen. Wird nur ein kleiner Launcher gemessen, während wichtige Datenschutzlogik später nachgeladen wird, kann die Attestation deutlich enger sein, als es zunächst klingt. Drittens: Wie werden Geheimnisse freigegeben? Die Schlüsselverwaltung sollte an einen zugelassenen Workload und eine ausdrückliche Policy gebunden sein. Ein menschlicher Administrator, der diese Entscheidung überschreiben kann, gehört zum Bedrohungsmodell, selbst wenn der normale Weg kryptografisch eingeschränkt ist. Viertens: Was lässt sich aus Metadaten ableiten? Zeitabläufe, Gruppenzugehörigkeit, Anfragegröße, Fehlermuster und Veröffentlichungszeitpunkte können Informationen tragen, auch wenn Nutzdaten verschlüsselt sind. Eine Datenschutzprüfung sollte deshalb den Datenverkehr und die operativen Metadaten abdecken, die jeder Beteiligte sehen kann. Fünftens: Was geschieht bei der Reaktion auf einen Vorfall? Ein kompromittierter Host, eine widerrufene Messung, ein verwundbarer Enklave oder eine fehlerhafte Build-Pipeline verlangen eine praktische Reaktion: Schlüsselvergabe stoppen, Schlüssel rotieren, Workloads ungültig machen, Beweise sichern und klären, ob bereits veröffentlichte Ergebnisse weiterhin vertrauenswürdig sind. Ein System, das nur dann privat ist, wenn nichts schiefgeht, ist noch nicht für sensible Produktion bereit. Auch frühere NIST-Leitlinien zum datenschutzschonenden föderierten Lernen zeigen dieses Prinzip. In der Diskussion über Private Set Intersection und Bloom-Filter weist NIST darauf hin, dass Techniken zum Abgleich von Daten weiterhin Trefferinformationen preisgeben können und stärkere Schutzmaßnahmen oft Leistungskosten verursachen. Die Konsequenz lautet nicht, solche Techniken abzulehnen. Ihre Leaks müssen in das Bedrohungsmodell aufgenommen und ausdrücklich daraufhin bewertet werden, ob sie akzeptabel sind. ## Der Einführungsaufwand ist erheblich Ein Unternehmen kann diese Architektur nicht aktivieren, indem es in einer gewöhnlichen KI-API einen Datenschutzschalter umlegt. Die schwierige Arbeit beginnt vor dem Training. Das Team muss Dateninhaber, Datenschutzeinheit, erlaubten Zweck, Aufbewahrungsgrenzen und die Ergebnisse definieren, die die geschützte Umgebung verlassen dürfen. Es muss entscheiden, ob Clients Beispiele, Gradienten, Merkmale oder eine andere Repräsentation hochladen. Außerdem braucht es einen Attestation-Pfad, einen Schlüsselverwaltungsdienst, ein Policy-Format, ein Transparenzprotokoll, eine reproduzierbare Build-Pipeline und einen Datenschutz-Abrechnungsmechanismus — selbst entwickelt oder übernommen. Wiederherstellung und Widerruf müssen getestet werden. Ebenso muss die Beziehung zwischen Confidential Computing und rechtlichen oder vertraglichen Pflichten dokumentiert werden. Die technische Oberfläche ist breiter als ein Trainingsskript. Eine Produktionsbereitstellung benötigt Client-Bibliotheken, Mechanismen für Registrierung und Updates, kryptografische Identitäten, Workload-Planung, Observability ohne übermäßige Sammlung sensibler Metadaten, Kontrollen für die Software-Lieferkette und eine Möglichkeit, die gemessene Bereitstellung mit dem geprüften Quellcode zu vergleichen. Organisationen, die bereits mobile Infrastruktur, Geräteflotten, Confidential-Computing-Cluster oder regulierte Datenpipelines betreiben, sind besser vorbereitet als Teams, die von einem einzelnen Notebook ausgehen. Kosten entstehen an mehreren Stellen. TEEs erfordern kompatible Hardware, können verfügbare Kapazität verringern und den Zugang zu Beschleunigern komplizierter machen. Attestation- und Schlüsselverwaltungsdienste schaffen zusätzliche betriebliche Abhängigkeiten. Öffentliche Protokollierung und reproduzierbare Builds verlangen Release-Disziplin. Differenzielle Privatsphäre kann mehr Teilnehmer, mehr Runden oder mehr Daten erfordern, um eine akzeptable Genauigkeit zu erreichen. Prüfungen und Red-Team-Arbeit werden zu laufenden Kosten und nicht nur zu einer Aufgabe vor dem Start. Die Architektur kann dennoch günstiger sein als eine Zentralisierung, wenn diese eine nicht akzeptable rechtliche, sicherheitstechnische oder vertragliche Angriffsfläche schaffen würde. Automatisch günstiger als konventionelles Training ist sie aber nicht. Verglichen werden muss der Gesamtaufwand für ein erfolgreiches und regelkonformes Modell: Infrastruktur, Entwicklung, Audits, Leistungseinbußen, Vorbereitung auf Vorfälle und der Wert des Zugangs zu Daten, die nicht in gewöhnlicher Form zusammengeführt werden dürfen. ## Für wen sich der Ansatz eignet Dieses Muster ist besonders vielversprechend, wenn Daten aus einem konkreten Grund verteilt sind und die Lernaufgabe davon profitiert, Signale mehrerer Teilnehmer zu kombinieren. Beispiele sind Personalisierung auf Geräten, Betrugserkennung zwischen Organisationen, klinische Forschung, bei der Institutionen keine Rohdaten teilen können, sowie industrielle oder im Feld erhobene Daten, die unter lokaler Kontrolle bleiben. Der Ansatz ist ein starker Kandidat, wenn der wichtigste Einwand gegen zentrales Training nicht bloß eine Präferenz für einen Anbieter ist, sondern eine konkrete Gefährdung: ein vertragliches Verbot, eine besonders schutzbedürftige Bevölkerungsgruppe, eine regulatorische Einschränkung oder eine glaubwürdige Bedrohung durch Insider und kompromittierte Infrastruktur. In solchen Situationen kann überprüfbare Workload-Autorisierung die Risikobewertung spürbar verändern. Er ist außerdem interessant, wenn ein Käufer gegenüber Prüfern oder Partnern eine belastbare Antwort braucht. Transparenzprotokoll, reproduzierbarer Build, Attestation-Aufzeichnung und Datenschutzbilanz erzeugen Belege, die später geprüft werden können. Sie beantworten nicht jede Frage, verbessern aber die Qualität des Gesprächs zwischen Entwicklung, Sicherheit, Recht und Datenverantwortlichen. Ein kleiner Pilot sollte mit einer Aufgabe beginnen, bei der Datenschutzeinheit und Erfolgsmetrik eindeutig sind. Die Vorhersage des nächsten Wortes ist ein bequemes Beispiel, weil Genauigkeit, Trainingsgeschwindigkeit, Teilnahme und Datenschutzabrechnung über wiederholte Runden gemessen werden können. Ein Unternehmen sollte einen ähnlich klar begrenzten Workflow wählen: ein enges Klassifikationsproblem, eine überschaubare Zahl beteiligter Organisationen und einen definierten Veröffentlichungsrhythmus. Der Pilot sollte das geschützte Design mit einer konventionellen Baseline vergleichen und Nutzen, Latenz, Kosten, Leaks und Betriebsaufwand dokumentieren. ## Für wen der Ansatz vorerst nicht passt Ein Team sollte diese Architektur wahrscheinlich nicht als Erstes wählen, wenn es kein Problem mit verteilten Daten gibt. Sind alle relevanten Daten bereits für die zentrale Nutzung freigegeben, kann eine gut kontrollierte Private Cloud oder isolierte Trainingsumgebung einfacher abzusichern und zu erklären sein. Föderiertes Lernen bringt Koordination und kryptografische Mechanismen hinzu; standardmäßig ist es kein Datenschutz-Upgrade. Ungeeignet ist der Ansatz auch, wenn die Daten zu knapp oder zu ungleich verteilt sind, um nützliches Training zu tragen. Differenzielle Privatsphäre braucht Teilnahme und sorgfältige Abrechnung. Ein System mit nur wenigen Beitragenden kann zwar eine formale Garantie liefern, aber ein Modell erzeugen, das zu verrauscht, verzerrt oder instabil für den Einsatz ist. Organisationen, die keine Software-Lieferkette, kein Schlüsselverwaltungssystem oder keinen Prozess für Sicherheitsvorfälle betreiben können, sollten ein TEE-basiertes Design nicht als Abkürzung verstehen. Confidential Computing verlagert Verantwortung; es beseitigt sie nicht. Kann das Team Workload-Änderungen nicht prüfen, Schlüssel nicht widerrufen, das Datenschutzbudget nicht verfolgen oder Metadaten-Leaks nicht untersuchen, kann die Architektur einen komplizierteren und schwerer zu steuernden Fehler schaffen. Schließlich ist Vorsicht geboten, wenn das gewünschte Ergebnis eine folgenreiche Entscheidung über einzelne Personen ist. Datenschutz beantwortet weder Fragen der Diskriminierung und Anfechtbarkeit noch der Datenqualität oder der notwendigen menschlichen Prüfung. Ein privates Modell kann weiterhin eine ungerechte Entscheidung treffen. ## Checkliste für überprüfbares privates Training Vor dem Abschluss mit einem Dienst für föderiertes Lernen sollte der Anbieter die folgenden Fragen schriftlich beantworten und möglichst Belege beifügen: 1. **Was genau ist privat?** Bezieht sich die Garantie auf Rohdaten, einzelne Updates, Beiträge auf Nutzerebene, das fertige Modell oder auf alle diese Ebenen? 2. **Wie lautet das Bedrohungsmodell?** Umfasst es den Dienstbetreiber, Cloud-Administratoren, kompromittierte Clients, böswillige Teilnehmer, kollaborierende Parteien und Hardwareangriffe? Welche Angriffe sind ausdrücklich ausgeschlossen? 3. **Was wird durch Kryptografie oder Hardware erzwungen?** Vertragliche Versprechen müssen von Kontrollen getrennt werden, die einen Betreiber tatsächlich daran hindern, Daten zu lesen oder einen Workload zu verändern. 4. **Wie funktioniert die Attestation?** Verlangt werden sollten die gemessenen Komponenten, das Prüfverfahren, die Bedingungen für die Schlüsselvergabe und der Widerrufsprozess. 5. **Kann die Datenschutzlogik geprüft werden?** Zu klären ist, ob Quellcode, Abhängigkeiten, Build-Prozess, Policy-Dateien und Messwerte der Bereitstellung eingesehen werden können. 6. **Wie wird das Datenschutzbudget berechnet?** Zu bestätigen sind Datenschutzeinheit, Abrechnungsmethode, Zusammensetzung über Veröffentlichungen hinweg, Annahmen zur Stichprobe sowie der Umgang mit Wiederholungen und Wiederherstellung. 7. **Was verlässt die geschützte Umgebung?** Dazu gehören Metriken, Checkpoints, Embeddings, Fehler, Protokolle, Zeitdaten, Gruppenstatistiken und Support-Artefakte. 8. **Was verrät die Teilnahme?** Es muss geklärt werden, ob ein Koordinator oder ein anderer Teilnehmer ableiten kann, dass ein bestimmtes Gerät, ein Mitarbeiter, eine Organisation oder eine Patientengruppe beigetragen hat. 9. **Was passiert, wenn das Modell falsch liegt?** Datenschutz- und Nutzentests sollten Gruppenleistung, Drift, Widerstandsfähigkeit gegen Vergiftung und einen Rücksetzungsplan einbeziehen. 10. **Was kostet der Betrieb in der Zielgröße?** Einzupreisen sind TEE-Kapazität, Speicher, Schlüsselverwaltung, Protokollierung, Prüfaufwand, Client-Updates, Wiederholungen und der Genauigkeitsverlust durch stärkeren Datenschutz. Kann ein Anbieter diese Fragen nicht beantworten, kann der Dienst für risikoarme Experimente weiterhin nützlich sein. Als nachgewiesene Kontrolle für sensible Produktionsdaten sollte er dann nicht behandelt werden. ## Die größere Lehre für die KI-Beschaffung Googles Ankündigung ist keine Erklärung, dass vertrauenswürdige Hardware privates maschinelles Lernen gelöst habe. Sie zeigt, dass die Datenschutzgrenze operativer wird. Der Wert des Systems liegt in der Verbindung mehrerer Mechanismen: verschlüsselte Aufnahme, eingeschränkte Schlüsselvergabe, attestierte Ausführung, überprüfbare Policies, reproduzierbare Software, differenzielle Privatsphäre und kontrollierte Veröffentlichung. Entfernt man einen davon, wird auch die Aussage enger. Der Wandel verändert zudem, was Unternehmen messen sollten. Ein datenschutzschonendes KI-Projekt sollte mehr ausweisen als Modellgenauigkeit und Infrastrukturkosten. Es sollte dokumentieren, wer was sehen konnte, welche Workloads autorisiert waren, wie viele Informationen veröffentlicht wurden, wie sich das Datenschutzbudget verändert hat, wie sich das System bei Fehlern verhielt und welche Nachweise ein unabhängiger Prüfer verifizieren kann. Das ist ein anspruchsvollerer Maßstab als „Wir trainieren nicht mit Ihren Daten“, aber auch ein nützlicherer. Das Versprechen des verteilten Lernens wird glaubwürdig, wenn der Dateninhaber die erlaubte Berechnung untersuchen kann, der Betreiber nicht heimlich einen anderen Workload einsetzen kann und das Endergebnis mit dokumentierten Datenschutzkosten verbunden ist. Für KI-Käufer lautet der unmittelbare Rat daher: Behandelt föderiertes Lernen als System- und Beschaffungsentscheidung, nicht als Modellfunktion. Zuerst muss feststehen, welche Informationen geschützt bleiben müssen, welchen Parteien nicht vertraut werden darf und welche Nachweise ein Prüfer braucht. Danach ist zu testen, ob die vorgeschlagene Architektur diese Grenzen tatsächlich durchsetzt. Googles neuer Gboard-Einsatz zeigt, dass sich der Ansatz im Produktionsmaßstab technisch umsetzen lässt. Die schwierigere Frage für alle anderen lautet, ob der Datenschutzgewinn den Aufwand rechtfertigt — und ob die Organisation bereit ist, das System verlässlich und ehrlich zu betreiben. ## Quellen Die faktischen Aussagen zur Architektur, zu Googles Gboard-Einsatz und zur Produktionsbereitstellung stützen sich auf [Googles Forschungsankündigung](https://research.google/blog/toward-provably-private-learning-from-federated-data/) und das dazugehörige [Paper auf arXiv](https://arxiv.org/abs/2609.31494). Für die Einordnung differenzieller Privatsphäre wurde [NIST SP 800-226](https://csrc.nist.gov/pubs/sp/800/226/final) herangezogen. Ergänzenden Kontext zu Datenschutzrisiken beim föderierten Lernen bietet NISTs Beitrag [Protecting Model Updates in Privacy-Preserving Federated Learning: Part Two](https://www.nist.gov/blogs/cybersecurity-insights/protecting-model-updates-privacy-preserving-federated-learning-part-two).