Google is moving private AI training to the cloud—and making its rules verifiable

Google Research’s 2 October announcement presents a counterintuitive privacy advance: send encrypted training examples to servers and move the computation there. Google says Gboard already uses the system for English and Japanese next-word prediction.[1]

The revealing questions are who can read the data, which operations can touch it and what information can emerge. “On the device” and “in the cloud” describe location; the access rules and permitted outputs define the privacy protections.

A permission attached to the data, not a promise beside it

The public Confidential Federated Compute project describes encrypted uploads bound to an access policy. A key-management service releases decryption keys only to protected workloads whose attestation matches that policy. Attestation is evidence about the code and environment actually running; the design uses it to connect permitted processing to access to the data.[2]

An analogy helps. Encrypting a sealed box stops a courier reading it. Giving its key to anyone inside the destination building removes that protection at the door. This system attempts something narrower: release the key only to an approved machine carrying out approved work. The analogy does not prove the machinery secure; it explains why encryption and execution rules solve different problems.

Why a model still needs protection at the output

Even a perfectly protected computation can publish an overly revealing result. Differential privacy addresses that output problem. NIST explains it as limiting how much the result distribution changes when one person’s contribution changes. The parameter epsilon controls the strength of the guarantee: a smaller value generally represents stronger protection. Repeated releases also consume a cumulative privacy budget.[4]

Imagine a service releasing statistics from a small group. Keeping the original records encrypted does not help if the published answer lets someone work out one participant’s record. A protected room and a safe public statement are different requirements. In model training, the corresponding question is what the released model and associated metrics can reveal—not only whether an operator opened a raw file.

There is a practical reason for engineers to care about the combination. Hardware protection can limit direct access while statistical protection limits what leaves the computation. Neither layer is redundant. Treating differential privacy as another name for encryption would overlook the output; treating encryption as unnecessary because outputs are private would overlook the inputs.

Verifiable is more specific than open source

The project’s inspection documentation describes records containing both attestation evidence and the relevant data-access policy. It also provides a route from binary identifiers to build provenance and source revisions. It notes that inspecting every contributing device is impractical and points to public transparency logs as a more scalable way to examine permitted workloads.[3]

Publishing source code alone would leave an obvious gap: how does an outsider know that this is the code processing their data? The intended chain links the permitted operation, the running binary and the source used to build it. An auditor needs all three. A carefully reviewed repository would be weak evidence if the deployed service could quietly run unrelated software.

This is a demanding standard, not a badge that an ordinary user can meaningfully award after reading a product page. Useful assurance requires someone to perform the inspection and explain its scope. “Auditable” means there is a route to examination; “audited” means an examination actually happened. We inspected the published design and documentation, not deployed devices, binary builds or a live training run.

The performance benefit comes from changing the schedule

Google reports one-to-two-month runs under its earlier setup. The new design separates encrypted collection from server-side training, avoiding a wait for devices at each step. No universal speed-up multiplier is stated.[1]

Think of coordinating a distributed workshop. If every stage must wait for a different group to be awake, connected and ready, faster arithmetic is not the only way to make progress. Separating collection from computation changes the scheduling problem. That is the engineering insight here: some performance restrictions arise from coordinating access to data, rather than from the model’s calculations alone.

Google’s established Federated Compute repository makes the broader architecture explicit: federated programs coordinate processing and movement of values across servers and clients. The label describes a collaborative computation system, not a universal guarantee that every operation occurs locally. Buyers should therefore read the actual data path rather than assume a familiar term establishes it.[6]

The remaining trust does not disappear

Google qualifies the design by the limitations of current trusted execution environments, including side-channel concerns, and describes complete correctness proofs for the software as a future possibility. “Toward provably private” is not a claim that every component already has such a proof.[1]

NIST’s work on differential-privacy bugs illustrates why implementation matters. A mechanism can leak information through exceptional behaviour, not only through an ordinary numerical answer: an error occurring for one input but not a neighbouring input can itself reveal something. A sound mathematical design must therefore be implemented without unintended disclosure paths.[5]

For an organisation evaluating privacy-preserving AI, a good specification should identify the permitted workload, the protected unit of data, the output guarantee, the retention boundary and the trusted components. It should also explain what happens after a software update or a vulnerability in a trusted component. Those questions distinguish an operational privacy design from a reassuring architectural slogan.

The advance is worth attention precisely because it does not rely solely on the slogan that data stays at home. It attempts to make remote processing accountable to constraints that outsiders can examine. Whether that model earns trust will depend on the quality and independence of the verification, not on how often the word “private” appears in its name.

Report an error or suggest a correction