Wat is privacybeschermend machine learning?

Een team besluit een taalmodel op eigen servers te draaien in plaats van een externe API aan te roepen. De motivatie is privacy: de gevoelige data in huis houden en nooit aan een derde partij geven. Dat instinct klopt, en de controle die het oplevert is echt, maar het is ook onvolledig. Een model dat op privégegevens is getraind, kan worden verleid tot het onthullen of het record van een specifieke persoon in de trainingsset zat. Federated updates die nooit ruwe data bevatten, kunnen worden teruggerekend naar de beelden die ze voortbrachten. Een groot model kan stukken van zijn trainingsdata onthouden en uitspugen. De data bleef thuis, en het model lekte alsnog.

Precies dat gat, tussen privé aanvoelen en aantoonbaar privé zijn, is wat privacybeschermend machine learning aanpakt. De standaard ML-pipeline heeft ruwe data nodig die toegankelijk is voor de trainingsinfrastructuur, en dat botst met privacyregelgeving, met eisen rond datasoevereiniteit en met partners die hun datasets simpelweg niet delen. Privacybeschermend machine learning is de familie technieken die die botsing oplost.

Het nuttige onderscheid loopt tussen technieken die dataverkeer verminderen, technieken die begrenzen wat outputs kunnen prijsgeven, en technieken die data vertrouwelijk houden tijdens de berekening. Zelf hosten komt naast die controles te staan, niet in plaats ervan.

De korte versie

• Privacybeschermend machine learning (PPML) is een verzamelcategorie, geen enkele methode. Dit artikel richt zich op vier hoofdbenaderingen: federated learning, differential privacy, homomorfe encryptie en secure multi-party computation. Ook andere privacyversterkende architecturen, waaronder trusted execution environments, kunnen in PPML-systemen voorkomen.
• Federated learning alleen biedt geen formele privacygarantie. Het houdt ruwe data bij de bron, maar gedeelde gradient-updates kunnen soms worden teruggerekend naar trainingsrecords. Differential privacy is een gangbare manier om een formele lekgrens toe te voegen.
• De sterkte van differential privacy wordt meestal samengevat met epsilon. De garantie hangt ook af van delta, van de beschermde eenheid en van de methode van privacy accounting. Een formele garantie met zwakke parameters blijft een garantie op papier en is in de praktijk theater.
• Homomorfe encryptie is echt en traag. Rekenen op versleutelde data werkt, maar de overhead beperkt het vandaag tot eenvoudiger modellen, latentietolerante inferentie en experimentele fine-tuning-workflows, niet tot gewone training van grote modellen of volledige pretraining.
• Een model zelf hosten is datalokalisatie, geen PPML. Data houden op infrastructuur die jij beheert bepaalt wie erbij kan. Het bepaalt niet wat het model zelf kan prijsgeven.

Scope-notitie: dit is een conceptuele uitleg, geen implementatiegids. Het behandelt library-setup, epsilonkeuze, regelgevingscompliance en privé fine-tuning van LLM's niet in detail. Het doel hier is de kaart. De routebeschrijving hoort thuis in aparte implementatiegidsen.

Hoe privacybeschermend machine learning data beschermt

Privacybeschermend machine learning is een overkoepelende term voor methoden die informatieblootstelling verminderen, beperken of formeel begrenzen bij modeltraining, inferentie en gezamenlijke analyse. Dit artikel richt zich op vier hoofdbenaderingen: federated learning, differential privacy, homomorfe encryptie en secure multi-party computation. Ze beschermen verschillende assets onder verschillende dreigingsmodellen en mogen dus niet als uitwisselbare garanties worden behandeld.

Het probleem is eenvoudig: standaard ML-pipelines gaan er meestal van uit dat het trainingsproces bij ruwe records kan, terwijl privacyregelgeving, eisen rond datasoevereiniteit en partnerafspraken die toegang vaak juist blokkeren. De vier families beantwoorden die beperking op verschillende manieren: de berekening naar de data brengen in plaats van de data naar de berekening (federated learning), gekalibreerde ruis toevoegen zodat outputs minder over één persoon prijsgeven (differential privacy), rekenen op data die versleuteld blijft (homomorfe encryptie), of meerdere partijen samen een resultaat laten berekenen zonder elkaar hun ruwe invoer te tonen (secure multi-party computation).

