Where training runs and who can read its inputs are different privacy questions.
Google’s October 2, 2026 research announcement describes a federated-learning system that moves much of the training work to protected servers. Devices upload encrypted training examples. This does not mean all training data stays on the phone.
What the protected server does
The Google Research explanation describes trusted execution environments, or TEEs. These hardware-backed environments restrict access to running code and data. Remote attestation helps verify which software is running before the system releases decryption keys.
Google combines those controls with differential privacy, which limits what released results can reveal about individual contributions. Encryption protects access to inputs. Differential privacy addresses disclosure through outputs. Neither term, on its own, describes the whole system.
What the paper reports
The research preprint reports a Gboard experiment with 3.5 million devices in each arm. The tested TEE-trained model used a privacy-budget value of 0.215, compared with 0.641 for the adjusted baseline. Google reports neutral results on the specified typing metrics. This is company-reported evidence, not an independent security audit.
Those values differ by about threefold within the paper’s privacy-accounting setup. They are not a universal measure that every user is three times more private. The paper describes models up to 10 million parameters; training much larger models remains future work.
The guarantees have boundaries.
The design depends on TEE hardware and its security assumptions. The paper also identifies information outside encrypted content: the operator can see which uploads are used. Its key-expiration mechanism is best effort so that an absolute deletion promise would overstate the evidence.
Published code and transparency logs help reviewers examine the allowed program. They do not remove the need to inspect its inputs, outputs, and policy. A verified binary can still implement an unsuitable data policy.
Questions to ask before adopting this design
- Which examples leave the device, and what remains visible as metadata?
- Which program can decrypt them, and how is that version verified?
- What privacy budget applies to released results and repeated runs?
- How do key expiry and recovery behave during failures?
- Who reviews the hardware assumptions and the application’s output policy?
This is a proposed procurement and engineering checklist, not certification of Google’s deployment. Record answers as evidence rather than accepting a confidential-computing label. For related review practices, see our AI-content source checklist and guide to interpreting agent metrics.
