O novo fluxo começa no dispositivo: os aparelhos criptografam localmente os exemplos de treinamento e anexam uma política de acesso que especifica quais cargas de trabalho no servidor podem descriptografar e processar os dados. Essas políticas são publicadas em um registro público de transparência. No servidor, um conjunto de TEEs implementa um KMS que exige atestação remota e correspondência com as políticas antes de fornecer chaves de descriptografia a uma TEE raiz. A TEE raiz executa um ciclo de treinamento em Python e distribui tarefas paralelas às TEEs de trabalho. Como os dados em texto claro só existem dentro de TEEs atestados e as chaves são liberadas conforme as políticas, os auditores podem rastrear o acesso aos dados desde o upload do dispositivo até o processamento dentro da TEE.

A publicação das políticas de acesso e o suporte a compilações reproduzíveis são os elementos que tornam possível uma auditoria efetiva. Ao consultar as entradas do registro público, os auditores podem verificar quais cargas de trabalho foram autorizadas a acessar os dados. Também podem compilar por conta própria os binários do KMS e de processamento a partir do código-fonte e confirmar que são idênticos, bit a bit, às imagens atestadas. Isso reduz significativamente o problema da “caixa-preta” que dificultava abordagens anteriores de aprendizado federado no servidor e cria um registro público que conecta o consentimento no dispositivo, o código autorizado e os binários executados nas TEEs.

Mesmo quando a execução do código é atestada e auditável, as garantias de privacidade exigem limites para os resultados divulgados. O sistema do Google restringe os artefatos visíveis a métricas e pesos de modelo protegidos por privacidade diferencial; os dados dos dispositivos em texto claro e os gradientes intermediários permanecem confinados às TEEs. Essa abordagem dupla — execução confidencial e privacidade diferencial nos resultados divulgados — ajuda a conciliar utilidade e privacidade comprovável, mas depende da implementação correta da privacidade diferencial dentro do programa atestado e do ajuste cuidadoso do ruído, do tamanho dos grupos e das estratégias de amostragem.

As TEEs reforçam a confidencialidade e a integridade, mas não são uma solução infalível. As TEEs atuais são vulneráveis a certos tipos de observação por canais laterais, e o carregamento dinâmico de componentes — usado para manter privados elementos proprietários do modelo — amplia a superfície de ataque se não for cuidadosamente limitado. O Google reconhece essas limitações e argumenta que é necessário manter toda a lógica relevante para a privacidade dentro do programa Python atestável, permitindo o carregamento dinâmico apenas de entradas bem auditadas. Portanto, os auditores devem verificar não só o programa atestado, mas também a procedência dos artefatos carregados dinamicamente e o escopo para o qual foram concebidos.

Para as equipes de produto, essa arquitetura oferece um roteiro claro para treinar modelos úteis com dados sensíveis sem exigir confiança cega no operador: publicar políticas de acesso, oferecer suporte a compilações reproduzíveis, liberar chaves somente após a atestação e divulgar apenas resultados processados com privacidade diferencial. Os auditores devem criar ferramentas que comparem automaticamente entradas de registros, atestações e artefatos recompilados. Organizações que avaliam projetos semelhantes devem prever recursos para a capacidade das TEEs, investir em medidas contra canais laterais e estabelecer uma governança que associe o consentimento no dispositivo às regras das políticas de acesso.