Het onderliggende risico wordt onomwonden benoemd in de richtlijn van Google over verantwoorde AI: machine-learningmodellen kunnen aspecten onthouden of prijsgeven van de data waaraan ze zijn blootgesteld, en privacywerk bestaat om daar waarborgen omheen te zetten. PPML pakt dat risico aan en verschilt van gewone anonimisering, om redenen die de volgende sectie concreet maakt.

Waarom is anonimisering niet genoeg?

Geanonimiseerde data kan nog steeds worden geherïdentificeerd. Namen en voor de hand liggende identificatoren uit een dataset halen vermindert de zichtbare blootstelling, maar garandeert geen privacy zodra de data te koppelen is aan informatie van buiten. Dat is de terugkerende zwakte van de-identificatiebenaderingen zoals k-anonimiteit: ze kunnen identificeerbaarheid verlagen onder specifieke aannames, maar bieden niet de formele garanties van technieken als differential privacy of cryptografische PPML-methoden.

Dit praktische onderscheid doet ertoe voor iedereen tegen wie ooit is gezegd: "we hebben het geanonimiseerd, dus het zit goed." Anonimisering is een uitspraak over een dataset binnen een specifieke context en een specifiek dreigingsmodel. Een linkage-aanval hoeft geen encryptie te breken of toegangscontroles te omzeilen. Er is alleen een andere dataset nodig die met de jouwe overlapt. Dat punt wordt rechtstreeks gemaakt in de de-identificatierichtlijn van NIST, dat opmerkt dat gede-identificeerde data alsnog kan worden geherïdentificeerd door koppeling met aanvullende datasets.

Differential privacy levert iets wat gewone de-identificatie niet levert: een wiskundige grens op hoeveel de data van één individu een gepubliceerd resultaat kan beïnvloeden, onder een gedefinieerde privacy-eenheid en een gedefinieerd dreigingsmodel. Homomorfe encryptie en SMPC bieden andere soorten cryptografische vertrouwelijkheid, terwijl federated learning vooral verandert wáár data wordt verwerkt. Die garanties zijn verwant, maar ze zijn niet hetzelfde.

Hoe werkt federated learning, en waarom is het alleen niet genoeg?

Bij federated learning wordt een globaal model naar lokale apparaten of servers gestuurd, traint daar op de aanwezige data en stuurt alleen zijn parameterupdates terug naar het centrum. Ruwe data verplaatst zich nooit. Het is een oprecht nuttig patroon en het draait op schaal in productie. Het is op zichzelf ook geen privacygarantie.

Het mechanisme is model-naar-data in plaats van data-naar-model. De Gboard-uitrol van Google draait meer dan 30 taalmodellen op het apparaat zelf, in meer dan 7 talen en meer dan 15 landen, en traint op tekst die de telefoon nooit verlaat. Dat is federated learning zoals beloofd: het toetsenbord wordt beter zonder dat Google verzamelt wat je typte.

Het probleem is wat er meereist in de updates. Gradiënten dragen informatie over de data die ze voortbracht, en die informatie is terug te halen. Zhu, Liu en Han lieten dat zien in Deep Leakage from Gradients (NeurIPS 2019), met gradient-inversieaanvallen die private trainingsvoorbeelden reconstrueren uit gedeelde modelupdates, in hun experimenten met pixelnauwkeurig herstelde beelden en tokenprecieze overeenkomst voor tekst. Federated learning verminderde dataverkeer. Het elimineerde het lekrisico niet.

Als het doel is te begrenzen wat deelname kan prijsgeven, is differential privacy een gangbare aanvulling. Secure aggregation pakt een ander risico aan door individuele clientupdates te verbergen voor de coördinerende server. Gboard combineert federated learning met formele differential privacy in plaats van te leunen op federatie alleen.

