🤖 AI

Privacy Preserving Machine Learning Workflow: from Anonymization to Personalized Differential Privacy Budgets in Federated Learning

Dit artikel stelt een uitgebreide privacybehoudende federatiele leerwerkstroom voor voor gevoelige tabulaire gegevens die anonimisering, detectie van client-drift voor vergiftigingsmitigatie en een nieuwe methodologie voor het toewijzen van gepersonaliseerde differentieel-private begrotingen op basis van het risico op heridentificatie integreert, waarbij een superieure modelprestatie wordt aangetoond ten opzichte van vaste-begrotingbenaderingen op medische dossiers.

Oorspronkelijke auteurs: Judith Sáinz-Pardo Díaz, Álvaro López García

Gepubliceerd 2026-05-06

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Judith Sáinz-Pardo Díaz, Álvaro López García

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een groep ziekenhuizen voor, elk in een ander land gevestigd, die een superintelligente AI-arts willen bouwen om te voorspellen hoe ernstig de kanker van een patiënt kan zijn. Ze hebben allemaal waardevolle patiëntgegevens, maar geen van hen kan hun daadwerkelijke patiëntendossiers met elkaar of met een centrale server delen. Waarom? Vanwege strenge privacywetten (zoals de AVG) en de angst dat gevoelige medische geheimen gestolen zouden kunnen worden.

Dit artikel stelt een slimme manier voor om dit probleem op te lossen met behulp van een systeem dat Federated Learning wordt genoemd, gecombineerd met een paar lagen "privacy-magie". Hier is de werkwijze uitgelegd in eenvoudige termen:

1. De Opzet: De "Geheime Recepten"-wedstrijd

Denk aan de centrale server als een wedstrijdjury, en de ziekenhuizen als chefs.

Het Doel: De jury wil het best mogelijke recept creëren (het AI-model) voor het voorspellen van kankerernst.
De Regel: Chefs mogen hun lijst met geheime ingrediënten (patiëntgegevens) niet naar de jury sturen. In plaats daarvan koken ze een klein deel van het recept lokaal, sturen ze alleen de wijzigingen die ze aan het recept hebben aangebracht (de modelupdates) terug, en de jury mengt ze allemaal samen om een beter globaal recept te maken.

2. Stap Eén: Identiteit Verbergen (Anonimisering)

Voordat de chefs zelfs maar beginnen met koken, moeten ze ervoor zorgen dat hun ingrediënten niet tot een specifiek persoon kunnen worden teruggevoerd.

De Analogie: Stel je een chef voor met een lijst van klanten met hun namen, leeftijden en favoriete gerechten. Om hen te beschermen, verwijdert de chef de namen en groepeert de leeftijden in bakken (bijvoorbeeld "30–39 jaar" in plaats van "34").
De Methode van het Artikel: De ziekenhuizen gebruiken een hulpmiddel om hun gegevens te generaliseren, zodat geen enkel individu kan worden geïdentificeerd. Cruciaal is dat het artikel ervoor zorgt dat alle ziekenhuizen hun gegevens op exact dezelfde manier generaliseren (bijvoorbeeld: iedereen gebruikt leeftijdsbakken van 10 jaar), zodat de recepten nog steeds eerlijk kunnen worden vergeleken.

3. Stap Twee: Controleren op "Drinke Chefs" (Client Drift Detectie)

Soms gebruikt een chef per ongeluk de verkeerde ingrediënten, of probeert een kwaadaardige chef het recept opzettelijk te saboteren.

Het Probleem: Als de gegevens van één ziekenhuis totaal verschillen van die van de anderen (misschien gebruiken ze andere apparatuur of hebben ze een andere patiëntenpopulatie), zullen hun receptwijzigingen vreemd lijken. Dit wordt "Client Drift" genoemd.
De Oplossing van het Artikel: De jury kijkt naar de receptwijzigingen voordat ze ze mengen. Als de wijzigingen van een chef wild afwijken van die van iedereen anders (zoals een chef die probeert "chocolade" aan een soetrecept toe te voegen), markeert de jury ze. Dit helpt zowel onbedoelde fouten als kwaadaardige aanvallen te detecteren zonder ooit de daadwerkelijke ingrediënten te zien.

4. Stap Drie: Het "Privacy-Budget" (Differentiële Privacy)

Zelfs als de chefs receptwijzigingen terugsturen, zou een slimme hacker misschien in staat zijn om de oorspronkelijke ingrediënten uit die wijzigingen te reconstrueren. Om dit te voorkomen, voegt het artikel "ruis" (statische storing) toe aan de receptwijzigingen.

