On October 2, 2026, Google Research introduced federated learning with verifiable server-side processing: devices send encrypted examples, and computations run in trusted execution environments, or TEEs. The main business takeaway from the announcement: where compute happens should be evaluated together with evidence of which code can access the data. Source: Google Research.
Prepared by the editorial team of AIrassvet for IT leaders, AI project owners, and data teams. First version — October 3, 2026. We review the architecture and acceptance questions; system deployment and the legal assessment of personal data processing require separate work. The editorial team did not conduct its own TEE tests, binary builds, or Gboard experiments.
Contents:
- What changed in federated learning
- Three different privacy proofs
- What the Gboard experiment showed
- Where the guarantees stop
- What materials to request from the vendor
- How to apply the findings to an enterprise project
- Frequently asked questions
- How AIrassvet helps prepare data for AI
- Conclusion
What changed in federated learning
Federated learning is joint model training on data from many participants, coordinated by a service. In Google’s new system, the client pre-approves a policy for permitted computations. Keys are managed by KMS, a key management service in the TEE; it issues them only to approved compute components. Policies are published in a transparency log, and training is split between a root node and worker TEEs. Google says the system was used for English and Japanese Gboard next-word prediction models. Google description.
So the promise that “data always stays on the device” would be inaccurate for this architecture. When discussing an enterprise project, it is more useful to map the path of a specific field: where it appears, who authorizes processing, where decryption happens, and what result leaves the system. That diagram shows what question to ask the engineer and what document is needed for the answer.
The news was published on October 2, but the preprint appeared on September 25; the version under review, v3, is dated September 29, 2026. A publication on arXiv does not by itself confirm peer review in a scientific journal. Version card.
Three different privacy proofs
TEE protects execution, attestation verifies the running component, and differential privacy limits leakage through the published result. These layers should be checked separately. Differential privacy, or DP, is a mathematical approach to quantifying privacy loss when a participant’s data is included in a dataset; NIST separately describes errors that arise in practical implementation. NIST SP 800-226.
The Confidential Federated Compute repository describes the relationship between encryption, access policy, and remote attestation — verification of which binary file is running. The documentation also links verification records to a reproducible build. The repository itself includes a disclaimer: it is not an officially supported Google product. Having source code does not confirm that the service is ready for a specific customer. Project README.
Rekor stores signed metadata in an append-only, tamper-evident log and allows other participants to query it. Sigstore documentation. The editorial conclusion: a log entry helps verify the published artifact, but it does not replace review of its contents. Acceptance requires both a link to the record and an explanation of why the recorded code meets the company’s requirement.
What the Gboard experiment showed
Section 5.3 of the preprint describes an A/B test of the English model: each experimental group included 3.5 million devices. The best TEE variant used a zCDP budget of 0.215 versus 0.641 for the production model after conversion to the same MF-DP-FTRL mechanism. The authors characterize the difference as roughly threefold. Words Per Minute and Words Modified Ratio remained neutral; training took three weeks instead of two months for the previous production model. Preprint v3, section 5.3.
This is the authors’ result for a specific keyboard model. It does not mean “three times lower chance of leakage” and does not promise the same acceleration for enterprise training. zCDP is a parameter of a mathematical guarantee, not a percentage of security. In section 6.1, the authors mention models with up to 10 million parameters; scaling to significantly larger models is discussed as future work. Preprint v3.
For a project leader, the practical takeaway is this: before rolling a number into the budget, request a comparable experiment on your own task. Lock in the same acceptance set, quality metric, compute cost, and full preparation timeline. Speeding up one stage does not show the duration of the whole project if data collection and approvals take longer.
Where the guarantees stop
In the technical paper, the TTL for decryption availability is described as being provided by KMS on a best-effort basis; that is not the same as proving physical deletion of all copies. Responsibility for anonymizing the output rests with the program author. Preprint, sections 3.1 and 4.1. In the Google blog, the limitations of modern TEEs, side channels, and the condition are noted separately: privacy-critical logic must remain in the verifiable program during dynamic loading of information. Google Research.
For enterprise acceptance, this leads to different questions. If the vendor describes only retention time, ask about key behavior and the ability to reprocess. If they show only attestation, ask about the program’s allowed outputs. If a specific version is confirmed, find out what happens during updates and who approves the new policy.
It is also important to distinguish technical protection from data-transfer permissibility. This article does not provide a conclusion on compliance with Russian law: processing regions, contractual terms, and the legal basis for using each dataset must be checked separately. Based on the sources reviewed, the price, availability of an enterprise offering, and the terms for using Google’s new system in Russia have not been established.
What materials to request from the vendor
The table below is an editorial checklist of questions for evaluating the offering. It is not a completed audit of Google’s system or a security certificate.
| Vendor promise | Material to verify | Action if evidence is insufficient |
|---|---|---|
| Approved code gets access | Program version, access policy, binary hash, and attestation record | Do not treat the link between the approved version and execution as verified |
| The result remains private | Definition of the protected unit, DP mechanism, parameters, and accounting for output release | Ask the engineer to explain the guarantee in terms of a specific dataset |
| Access is time-limited | Key expiration period, behavior on failures, and description of residual copies | Separate the end of decryption from deletion in the acceptance criteria |
| Training will become faster | A comparable experiment on an approved task and full cycle | Do not roll the Gboard result into the financial plan |
| The system is ready for production use | Supported components, updates, limitations, and each party’s responsibilities | Start by checking applicability, then discuss implementation |
A useful response format is “requirement → artifact → version → reviewer → decision.” Fill it out for every material claim. If evidence is missing, mark it clearly and assign an owner to obtain it; a general presentation should not use one checkmark to cover several different questions.
You can start the review with the simplest chain. Choose one permitted program output, determine which field is involved in producing it, then trace the processing rules through to the released result. After that, add the remaining outputs and updates. This sequence helps keep the review scope manageable, but it does not guarantee completeness.
How to apply the findings to a corporate project
Suppose a company wants to improve a support ticket classifier using branch data. This is a hypothetical scenario, not a client case. First, the team should decide whether training on distributed data is really necessary: it may be possible to validate the task on an already approved anonymized sample. The architecture should be chosen after defining the goal and constraints, not based on how well known the technology is.
Suggested preparation sequence:
- Define the decision the model is meant to support and the acceptable output, for example, a ticket category for routing.
- List the fields required for this task and separately agree on which information will be excluded.
- Document the current processing method, the set of acceptance examples, and who is responsible if classification is wrong.
- Compare deployment options with data constraints and the available evidence of protection.
- Agree on the stop condition: what missing evidence or quality drop will prevent a move to production.
There is no universal accuracy threshold or pilot length here: those cannot be inferred from Google’s news release. For preparing a sample set, the material on preparing data before AI deploymentwill be useful, and questions about not storing requests are covered separately in the article on Zero Data Retention.
This analysis compares a dated news item, a v3 preprint, code documentation, and materials from NIST and Sigstore. The figures come from Section 5.3 of the authors’ paper; the table and scenario are the editors’ suggestions. If you find an error, you can report it through the contacts on the AIrassvet website, including the section and the original source.
Answers to common questions
Do data remain on the phone in the new federated learning setup?
In the system described by Google, encrypted training examples are uploaded to the server. When evaluating the proposal, you need to verify the allowed ways they are processed and how results are produced. The promise that no data are transferred cannot be inferred from the word “federated.”
Does TEE prove the security of the entire AI system?
For an implementation decision, one TEE label is not enough. The team needs proof of the access policy, the running version, output handling, and hardware limitations. The scope of this evidence should be agreed before acceptance.
Can Gboard figures be used to calculate ROI?
Without a comparable experiment on your own task, they should not be carried over into the calculation. The keyboard model result is useful as a reason to request a review, but it does not determine the cost, quality, or timeline of a corporate project.
Does open-source code confirm that a product is ready for business use?
Source code helps you study the components. For an implementation decision, you also need support, terms of use, compatibility, and evidence that the specific configuration works. You cannot assume those exist from a single GitHub link.
How AIrassvet helps prepare data for AI
The news raises a practical question: what data does the chosen process actually need, and by what criteria should the result be judged? Within AIrassvet’s service areas described on the site — process audits, data preparation, and LLM implementation — three tasks can be discussed:
- describe one process, how it is currently performed, and the criterion for a useful result;
- prepare the necessary data set while taking access restrictions into account;
- define requirements for LLM deployment and integration with existing systems.
The first step is to choose a process and list the data sources, restrictions, and acceptance criterion. Support for Google’s new TEE system, its certification audit, and a repeat of the Gboard results are not being claimed here. Discuss the task.
Conclusion
Google’s federated learning example shows why server location is only one privacy issue. A corporate decision needs verifiable links between data, permitted code, and the output that is released. Start with a table of requirements and evidence for one process; validate numerical effects on your own task, and keep open questions in the implementation decision.