Opmerking: Federated learning wordt vaak "privé" genoemd omdat ruwe data bij de bron blijft. Die beschrijving is misleidend. Zonder extra bescherming kunnen federated updates genoeg signaal dragen om trainingsrecords te reconstrueren. DP-FL voegt een formele differential-privacy-garantie toe in plaats van te leunen op federatie alleen. Federatie op zichzelf is een keuze over hoe je met data omgaat, geen privacybewijs.

Wat is differential privacy, en wat regelt epsilon eigenlijk?

Differential privacy is een wiskundige definitie die begrenst hoeveel een analyse kan veranderen als één privacy-eenheid wordt toegevoegd of verwijderd. Veel mechanismen bereiken die garantie door gekalibreerde willekeur toe te voegen. Epsilon is één zichtbare parameter, maar een betekenisvolle garantie hangt ook af van de privacy-eenheid, de DP-variant en eventuele extra parameters zoals delta, plus compositie, accounting en implementatiedetails.

Epsilon wordt omschreven als het privacybudget in de woordenlijst van NVIDIA: lagere waarden betekenen sterkere privacy maar meer ruis, hogere waarden behouden nauwkeurigheid ten koste van zwakkere garanties. Een gangbare manier om differential privacy toe te passen tijdens deep-learningtraining is DP-SGD, differentially private stochastic gradient descent: knip elke gradiënt per sample af op een begrensde grootte, voeg gekalibreerde Gaussische ruis toe en aggregeer dan. Het afknippen begrenst hoeveel invloed één voorbeeld op het model kan hebben. De ruis verhult de invloed die overblijft.

Dat budget raakt op. Het mechanisme wordt beschreven in de documentatie van Tumult Analytics over privacybudgetten: elke query op een beschermde dataset verbruikt een deel van het privacybudget. Hoe die uitgaven optellen is standaardtheorie van differential privacy, uiteengezet in The Algorithmic Foundations of Differential Privacy van Dwork en Roth: bij basiscompositie tellen k queries elk met parameter epsilon op tot een totaal privacyverlies van k maal epsilon, en geavanceerde compositiestellingen geven strakkere grenzen. Je krijgt geen onbeperkt aantal vragen. Je krijgt een budget, en dat geef je uit.

De parameterkeuzes bepalen dus of de garantie in de praktijk iets betekent. Een peer-reviewed kritiek op privacybenaderingen in machine learning betoogt dat de wiskundige kadering een "vernislaag van objectiviteit" kan geven die vervolgens wordt gebruikt om een project wit te wassen. Zet de privacyparameters zwak genoeg en de garantie kan bijna betekenisloos worden, terwijl een team nog steeds kan claimen dat het aan differential privacy voldeed. De garantie is echt. De praktische kracht ervan is een ontwerpkeuze.

Opmerking: Een differential-privacygarantie betekent alleen iets als je de privacyparameters kent en de eenheid die ze beschermen. Een zeer hoge epsilon, een losse delta of onduidelijke accounting kunnen een technisch geldige garantie in de praktijk vrijwel waardeloos maken. "Dit systeem gebruikt differential privacy" lezen zegt op zichzelf bijna niets: de betekenis zit in de privacyparameters, waarover ze zijn gemeten en hoe ze samengesteld worden. Concrete deployments maken dit tastbaar. Google rapporteert een epsilon van 1 op gebruikersniveau voor zijn Provably Private Insights-systeem, maar dat is de keuze van één deployment voor één use case, geen getal om over te nemen.

Hoe rekent homomorfe encryptie op data die ze nooit ontsleutelt?

Volledig homomorfe encryptie (FHE) laat een server berekeningen rechtstreeks op versleutelde data uitvoeren en een versleuteld resultaat teruggeven dat alleen de data-eigenaar kan ontsleutelen. De server doet het werk zonder ooit de platte tekst te zien. Het is een van de sterkste privacytools in het vakgebied, maar de prijs is prestatie.

De nuttige analogie is een afgesloten handschoenkast met ingebouwde handschoenen: een medewerker kan erin reiken en de inhoud bewerken zonder de kast ooit te openen of iets eruit te halen. De data-eigenaar heeft de enige sleutel. De berekening gebeurt op de verzegelde inhoud, en alleen de eigenaar kan de kast openen om het resultaat te lezen. Dat is wat FHE wiskundig doet: opereren op cijfertekst zodat het ontsleutelen van de uitvoer hetzelfde antwoord geeft als rekenen op de platte tekst zou hebben gedaan.