De Oude Manier (Globaal Budget): Stel je voor dat de jury precies dezelfde hoeveelheid ruis toevoegt aan elke enkele receptwijziging, ongeacht wie het stuurde. Het is een "one-size-fits-all"-aanpak.
De Nieuwe Manier van het Artikel (Gepersonaliseerde Budgetten): Het artikel stelt een slimmere aanpak voor. Het vraagt: Hoe riskant is het om de gegevens van deze specifieke chef te onthullen?
- Als een ziekenhuis een zeer kleine, unieke groep patiënten heeft, zijn hun gegevens makkelijker te raden. Ze krijgen meer ruis (meer privacybescherming).
- Als een ziekenhuis een enorme, diverse groep patiënten heeft, zijn hun gegevens moeilijker te raden. Ze krijgen minder ruis (minder privacybescherming, wat betekent dat het recept nauwkeuriger blijft).
De Meting: Ze berekenen een "Risicoscore voor Heridentificatie" (ARIREC) voor elk ziekenhuis. Hoe hoger het risico, hoe meer ruis er aan hun bijdrage wordt toegevoegd.

5. De Resultaten: Werkt Het?

De auteurs testten dit systeem met behulp van een nep-dataset van 50.000 kankerpatiëntendossiers, verdeeld over 10 verschillende "landen" (ziekenhuizen). Ze vergeleken drie scenario's:

Standaard Federated Learning: Geen extra privacy-stappen.
Globale Privacy: Dezelfde hoeveelheid ruis toevoegen aan iedereen.
Gepersonaliseerde Privacy: Aangepaste hoeveelheden ruis toevoegen op basis van risico.

De Bevinding:
De aanpak "Gepersonaliseerde Privacy" werkte beter dan de aanpak "Globale Privacy". Door de hoeveelheid ruis af te stemmen op het specifieke risico van elk ziekenhuis, was het uiteindelijke AI-model nauwkeuriger (lagere foutpercentages) terwijl de gegevens van iedereen veilig bleven.

Samenvatting

Dit artikel presenteert een complete werkwijze voor het trainen van AI op gevoelige medische gegevens zonder de gegevens zelf ooit te verplaatsen. Het combineert:

Anonimisering om identiteiten te verbergen.
Drift-detectie om slechte actoren of vreemde gegevens op te sporen.
Gepersonaliseerde Privacy om precies de juiste hoeveelheid "ruis" toe te voegen om elk ziekenhuis te beschermen op basis van hoe kwetsbaar hun gegevens zijn.

Het resultaat is een systeem dat privacy effectief beschermt terwijl het AI-model slim en nauwkeurig blijft.

Technische Samenvatting: Privacybehoudend Machine Learning Workflow

Probleemstelling
De snelle ontwikkeling van kunstmatige intelligentie, met name in gevoelige domeinen zoals de gezondheidszorg, vereist het trainen van modellen op grote datasets terwijl strikte privacyregels zoals de Algemene Verordening Gegevensbescherming (AVG) worden nageleefd. Hoewel Federated Learning (FL) een gedecentraliseerd alternatief biedt voor centraal datatrainen, introduceert het specifieke kwetsbaarheden. Zelfs zonder datacentralisatie blijven FL-architecturen vatbaar voor privacykrenkingen (bijvoorbeeld reconstructie, modelinferentie en lidmaatschapsinferentie-aanvallen) en integriteitsbedreigingen (bijvoorbeeld vergiftigingsaanvallen en client drift). Bovendien passen bestaande benaderingen vaak uniforme privacymaatregelen (zoals een vast globaal differentieel privacy-budget) toe op alle clients, waardoor rekening wordt gehouden met de variërende risico's op heridentificatie die inherent zijn aan verschillende lokale datasets.

Methodologie
Het artikel stelt een uitgebreide workflow voor voor privacybehoudend machine learning op gevoelige tabulaire data, waarbij vier kernfasen worden geïntegreerd:

