Implementing Differential Privacy in ML: Privacy Without Compromises

Differential privacy: where the model remembers too much

A model does not store the dataset — it stores statistics, and traces of specific records remain in them. The rarer an example is in the sample, the more strongly the model fits to it and reproduces fragments of text, table fields, rare combinations of features.

From the model output, training examples are reconstructed — not verbatim, but enough to link a record to a person.

Conventional anonymization does not cover this: removing name and phone removes a direct identifier, but quasi-identifiers remain. Age, district, occupation, and date of contact together point to one person.

Pseudonymization and hashing change the representation of a feature, while consistency between records remains — reconstruction is still possible.

Formally, the barrier is described by Differential Privacy: the training result changes almost imperceptibly when one record is added or removed.

The guarantee is provided at the level of an individual, not the entire set, so it does not fall apart when the attacker gains auxiliary data.

In practice, the guarantee is set by a privacy budget: less noise — higher accuracy and higher risk. Noise is added to gradients during training, the contribution of an individual example is limited, and how this affects metrics is monitored.

A separate risk area is model transfer: weights go to a contractor or an external environment along with everything the model has memorized. We explain how this is closed at the training level rather than by a non-disclosure agreement.

What secure model training provides

Differential privacy changes the class of failures, not just their probability.

Reconstruction of training records, inference of an example's membership in the sample, and insertion of "trap records" stop yielding reliable results: the contribution of a single record to the output is bounded by construction.

Secure training makes the model's robustness to attacks a measurable quantity rather than a property "by feel": the privacy budget is set in advance and distributed across epochs.

When it is exhausted, training stops — the model cannot be fine-tuned "a little more" at the expense of the guarantee.

The price is quality on rare examples: noise blurs the long tail most strongly. We move rare slices into separate validation with fixed thresholds, weight classes, compute gradient clipping layer by layer, and start from a pretrained backbone.

Training becomes about a third longer, while the drop on a rare slice stays within 1–2 metric points.

Model transfer to a partner comes with a privacy map: total budget, training mode, feature composition, and an attack robustness report on a test bench.

We ensure training reproducibility by fixing the data order, generator seed, and noise profile — a repeat run yields the same budget, and metrics stay within a known interval.

The approach has been proven in production: Apple collects aggregated statistics from devices in exactly this way — noise on the client side, raw data never leaves the device. The same principle transfers to corporate training, only the guarantee is formulated as a number.

Differential privacy: comparison of approaches

Choosing a protection mode is not a switch, but a decision about where exactly noise is introduced and what remains in the customer's environment.

Different training modes provide different levels of guarantees, cost model quality differently, and fit infrastructure differently, so they should be compared by constraints, not promises.

In practice, approaches are combined: client-side noise works as a first filter, noise during training as a formal guarantee at the output. What is applicable in your case is determined by one thing: at which points data physically crosses the boundary of the environment.

Implementation stages: from data audit to model transfer

Implementing differential privacy is a sequence of work where each stage leaves a verifiable artifact.

The order is fundamental: start with the noise mode before understanding which fields and links between records go into training — otherwise the privacy budget will go to protecting insensitive data, and model quality will drop for nothing.

1. Data audit: we inventory sources, mark quasi-identifiers and rare categories, assess by which features a specific person stands out. The output is a risk map and a list of fields that are unacceptable in training in their original form.
2. Data flow diagram: we record who reads the data, how it enters the training sample, and what goes into logs and metrics. We mark noise injection points and places where reverse matching is possible.
3. Noise mode configuration: we choose a local or central mechanism, distribute the privacy budget across training iterations, and calibrate so that quality does not fall below the agreed threshold.
4. Reconstruction attack testing: feature reconstruction, determining whether a record belongs to the training sample, extracting information through model queries. Every finding is closed before acceptance.
5. Acceptance criteria: quality on a holdout set, share of successful attacks, budget stability during retraining. We put checks into an automated pipeline so that regression is caught immediately.
6. Handover to the team: configurations, flow diagram, budget-handling policies, incident triage procedure. After practical sessions, engineers and analysts change the noise mode themselves and read attack reports.

What the team retains after implementation

Implementation of differential privacy ends not with a model demonstration, but with a working environment: a set of artifacts by which the solution can be maintained, retrained, and audited without our involvement.

Everything handed over is stored in a repository and documentation with versioning — a change to any privacy parameter is traceable to a specific decision.

