Le processus commence sur l’appareil : celui-ci chiffre localement les exemples d’entraînement et y joint une politique d’accès qui précise quelles charges de travail côté serveur sont autorisées à déchiffrer et à traiter les données. Ces politiques sont publiées dans un journal public de transparence. Côté serveur, un ensemble de TEE met en œuvre un KMS qui exige une attestation à distance et la conformité aux politiques avant de remettre les clés de déchiffrement à un TEE racine. Ce dernier exécute une boucle d’entraînement Python et répartit les tâches en parallèle entre des TEE de calcul. Comme les données en clair ne sont présentes qu’à l’intérieur des TEE attestés et que l’accès aux clés est soumis aux politiques, les auditeurs peuvent suivre l’accès aux données, depuis leur téléversement par l’appareil jusqu’à leur traitement dans le TEE.

La publication des politiques d’accès et la possibilité de reproduire les versions constituent le maillon essentiel d’un audit concret. Les auditeurs peuvent vérifier dans les entrées du journal public quelles charges de travail étaient autorisées à accéder aux données, puis recompiler indépendamment les binaires du KMS et de traitement à partir du code source pour confirmer qu’ils sont identiques bit à bit aux images attestées. Cela réduit considérablement l’opacité, ou l’effet « boîte noire », qui a freiné les premières approches d’apprentissage fédéré côté serveur, et fournit un registre public reliant le consentement donné sur l’appareil, le code autorisé et les binaires exécutés dans les TEE.

Même lorsque l’exécution du code est attestée et vérifiable, la protection de la vie privée exige de limiter les résultats publiés. Le système de Google ne rend visibles que des métriques et des poids de modèle protégés par la confidentialité différentielle ; les données des appareils en clair et les gradients intermédiaires restent confinés aux TEE. Cette double approche — exécution confidentielle et confidentialité différentielle pour les résultats publiés — contribue à concilier utilité et protection démontrable de la vie privée. Elle repose toutefois sur une mise en œuvre correcte de la confidentialité différentielle dans le programme attesté et sur un réglage minutieux du bruit, de la taille des cohortes et des méthodes d’échantillonnage.

Les TEE renforcent la confidentialité et l’intégrité, mais ne constituent pas une solution miracle. Les TEE actuels restent vulnérables à certaines observations par canal auxiliaire, et le chargement dynamique — utilisé pour préserver la confidentialité des éléments propriétaires des modèles — élargit la surface d’attaque s’il n’est pas strictement encadré. Google reconnaît ces limites et estime qu’il est nécessaire de conserver toute la logique touchant à la confidentialité dans le programme Python attestable, en ne chargeant dynamiquement que des entrées bien auditées. Les auditeurs doivent donc vérifier non seulement le programme attesté, mais aussi la provenance des éléments chargés dynamiquement et le périmètre auquel ils sont destinés.

Pour les équipes produit, cette architecture propose une méthode claire pour entraîner des modèles utiles sur des données sensibles sans devoir faire aveuglément confiance à l’opérateur : publier les politiques d’accès, permettre la reproduction des versions, conditionner la remise des clés à une attestation et ne diffuser que des résultats traités par confidentialité différentielle. Les auditeurs devraient mettre au point des outils qui comparent automatiquement les entrées des journaux, les attestations et les artefacts reconstruits. Les organisations qui évaluent des conceptions similaires devraient prévoir le coût des capacités TEE, investir dans des mesures d’atténuation des canaux auxiliaires et mettre en place une gouvernance reliant le consentement sur l’appareil à la portée des politiques d’accès.