Data-anonimisering: Voordat federatief trainen plaatsvindt, passen clients lokaal anonimiserings technieken (bijvoorbeeld $k$ -anonymity, $\ell$ -diversiteit) toe op hun tabulaire data. Om compatibiliteit voor modeltraining te waarborgen, coördineert een server een harmonisatieproces waarbij clients hun toegepaste transformatiehiërarchieën uitwisselen. De server bepaalt het maximale hiërarchieniveau dat vereist is om aan de privacybeperkingen van alle clients te voldoen, zodat alle datasets worden gegeneraliseerd naar hetzelfde niveau binnen een latente ruimte.
Detectie van client drift: Om vergiftigingsaanvallen (zowel opzettelijk als onopzettelijk) te mitigeren, definiëren de auteurs "client drift" formeel als een significante verschuiving in de verdeling van de data van een client ten opzichte van het systeem. In plaats van toegang te hebben tot ruwe data, detecteert de server drift door de divergentie tussen modelgewichten te analyseren met behulp van een symmetrische maatstaf gebaseerd op de Frobenius-norm (Vergelijking 2). Clients die een significante divergentie vertonen, kunnen worden uitgesloten van het aggregatieproces.
Differentieel Privacy (DP) met gepersonaliseerde budgetten: De kernbijdrage is een methodologie voor het toewijzen van gepersonaliseerde privacybudgetten.
- Risicomaatstaf: De auteurs definiëren het gemiddelde risico op heridentificatie van equivalentieklassen (ARIREC) voor elke client op basis van hun geanonimiseerde data.
- Toewijzing van budget: Een globale ruisvermenigvuldiger ( $n_\epsilon$ ) wordt vastgesteld. Voor elke client $i$ wordt een gepersonaliseerde ruisvermenigvuldiger ( $n_{\epsilon,i}$ ) berekend door de globale vermenigvuldiger te schalen op basis van de genormaliseerde ARIREC-maatstaf van de client ( $\tilde{A}_i$ ).
- Implementatie: Gaussische ruis wordt toegevoegd aan de lokale modelgewichten van elke client voordat aggregatie plaatsvindt, waarbij de ruismagnitude evenredig is met het specifieke risico op heridentificatie van de client. Dit staat in contrast met Global DP (GDP), waarbij ruis alleen wordt toegevoegd aan de geaggregeerde gewichten.
Federatieve aggregatie: De workflow maakt gebruik van een vertrouwde server om de ruizige gewichten te aggregeren (met behulp van FedAvg) en het globale model bij te werken.

Kernbijdragen

Formele definitie van client drift: Het artikel biedt een formele definitie van client drift in FL en stelt een privacybehoudend detectiemechanisme voor op basis van divergentie van gewichten, waardoor toegang tot ruwe data overbodig wordt.
Gepersonaliseerde privacybudgetten: Het introduceert een methodologie om gepersonaliseerde differentieel privacy-budgetten toe te wijzen op basis van een berekend risico op heridentificatie (ARIREC), wat adaptieve ruisinjectie mogelijk maakt die de specifieke kwetsbaarheid van de dataset van elke client weerspiegelt.
Geïntegreerde workflow: Het artikel beschrijft een complete, reproduceerbare pipeline die anonimiserings, driftdetectie en gepersonaliseerde DP combineert binnen een FL-architectuur.

Experimentele resultaten
De methodologie werd geëvalueerd met behulp van een synthetische dataset van 50.000 medische dossiers voor de voorspelling van kankerernst, gesimuleerd over 10 clients die verschillende landen vertegenwoordigen. De studie vergeleek drie scenario's:

Vanilla FL (geen privacy).
FL met Global DP (vast budget toegevoegd aan geaggregeerde gewichten).
FL met Gepersonaliseerde DP (aangepaste budgetten toegevoegd aan lokale gewichten).

De resultaten gaven aan dat de benadering met Gepersonaliseerde DP betere modelprestaties behaalde dan de benadering met Global DP. Specifiek leverde het scenario met Gepersonaliseerde DP een lagere Mean Absolute Error (MAE: 0,836 versus 0,847) en Mean Relative Error (MRE: 0,177 versus 0,182) op in vergelijking met Global DP, terwijl privacybeschermingen werden gehandhaafd. De auteurs merken op dat hoewel beide DP-methoden de prestaties ten opzichte van Vanilla FL verminderen, de gepersonaliseerde benadering deze achteruitgang minimaliseert door ruis af te stemmen op risiconiveaus.

Betekenis en claims
De auteurs positioneren dit werk als een methodologisch raamwerk in plaats van een definitieve oplossing voor alle real-world scenario's. Zij stellen dat de primaire betekenis ligt in het aantonen dat gepersonaliseerde privacybudgetten, afgeleid van risico's op heridentificatie, de modelnut kunnen verbeteren ten opzichte van vaste globale budgetten in een federatieve setting.

Het artikel stelt expliciet dat de studie een "voorlopig" bewijs van concept is met behulp van een synthetisch, reproduceerbaar gebruiksscenario. Het erkent beperkingen, waarbij wordt opgemerkt dat de huidige implementatie uitgaat van een vertrouwde server en nog geen rigoureuze $\epsilon$ - en $\delta$ -rekening biedt voor de compositie van privacyverlies over rondes heen. De auteurs suggereren dat toekomstig werk zich zal richten op het uitbreiden van deze workflow naar scenario's met een onbetrouwbare server (potentieel met behulp van homomorf versleuteling) en niet-IID client-distributies.