Casebook/Case 23
Fairness, privacy & security

Private training for on-device language models

Balancing utility, device constraints, aggregation, and formal privacy protection.

Reported by the primary sourceFACT LAYER

What we can attribute directly

Google Research published advances in private training for production on-device language models.

The work combines on-device/federated settings with privacy techniques.

Read Google Research — Private on-device training Primary source · last checked 26 Aug 2026
01 · Problem & constraints

The operating envelope

Sensitive local text, unreliable devices, communication limits, heterogeneous data, privacy budget, and model utility.

Actors

Model teams, platform owners, operators, downstream product systems, and people affected by decisions.

Evidence

Versioned data, configs, traces, artifacts, deployments, and outcomes aligned on one timeline.

Failure cost

Central collection creates privacy risk, while naive local updates may leak information through gradients or metadata.

02 · Architecture reconstruction

Trace the system before naming the bug.

  1. 01

    Producers emit versioned data or model artifacts.

  2. 02

    A platform validates, computes, stores, schedules, or routes them.

  3. 03

    Training or inference consumes the exact declared version.

  4. 04

    Telemetry joins the decision to system, data, and model identity.

  5. 05

    Operators compare outcomes, stop conditions, and the last known-good path.

03 · Symptoms & investigation

Follow the evidence boundary by boundary.

Symptoms

Central collection creates privacy risk, while naive local updates may leak information through gradients or metadata.

Investigation

Threat-model server, client, transport, update content, participation, retention, and repeated releases.

DIAGNOSTIC EXERCISE

Why can repeated “small” releases consume a large privacy budget, and which accountant output should gate them?

Open investigation scaffold
  1. Write the earliest known-bad timestamp.
  2. Compare exact identities on either side of that boundary.
  3. Find the smallest affected slice and a known-good counterexample.
  4. Separate mitigation from root-cause confirmation.
04 · Root cause & fix

Repair the contract, not only the symptom.

ROOT CAUSE

Keeping raw data on device does not by itself protect information encoded in updates.

FIX

Combine secure aggregation, clipping, noise, controlled participation, and an auditable privacy accountant.

Rollout

Start with low-risk cohorts, validate utility and privacy accounting, and bound cumulative releases.

05 · Rejected alternatives

Reason about the tempting shortcuts.

  • Calling a system private because raw examples are not uploaded.
  • Reporting epsilon without adjacency, delta, sampling, and threat model.
06 · Monitoring after the fix

Make recurrence visible early.

01

Privacy budget consumption

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

02

Update clipping and participation

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

03

Utility and failure by device cohort

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

REUSABLE PRODUCTION PATTERN

Privacy is an end-to-end guarantee with explicit adversary, accounting, and utility tradeoffs.

Carry this pattern into assignments as a design constraint and into incident reviews as a hypothesis—not as proof about an unpublished system.