• Data schemas — a map of sources, field labeling by sensitivity, and a list of attributes involved in training: it is visible where personal data ends and the aggregate begins.
• Roles and access policies — a matrix "role → dataset → allowed noise level → what is visible at the output," with separation of access to source samples and to trained models.
• Training configurations — fixed parameters: privacy budget per cycle, noise type and scale, clipping of an individual example's contribution, feature composition.
• Retraining regulations — conditions for a new run (data slice change, privacy budget exhaustion), approval procedure, and result verification before publication.
• Change log — history of edits to parameters, data, and access rules with author and reason: it is clear why the model behaves differently from the previous release.
• Solution documentation — architecture diagram, description of the trade-off between accuracy and privacy level, instructions for launch, diagnostics, and rollback.

We hand this over together with employee training — the team changes parameters and data without breaking privacy guarantees.

Case: training on the customer's sensitive data

The customer is a medical service with a large array of personal records about appointments and prescriptions. A risk prediction model had to be trained on this same data, but exporting it to a shared environment was prohibited.

Before the project, records were anonymized manually: names were removed, but a person was still identifiable by the combination of age, diagnosis, and appointment date.

We moved training to differential privacy: at each step, gradients are clipped by norm, then noise calculated for the agreed privacy budget is added to them.

We integrated this via Opacus — the library plugs into the existing training loop and tracks the spent budget on the fly, without rewriting the model.

Metrics before and after

The share of reconstructable records was measured by an attack that determines whether a specific record was in the training sample. The quality drop of 1.8 p.p.

is the price of privacy; in the risk prediction task, trigger thresholds were recalculated, and this did not affect final decisions.

Training time increased because of noise and gradient norm clipping, but manual anonymization, which took several days per slice, is no longer needed.

Security service review now follows a formal criterion — a run log, a fixed budget, and a report for each training run, instead of discussing the question "did we erase everything well enough."

Client-side and server-side noise: what is the difference

The difference is at which step noise is added to the data. In local mode, the client randomizes its contribution before sending — the server receives already noisy values and cannot reconstruct the originals.

In global mode, noise is applied once to the aggregate in a trusted storage where exact records are stored.

This leads to different privacy budget consumption. Local mode spends it per participant, so comparable protection requires noticeably more noise: on a small sample, the signal drowns, and the model stops catching rare classes.

Global mode makes fewer errors for the same budget, but requires trust in an environment with open data.

The modes affect accuracy differently. Local smooths distribution tails more strongly and biases estimates of rare events; global mainly blurs small groups.

Therefore, the budget is calculated per subgroup, not for the entire sample: otherwise rare slices become unusable for conclusions.

Infrastructure requirements diverge in the same way. Local mode moves randomization to the device or client application, and the server only sums reports — a secure aggregation protocol is needed so that individual reports cannot reveal a contribution. Global requires a trusted node, access audit, and budget accounting for each request.

A hybrid is often used: identifiers are noised on the client, while product analytics are run through a global environment with request limits. Both options are run on historical data and compared in quality at a fixed budget — it is visible where exactly accuracy is lost.

Technical doubts: model accuracy and noise budget

Differential privacy adds controlled noise to training, and an engineer's first question is how much accuracy this costs. We calculate the "privacy — quality" curve on the customer's data and show where a reasonable trade-off lies, rather than naming a single number.

Below are the questions that most often come up at the assessment stage.

Is this applicable to an already trained model?

Directly, no: weights obtained without noise already contain traces of the original records. We work in two ways — fine-tuning in private mode (faster, weaker guarantee) or retraining from scratch with noise (longer and more reliable).

What should be done with combined storages?

Noise is calculated for each source separately, and budgets add up — the resulting guarantee is weaker than it seems. We calculate the total budget for all combined storages in advance and, if it goes beyond the limits, propose local noise on the source side.

How do you verify that records cannot be reconstructed?

We attack the model ourselves: we try reconstruction from output probabilities, compare responses to records that were and were not in training, and look for anomalies on rare examples. The result is a report on which noise budget excludes reconstruction.

Let's discuss your data protection task in the model

To assess implementation, we need specifics on data and the model, not a general story about the task. Describe what the system is, what data enters it, and what exactly needs to be hidden — that is enough for us to return with a work plan and timelines.

What to send for the first review:

• data composition: training sources, personal fields, volumes, and missing value share;
• flow diagram: where data is stored, who has access, where trained artifacts go;
• model description: task type, what it is trained on, in what form it outputs the result;
• protection requirements: what is considered disclosure, to what level data is aggregated, whether there are regulator restrictions;
• examples of requests the model must withstand — they show the acceptable accuracy drop;
• environment constraints: prohibition on taking data outside the environment, engineer roles, where the model is deployed.

The first review takes about an hour and is held together with your engineers. We examine the data composition, mark where information leaks in the current process, and show which noise injection mechanisms apply to what.

After the review, we return with a stage-by-stage work plan, expected accuracy change, and acceptance criteria by which the result can be verified without taking our word for it.

If you are not ready to show part of the data — describe it in words; that is enough for assessment: we will discuss the task and determine where to start.