Het addertje is de kosten. Concrete ML van Zama zet scikit-learn- en PyTorch-modellen om in FHE-compatibele equivalenten zonder dat de gebruiker rechtstreeks met cryptografische primitieven hoeft te werken, en versie v1.9 verscheen op 10 april 2025. Maar de eigen benchmarks van het project tonen de overhead: een CIFAR10-beeldclassificatienetwerk draait onder FHE op ongeveer 4 minuten per beeld. Dat is prima voor sommige latentietolerante inferentie, eenvoudiger modellen en experimentele versleutelde fine-tuning. Het is nog steeds geen praktisch pad naar volledige pretraining van grote modellen of gewone trainingsworkloads. FHE is vandaag een precisie-instrument voor een smalle set taken, geen algemene privacylaag.

Wat is secure multi-party computation in machine learning?

Secure multi-party computation (SMPC) laat meerdere partijen samen een functie berekenen over hun gecombineerde private invoer zonder dat een partij de ruwe data van de anderen ziet. De invoer van elke partij blijft geheim. Alleen het afgesproken resultaat wordt bekend. SMPC kan worden gebouwd met technieken als secret sharing, garbled circuits, oblivious transfer en combinaties daarvan. Bij secret-sharingprotocollen worden private waarden in delen gesplitst, zodat één deel de invoer niet prijsgeeft. Garbled-circuitprotocollen werken anders: ze coderen een berekening zo dat partijen die kunnen evalueren zonder hun private invoer te onthullen.

De natuurlijke use case is samenwerking tussen organisaties. Meerdere ziekenhuizen willen een model trainen op hun gecombineerde patiëntdata, maar geen van hen mag wettelijk dossiers met de andere delen. SMPC laat hen het gezamenlijke model berekenen alsof de data was samengevoegd, terwijl de dossiers van elk ziekenhuis daar verzegeld blijven. De SMPC-overhead hangt sterk af van het protocol, het beveiligingsmodel, de netwerkomstandigheden, het aantal partijen en de functie die wordt geëvalueerd. Veel protocollen zijn communicatie-intensief, dus prestaties moet je meten tegen de specifieke samenwerking in plaats van generiek te rangschikken tegenover differential privacy of FHE. Precies dat patroon voor machine learning in de zorg wordt behandeld in een overzichtsartikel uit 2025 in WIREs Computational Statistics.

Kan een machine-learningmodel zijn trainingsdata lekken?

Ja. Een getraind model kan zijn trainingsdata op verschillende manieren verraden: membership inference onthult of een specifiek record in de trainingsset zat, modelinversie en gradiëntlekkage kunnen records reconstrueren, en grote taalmodellen kunnen stukken van hun trainingsdata onthouden en letterlijk uitspugen. Dit zijn geen hypotheses. Het zijn aangetoonde aanvallen, en ze zijn de reden dat de bovenstaande technieken bestaan.

Het fundamentele resultaat is membership inference. Shokri en collega's toonden in Membership Inference Attacks Against Machine Learning Models (IEEE S&P 2017) dat een aanvaller die het voorspelgedrag van een model observeert, kan bepalen of een bepaald record deel uitmaakte van de trainingsset. Dat klinkt abstract totdat de trainingsset "patiënten met een bepaalde diagnose" is, want dan is het lidmaatschap zelf het gevoelige feit. Modelinversie en de eerder besproken gradiëntlekkage-aanvallen breiden dit uit van "was dit record aanwezig" naar "reconstrueer het record".

De frontlinie zijn grote taalmodellen, en daar passen oudere PPML-frameworks het slechtst. Onderzoek naar LLM's die trainingsdata uitspugen documenteert dat grote modellen delen van hun trainingscorpus onthouden en ertoe aangezet kunnen worden die te reproduceren, waarbij extractie-aanvallen letterlijke en bijna letterlijke trainingsdata terughalen. DP-SGD kan worden toegepast op private fine-tuning, maar de kosten in nauwkeurigheid en rekenkracht op de schaal van grote modellen zijn hard, wat mede verklaart waarom de PPML-workshop van Apple in 2026 een heel track wijdde aan foundation models en privacy. Verdedigingen die netjes werken voor een logistische-regressieclassifier laten zich niet gratis overzetten naar een model met miljarden parameters.

