Google announced on October 2, 2026 that its TEE-based federated learning system already trains English and Japanese Gboard next-word prediction models. For AI teams evaluating privacy-preserving training, the important addition is an inspectable link between permitted data use and the software allowed to carry it out.
The announcement is dated October 2 in Google’s official feed; the underlying preprint first appeared on September 25 and was revised on September 30. Neither date establishes when the production deployment began.
Four protections, four different questions
“Federated,” “encrypted” and “differentially private” describe different properties. They should not be treated as interchangeable assurances.
Layer | What it does | What still needs checking |
|---|---|---|
Trains locally and sends model updates for aggregation instead of uploading training examples. | Where updates go and what the aggregation process or resulting model could reveal. | |
Conceals individual updates from the aggregation server while allowing a combined result. | What can be learned from the aggregate and subsequent releases. | |
Uses bounded contributions and calibrated noise to limit an individual’s influence on released results. | The protected unit, privacy budget and accounting across releases. | |
Restricts access to protected computation and provides evidence of the software running there, under hardware assumptions. | Whether that software implements the promised privacy rules correctly. |
Secure aggregation and differential privacy can be combined: Google has documented a deployed system using both. The new architecture is not evidence that these protections are universally incompatible.
What the public audit trail exposes
Devices upload encrypted training examples for processing inside trusted execution environments under a pre-authorized access policy. This differs from sending only locally computed model updates. Google describes public policies that identify permitted Python training workloads.
The key management service, or KMS releases decryption keys only to authorized, attested software. Policies may permit several pipelines and versions, so an audit must cover the entire allowed set—not just one sample program.
The practical review sequence, drawn from the project’s inspection documentation, is:
Identify the policy. Use client attestation records or logged endorsements to establish which processing applications are allowed. These are complementary ways to inspect the system.
Connect binaries to source. Trace the KMS and permitted transformations through their firmware, kernel and application layers. The endorsement guide explains how log entries lead to artifact digests and build provenance.
Review the privacy logic. Check the contribution limits, noise and release rules in the identified workload. Knowing which program ran is not the same as establishing that its algorithm is correct.
Rekor’s transparency log supplies an append-only record with inclusion and consistency checks. It makes claims inspectable; it does not certify privacy-algorithm correctness or show that an independent audit has happened. A permitted workload is also not proof that a particular phone participated in it.
This extends earlier work: Google’s March 2025 confidential federated analytics announcement already described TEE-backed Gboard word discovery. The present development applies the approach to model training.
What Google’s reported results show
In an English-model A/B experiment with 3.5 million devices per arm, Google reports a zCDP privacy budget of 0.215 for the best TEE-based arm versus 0.641 for the production baseline, adjusted to the same MF-DP-FTRL mechanism. Words Per Minute and Words Modified Ratio were neutral. Training took three weeks versus two months.
Calculation from those reported budgets: (0.641 − 0.215) ÷ 0.641 × 100 ≈ 66.5% lower. This compares the source’s privacy-accounting values; it is not a 66.5% reduction in breach probability, and zCDP is not interchangeable with epsilon.
The result supports a narrower conclusion than a universal accuracy or speed claim: a lower reported privacy budget with neutral measured usability in that comparison. The paper describes models up to 10 million parameters and one configuration tested per model. It does not demonstrate frontier-scale training.
The limits an audit must retain
Google allows proprietary model or preprocessing information to be loaded into a workload while keeping privacy-relevant logic inspectable. Its announcement explicitly retains current TEE and side-channel limitations and describes complete software-correctness proofs as future work. Auditors still need to assess the boundary around privately loaded components.
Retention is a separate issue. The KMS design says time-to-live enforcement is best-effort and not verifiable because expiry depends on observed, untrusted system time. A configured retention period should therefore not be presented as an unconditional, independently verified deletion deadline.
Recovery also affects privacy accounting. The KMS keeps rollback-protected pipeline state alongside decryption keys and can require a state update before releasing an output. For buyers, the implication is concrete: include retries and recovery in the review of release rules. Restarting a job must not silently create a fresh allowance for additional disclosures.
Decide whether this data flow fits your requirements
Start with the rule your organization actually needs to satisfy:
If training examples must remain on-device: encrypted upload is still upload. Evaluate a local-training architecture against that requirement rather than accepting the word “federated” as sufficient.
If protected server processing is acceptable: request the policy, all authorized versions, build provenance or rebuild evidence, attestation checks and a workload-level privacy assessment. Assign responsibility for monitoring policy changes.
If retention deadlines are decisive: obtain separate evidence for expiry and deletion. Do not substitute proof of permitted processing for proof of when access ends.
The same need to distinguish deployment location from actual data flows appears in the IBM Bob self-hosted deployment analysis, although that article concerns inference rather than federated training.
As of October 2, the Confidential Federated Compute repository offers Apache-2.0 components and explicitly disclaims official Google product support. The reviewed materials do not announce a commercial API, price or SLA for this system. Exact Gboard device, version and country coverage are not established by the announcement.
Methodology: This AI-assisted analysis draws on Google’s announcement, the September 30 preprint revision and public documentation pinned to repository commit 12d28177cf19e61b0097c6eeadab29bc8ad5da78. Results are Google-reported. No binaries were rebuilt, production attestations checked or hands-on privacy audit performed.