PPML en zelf gehoste AI: wat lokale inferentie je wel en niet oplevert

Een model zelf hosten houdt je data op infrastructuur die jij beheert. Dat is een echte winst op het vlak van toegangscontrole en datalokalisatie: de data reist niet naar een derde partij, en jij bepaalt wie bij de machine kan waarop het draait. Het is echter geen privacybeschermend machine learning. Lokale inferentie doet op zichzelf niets tegen membership inference op het model, en het weerhoudt een model er niet van te onthullen wat het heeft onthouden.

De twee lossen verschillende helften van het probleem op, en ze door elkaar halen is een veelgemaakte fout in dit vakgebied. Datalokalisatie bepaalt wie bij de data kan: een perimeterkwestie, beantwoord door waar de bytes staan en wie de sleutels van de ruimte heeft. PPML bepaalt wat het model zelf kan prijsgeven, een kwestie van informatielekkage, beantwoord door de vier technieken hierboven. Een model op je eigen server draaien is een sterk antwoord op de eerste vraag en helemaal geen antwoord op de tweede.

Als de vraag die je afweegt is of je het model überhaupt zelf moet draaien, dan is de kostenkant van die beslissing een eigen analyse: zie Zelf een Open-Weight LLM Hosten vs. een API: De Echte Kostenwiskunde.

Voor een platform- of infrastructuurengineer luidt de operationele lezing zo: "het draait op onze eigen server" kan voldoen aan sommige eisen rond datalokalisatie en toegangscontrole, maar het beperkt op zichzelf niet wat het model kan prijsgeven. Zodra het model of zijn output ooit wordt gedeeld, of dat nu tussen teams is, met partners of in een product, loopt de perimeter die je om de hardware bouwde niet met het model de deur uit. De architectuurkeuzes die de garantie echt verschuiven zijn de PPML-keuzes: differential privacy op de output die je publiceert, DP-FL voor training over locaties die je niet kunt centraliseren, encryptie-gebaseerde berekening waar data zelfs voor je eigen infrastructuur niet blootgesteld mag worden. Googles Provably Private Insights is juist leerzaam omdat het meerdere controles combineert, differential privacy, trusted execution environments en vertrouwelijke federated analytics, in plaats van op één ervan te leunen. Lokalisatie hoort bij een echte architectuur. Het is niet de hele architectuur.

Wanneer gebruik je welke PPML-techniek?

De keuzelogica volgt de randvoorwaarde, niet de mode. Gebruik federated learning wanneer de data niet gecentraliseerd kan worden. Gebruik differential privacy wanneer je een formele garantie nodig hebt over wat het model prijsgeeft. Gebruik homomorfe encryptie wanneer de berekening moet plaatsvinden op data die nooit ontsleuteld wordt en de latentie het toelaat. Gebruik secure multi-party computation wanneer meerdere partijen samen moeten rekenen zonder hun invoer te delen.

De technieken laten zich ook combineren. DP-FL is het duidelijkste voorbeeld: kies de controles op basis van de garanties die het systeem nodig heeft, in plaats van het probleem in één techniek te persen.

De afwegingen in één oogopslag:

Die karakteriseringen komen uit een op IoT gericht PPML-overzichtsartikel van maart 2026, uit Zama's Concrete ML-benchmarks en uit de literatuur over herïdentificatie.

De tabel is slechts een startpunt. Echte systemen combineren vaak technieken: een trainingsprobleem over meerdere locaties dat óók een formele privacygarantie nodig heeft, is meestal een DP-FL-probleem en geen keuze tussen federated learning en differential privacy. Wie de beslissing strenger wil structureren, kan zich door het gestructureerde beslissingsondersteunende raamwerk voor ontwikkelaars werken dat eind 2024 is gepubliceerd.

Wat tooling betreft: TensorFlow Federated biedt een open-sourceframework voor federated learning en berekeningen op gedecentraliseerde data. TensorFlow Privacy levert hulpmiddelen voor differentially private training, Googles Differential Privacy-bibliotheken dekken differentially private statistiek en aggregatie, en Concrete ML levert het FHE-pad. PySyft richt zich inmiddels breder op privacybeschermende remote data science, waarbij berekeningen draaien tegen data die bij de eigenaar blijft en alleen goedgekeurde resultaten worden gedeeld. Dat zijn de namen en wat ze doen. De setup hoort in aparte implementatiegidsen, niet hier. De terugkerende les is dat de wiskunde kan kloppen terwijl de implementatie alsnog faalt. De garantie telt alleen als het systeem rond het juiste dreigingsmodel is ontworpen en de privacyparameters passen bij het risico dat je beschermt.

Veelgestelde vragen

Wat betekent PPML?

Privacybeschermend machine learning is een overkoepelende term voor methoden die informatieblootstelling tijdens machine learning verminderen, beperken of formeel begrenzen. Belangrijke benaderingen zijn federated learning, differential privacy, homomorfe encryptie en secure multi-party computation, maar ze beschermen verschillende assets en bieden verschillende soorten garanties.

Is federated learning genoeg om privacy te beschermen?

Nee. Federated learning houdt ruwe data bij de bron, maar de gedeelde parameterupdates kunnen via gradient-inversieaanvallen worden teruggerekend naar trainingsrecords. Op zichzelf biedt het geen formele privacygarantie. Differential privacy kan een formele lekgrens toevoegen, wat de combinatie oplevert die meestal DP-FL heet.

Welke epsilonwaarde moet ik gebruiken voor differential privacy?

Er is geen universele waarde. Epsilon is een van de belangrijkste parameters in de afweging tussen privacy en nauwkeurigheid: lagere waarden betekenen doorgaans sterkere privacy en meer ruis, hogere waarden doorgaans zwakkere privacy en minder ruis. De juiste instelling hangt af van de gevoeligheid van de data en het risico dat je kunt accepteren. Er bestaat geen universele grens die een epsilonwaarde "veilig" maakt. Beoordeel epsilon samen met de privacy-eenheid, de DP-variant en eventuele extra parameters zoals delta, de compositiemethode en het dreigingsmodel van het systeem.

Wat is het verschil tussen PPML en anonimisering?

Anonimisering haalt identificatoren uit een dataset, maar geanonimiseerde records kunnen worden geherïdentificeerd door ze te koppelen aan aanvullende data uit andere bronnen. Sommige PPML-technieken bieden formele garanties die gewone anonimisering niet geeft. Differential privacy kan begrenzen hoeveel de data van één persoon een gepubliceerd resultaat beïnvloedt, terwijl FHE en SMPC andere vormen van cryptografische vertrouwelijkheid bieden.

Kun je trainingsdata uit een machine-learningmodel halen?

Ja. Membership-inferenceaanvallen onthullen of een specifiek record in de trainingsset zat, modelinversie en gradiëntlekkage kunnen records reconstrueren, en grote taalmodellen kunnen trainingsdata onthouden en letterlijk uitspugen. Dit zijn aangetoonde aanvallen die in de securityliteratuur zijn gedocumenteerd, geen hypothetische risico's.

Garandeert het zelf hosten van een model dataprivacy?

Nee. Zelf hosten houdt data op infrastructuur die jij beheert, wat neerkomt op toegangscontrole en datalokalisatie, een echte winst voor het besturen van wie bij de data kan. Het is geen privacybeschermend machine learning en stopt membership inference of lekkage door memorisatie niet. Het combineert goed met PPML-technieken, maar vervangt ze niet.

Welke opensourcetools bestaan er voor privacybeschermend machine learning?

Verschillende opensourcetools dekken verschillende delen van PPML. TensorFlow Federated ondersteunt federated learning en berekeningen over gedecentraliseerde data, TensorFlow Privacy levert hulpmiddelen voor differentially private training, en Concrete ML dekt machine learning met FHE. PySyft richt zich nu op privacybeschermende remote data science, waarbij berekeningen draaien tegen data die de eigenaar beheert en alleen goedgekeurde resultaten worden gedeeld.