Hvad er privatlivsbevarende machine learning?

Et team beslutter at køre en sprogmodel på sine egne servere i stedet for at kalde et eksternt API. Motivationen er privatliv: hold de følsomme data internt, og giv dem aldrig til tredjepart. Instinktet er rigtigt, og den kontrol det giver, er reel, men den er også ufuldstændig. En model, der er trænet på private journaler, kan bringes til at afsløre, om en bestemt persons journal indgik i træningssættet. Federated opdateringer, der aldrig bærer rådata, kan regnes tilbage til de billeder, der frembragte dem. En stor model kan huske og udsende stumper af det, den blev trænet på. Data blev hjemme, og modellen lækkede alligevel.

Netop det gab, mellem at føles privat og at være beviseligt privat, er det, privatlivsbevarende machine learning tager fat på. Den almindelige ML-pipeline kræver, at rådata er tilgængelige for træningsinfrastrukturen, og det støder sammen med privatlivslovgivning, med krav om datasuverænitet og med partnere, der slet ikke vil dele deres datasæt. Privatlivsbevarende machine learning er den familie af teknikker, der løser det sammenstød.

Den nyttige skelnen går mellem teknikker, der reducerer dataflytning, teknikker, der afgrænser, hvad output kan afsløre, og teknikker, der holder data fortrolige under beregningen. Selv-hosting står ved siden af disse kontroller, ikke i stedet for dem.

Den korte version

• Privatlivsbevarende machine learning (PPML) er en paraplykategori, ikke én metode. Denne artikel fokuserer på fire hovedtilgange: federated learning, differential privacy, homomorf kryptering og secure multi-party computation. Andre privatlivsstyrkende arkitekturer, herunder trusted execution environments, kan også indgå i PPML-systemer.
• Federated learning alene giver ingen formel privatlivsgaranti. Den holder rådata ved kilden, men delte gradient-opdateringer kan nogle gange regnes tilbage til træningsposter. Differential privacy er en udbredt måde at tilføje en formel lækagegrænse på.
• Styrken af differential privacy opsummeres normalt med epsilon. Garantien afhænger også af delta, af den beskyttede enhed og af metoden til privacy accounting. En formel garanti med svage parametre er stadig en garanti på papiret og teater i praksis.
• Homomorf kryptering er ægte og langsom. At regne på krypterede data virker, men overhead begrænser det i dag til simplere modeller, latenstolerant inferens og eksperimentelle fine-tuning-workflows, ikke til almindelig træning af store modeller eller fuld pretraining.
• At selv-hoste en model er datalokalisering, ikke PPML. At holde data på infrastruktur, du styrer, afgør, hvem der kan nå dem. Det afgør ikke, hvad modellen selv kan afsløre.

Note om omfang: dette er en begrebsmæssig gennemgang, ikke en implementeringsguide. Den dækker ikke library-opsætning, valg af epsilon, regulatorisk compliance eller privat fine-tuning af LLM'er i dybden. Målet her er kortet. Sving-for-sving-anvisningerne hører hjemme i dedikerede implementeringsguides.

Sådan beskytter privatlivsbevarende machine learning data

Privatlivsbevarende machine learning er en samlebetegnelse for metoder, der reducerer, begrænser eller formelt afgrænser informationseksponering på tværs af modeltræning, inferens og fælles analyse. Denne artikel fokuserer på fire hovedtilgange: federated learning, differential privacy, homomorf kryptering og secure multi-party computation. De beskytter forskellige aktiver under forskellige trusselsmodeller og bør derfor ikke behandles som ombyttelige garantier.

Problemet er enkelt: standard-ML-pipelines antager typisk, at træningsprocessen kan tilgå rå poster, mens privatlivslovgivning, krav om datasuverænitet og partneraftaler ofte forhindrer netop den adgang. De fire familier svarer forskelligt på den begrænsning: flyt beregningen hen til data i stedet for at flytte data hen til beregningen (federated learning), tilføj kalibreret støj, så output afslører mindre om en enkelt person (differential privacy), regn på data, der forbliver krypterede (homomorf kryptering), eller lad flere parter beregne et resultat sammen uden at vise hinanden deres rå input (secure multi-party computation).

Den underliggende risiko står klart formuleret i Googles vejledning om ansvarlig AI: machine learning-modeller kan huske eller afsløre aspekter af de data, de har været udsat for, og privatlivsarbejde findes for at sætte værn omkring netop det. PPML adresserer den risiko og adskiller sig fra almindelig anonymisering, af grunde som næste afsnit gør konkrete.

Hvorfor er anonymisering ikke nok?

Anonymiserede data kan stadig re-identificeres. At fjerne navne og åbenlyse identifikatorer fra et datasæt reducerer den synlige eksponering, men garanterer ikke privatliv, så snart data kan kobles med information udefra. Det er den tilbagevendende svaghed ved de-identifikationstilgange som k-anonymitet: de kan sænke identificerbarheden under bestemte antagelser, men de giver ikke de formelle garantier, man får fra teknikker som differential privacy eller kryptografiske PPML-metoder.

Denne praktiske skelnen betyder noget for enhver, der har fået at vide: "vi har anonymiseret det, så vi er fine." Anonymisering er en påstand om et datasæt i en bestemt kontekst og trusselsmodel. Et linkage-angreb behøver hverken at bryde kryptering eller omgå adgangskontrol. Det behøver kun et andet datasæt, der overlapper dit. Den pointe fremsættes direkte i NIST's vejledning om de-identifikation, som bemærker, at de-identificerede data stadig kan re-identificeres ved at koble dem med hjælpedatasæt.

Differential privacy giver noget, som almindelig de-identifikation ikke giver: en matematisk grænse for, hvor meget én persons data kan påvirke et offentliggjort resultat, under en defineret privatlivsenhed og trusselsmodel. Homomorf kryptering og SMPC giver andre former for kryptografisk fortrolighed, mens federated learning først og fremmest ændrer, hvor data behandles. Garantierne er beslægtede, men de er ikke de samme.

Hvordan virker federated learning, og hvorfor er det ikke nok alene?

I federated learning sendes en global model ud til lokale enheder eller servere, træner på de data, der ligger der, og returnerer kun sine parameteropdateringer til centret. Rådata flytter sig aldrig. Det er et reelt nyttigt mønster, og det kører i produktion i stor skala. Det er i sig selv heller ikke en privatlivsgaranti.

Mekanismen er model-til-data frem for data-til-model. Googles Gboard-udrulning kører over 30 sprogmodeller direkte på enheden, på over 7 sprog og i over 15 lande, og træner på tekst, der aldrig forlader telefonen. Det er federated learning, der virker som lovet: tastaturet bliver bedre, uden at Google indsamler det, du skrev.

Problemet er, hvad der rejser med i opdateringerne. Gradienter bærer information om de data, der frembragte dem, og den information kan genskabes. Zhu, Liu og Han viste det i Deep Leakage from Gradients (NeurIPS 2019), hvor de demonstrerede gradient inversion-angreb, der genskaber private træningseksempler ud fra delte modelopdateringer, i deres eksperimenter med pixelnøjagtig billedgenskabelse og tokenpræcis match for tekst. Federated learning reducerede dataflytning. Det fjernede ikke lækagerisikoen.

Hvis målet er at afgrænse, hvad deltagelsen kan afsløre, er differential privacy en udbredt tilføjelse. Secure aggregation adresserer en anden risiko ved at skjule de enkelte klienters opdateringer for den koordinerende server. Gboard kombinerer federated learning med formel differential privacy i stedet for at læne sig op ad federering alene.

Bemærk: Federated learning beskrives ofte som "privat", fordi rådata bliver ved kilden. Den beskrivelse er vildledende. Uden yderligere beskyttelse kan federated opdateringer bære signal nok til at rekonstruere træningsposter. DP-FL tilføjer en formel differential privacy-garanti i stedet for at læne sig op ad federering alene. Federering i sig selv er et valg om datahåndtering, ikke et privatlivsbevis.

Hvad er differential privacy, og hvad styrer epsilon egentlig?

Differential privacy er en matematisk definition, der afgrænser, hvor meget en analyse kan ændre sig, når én privatlivsenhed tilføjes eller fjernes. Mange mekanismer opnår den garanti ved at tilføje kalibreret tilfældighed. Epsilon er én synlig parameter, men en meningsfuld garanti afhænger også af privatlivsenheden, af DP-varianten og eventuelle ekstra parametre som delta, plus komposition, accounting og implementeringsdetaljer.

Epsilon beskrives som privatlivsbudgettet i NVIDIA's ordliste: lavere værdier betyder stærkere privatliv, men mere støj; højere værdier bevarer nøjagtigheden på bekostning af svagere garantier. En udbredt måde at anvende differential privacy under deep learning-træning er DP-SGD, differentially private stochastic gradient descent: klip hver enkelt prøves gradient til en begrænset størrelse, tilføj kalibreret gaussisk støj, og aggregér så. Klipningen begrænser, hvor meget ét enkelt eksempel kan påvirke modellen. Støjen slører den påvirkning, der er tilbage.

Det budget bliver brugt op. Mekanismen beskrives i Tumult Analytics' dokumentation om privatlivsbudgetter: hver forespørgsel mod et beskyttet datasæt bruger en del af privatlivsbudgettet. Hvordan de forbrug lægger sig sammen, er standardteori for differential privacy, fremlagt i The Algorithmic Foundations of Differential Privacy af Dwork og Roth: under basal komposition summerer k forespørgsler, hver med parameteren epsilon, til et samlet privatlivstab på k gange epsilon, og avancerede kompositionssætninger giver strammere grænser. Du får ikke ubegrænsede spørgsmål. Du får et budget, og du bruger af det.

Parametervalgene afgør derfor, om garantien betyder noget i praksis. En peer-reviewed kritik af privatlivstilgange i machine learning argumenterer for, at den matematiske indramning kan give en "objektiv fernis", som bruges til at hvidvaske et projekt. Sæt privatlivsparametrene svagt nok, og garantien kan blive nærmest meningsløs, mens et team stadig kan hævde, at det opfyldte differential privacy. Garantien er ægte. Dens praktiske styrke er et designvalg.

Bemærk: En differential privacy-garanti er kun meningsfuld, når du kender privatlivsparametrene og den enhed, de beskytter. Et meget højt epsilon, et løst delta eller uklar accounting kan gøre, at en teknisk gyldig garanti giver ganske lidt beskyttelse i praksis. At læse "dette system bruger differential privacy" siger næsten intet i sig selv: betydningen ligger i privatlivsparametrene, hvad de er målt over, og hvordan de sammensættes. Konkrete deployments gør det håndgribeligt. Google rapporterer et epsilon på 1 på brugerniveau for sit Provably Private Insights-system, men det er ét deployments valg til ét use case, ikke et tal at kopiere.

Hvordan regner homomorf kryptering på data, den aldrig dekrypterer?

Fuldt homomorf kryptering (FHE) lader en server køre beregninger direkte på krypterede data og returnere et krypteret resultat, som kun dataejeren kan dekryptere. Serveren udfører arbejdet uden nogensinde at se klarteksten. Det er et af feltets stærkeste privatlivsværktøjer, men prisen er ydeevne.

Den nyttige analogi er en aflåst handskeboks med indbyggede handsker: en medarbejder kan række ind og manipulere indholdet uden nogensinde at åbne boksen eller tage indholdet ud. Dataejeren har den eneste nøgle. Beregningen sker på det forseglede indhold, og kun ejeren kan åbne boksen og læse resultatet. Det er, hvad FHE gør matematisk: operere på ciffertekst, sådan at dekryptering af output giver samme svar, som beregning på klarteksten ville have givet.

Hagen er omkostningen. Concrete ML fra Zama konverterer scikit-learn- og PyTorch-modeller til FHE-kompatible ækvivalenter, uden at brugeren skal arbejde direkte med kryptografiske primitiver, og version v1.9 udkom den 10. april 2025. Men projektets egne benchmarks viser overhead: et CIFAR10-billedklassifikationsnetværk kører under FHE på cirka 4 minutter pr. billede. Det er fint til noget latenstolerant inferens, til simplere modeller og til eksperimentel krypteret fine-tuning. Det er stadig ikke en praktisk vej til fuld pretraining af store modeller eller til almindelige træningsworkloads. FHE er i dag et præcisionsinstrument til et smalt sæt opgaver, ikke et alment privatlivslag.

Hvad er secure multi-party computation i machine learning?

Secure multi-party computation (SMPC) lader flere parter i fællesskab beregne en funktion over deres samlede private input, uden at nogen part ser de andres rådata. Hver parts input forbliver hemmeligt. Kun det aftalte resultat bliver kendt. SMPC kan bygges med teknikker som secret sharing, garbled circuits, oblivious transfer og kombinationer heraf. I secret sharing-protokoller opdeles private værdier i andele, så en enkelt andel ikke afslører inputtet. Garbled circuit-protokoller virker anderledes: de indkoder en beregning, så parterne kan evaluere den uden at afsløre deres private input.

Det naturlige use case er samarbejde på tværs af organisationer. Flere hospitaler vil træne en model på deres samlede patientdata, men ingen af dem må lovligt dele journaler med de andre. SMPC lader dem beregne den fælles model, som om data var lagt sammen, mens hvert hospitals journaler forbliver forseglede hos hospitalet. SMPC-overhead afhænger i høj grad af protokollen, sikkerhedsmodellen, netværksforholdene, antallet af parter og den funktion, der evalueres. Mange protokoller er kommunikationstunge, så ydeevne skal måles mod det konkrete samarbejde frem for rangeres generisk mod differential privacy eller FHE. Netop det mønster for machine learning i sundhedsvæsenet behandles i en oversigtsartikel fra 2025 i WIREs Computational Statistics.

Kan en machine learning-model lække sine træningsdata?

Ja. En trænet model kan forråde sine træningsdata på flere forskellige måder: membership inference afslører, om en bestemt post var i træningssættet, modelinversion og gradientlækage kan rekonstruere poster, og store sprogmodeller kan huske og udsende stumper af deres træningsdata ordret. Det er ikke hypoteser. Det er demonstrerede angreb, og de er grunden til, at teknikkerne ovenfor findes.

Det grundlæggende resultat er membership inference. Shokri og kolleger viste i Membership Inference Attacks Against Machine Learning Models (IEEE S&P 2017), at en angriber, der observerer en models forudsigelsesadfærd, kan afgøre, om en given post var en del af træningssættet. Det lyder abstrakt, indtil træningssættet er "patienter med en bestemt diagnose". Så er medlemskabet selv det følsomme faktum. Modelinversion og de tidligere omtalte gradientlækage-angreb udvider dette fra "var denne post til stede" til "rekonstruér posten".

Fronten er store sprogmodeller, og det er der, ældre PPML-rammeværker passer dårligst. Forskning i LLM'er, der udsender træningsdata dokumenterer, at store modeller husker dele af deres træningskorpus og kan lokkes til at gengive det, hvor udtrækningsangreb genskaber ordrette og næsten ordrette træningsdata. DP-SGD kan anvendes til privat fine-tuning, men omkostningen i nøjagtighed og compute i stor modelskala er hård, hvilket er en del af grunden til, at Apples PPML-workshop i 2026 kørte et helt spor om foundation-modeller og privatliv. De forsvar, der virker rent for en logistisk regressionsklassifikator, overføres ikke gratis til en model med milliarder af parametre.

PPML og selv-hostet AI: hvad lokal inferens giver dig, og hvad den ikke gør

At selv-hoste en model holder dine data på infrastruktur, du styrer. Det er en reel gevinst for adgangskontrol og datalokalisering: data rejser ikke til tredjepart, og du bestemmer, hvem der kan nå den maskine, den kører på. Men det er ikke privatlivsbevarende machine learning. Lokal inferens gør i sig selv intet for at stoppe membership inference mod modellen, og den forhindrer ikke en model i at afsløre, hvad den har husket.

De to løser hver sin halvdel af problemet, og at blande dem sammen er en udbredt fejl på området. Datalokalisering styrer, hvem der kan nå data: et perimeterspørgsmål, besvaret af, hvor bytes ligger, og hvem der har nøglerne til rummet. PPML styrer, hvad modellen selv kan afsløre, et spørgsmål om informationslækage, besvaret af de fire teknikker ovenfor. At køre en model på sin egen server er et stærkt svar på det første spørgsmål og slet intet svar på det andet.

Hvis det, du vejer, er, om du overhovedet skal køre modellen selv, er omkostningssiden af den beslutning en analyse for sig: se At selvhoste en open-weight LLM vs. et API: Den reelle omkostningsmatematik.

For en platform- eller infrastrukturingeniør lyder den operationelle læsning sådan: "det kører på vores egen server" kan opfylde nogle krav om datalokalisering og adgangskontrol, men det begrænser ikke i sig selv, hvad modellen kan afsløre. Hvis modellen eller dens output nogensinde deles, hvad enten det er på tværs af teams, med partnere eller i et produkt, følger den perimeter, du byggede om hardwaren, ikke med modellen ud ad døren. De arkitekturvalg, der faktisk rykker garantien, er PPML-valgene: differential privacy på det output, du udgiver, DP-FL til træning på tværs af lokationer, du ikke kan centralisere, krypteringsbaseret beregning der, hvor data ikke må eksponeres end ikke for din egen infrastruktur. Googles Provably Private Insights-deployment er lærerigt netop fordi det kombinerer flere kontroller, nemlig differential privacy, trusted execution environments og fortrolig federated analytics, frem for at læne sig op ad én af dem. Lokalisering er en del af en rigtig arkitektur. Den er ikke hele arkitekturen.

Hvornår skal du bruge hvilken PPML-teknik?

Udvælgelseslogikken følger begrænsningen, ikke moden. Brug federated learning, når data ikke kan centraliseres. Brug differential privacy, når du har brug for en formel garanti for, hvad modellen afslører. Brug homomorf kryptering, når beregningen skal ske på data, der aldrig dekrypteres, og latensen tillader det. Brug secure multi-party computation, når flere parter skal regne sammen uden at dele deres input.

Teknikkerne kan også kombineres. DP-FL er det tydeligste eksempel: vælg kontrollerne efter de garantier, systemet har brug for, i stedet for at presse problemet ind i én teknik.

Afvejningerne i overblik:

Disse karakteristikker stammer fra en IoT-fokuseret PPML-oversigt fra marts 2026, fra Zamas Concrete ML-benchmarks og fra litteraturen om re-identifikation.

Tabellen er kun et udgangspunkt. Virkelige systemer kombinerer ofte teknikker: et træningsproblem på tværs af lokationer, der også kræver en formel privatlivsgaranti, er som regel et DP-FL-problem, ikke et valg mellem federated learning og differential privacy. Den, der vil strukturere beslutningen mere stringent, kan arbejde sig igennem det strukturerede beslutningsstøtteframework for udviklere , der blev udgivet i slutningen af 2024.

Hvad angår værktøjer, giver TensorFlow Federated et open source-framework til federated learning og beregninger på decentraliserede data. TensorFlow Privacy leverer værktøjer til differentielt privat træning, Googles Differential Privacy-biblioteker dækker differentielt privat statistik og aggregering, og Concrete ML leverer FHE-vejen. PySyft fokuserer nu bredere på privatlivsbevarende remote data science, hvor beregninger kører mod data, ejeren beholder, og kun godkendte resultater deles. Det er navnene, og det er, hvad de gør. Opsætningen hører til i dedikerede implementeringsguides, ikke her. Den tilbagevendende lære er, at matematikken kan holde, mens implementeringen alligevel fejler. Garantien betyder kun noget, hvis systemet er designet omkring den rigtige trusselsmodel, og privatlivsparametrene matcher den risiko, der beskyttes.

Ofte stillede spørgsmål

Hvad betyder PPML?

Privatlivsbevarende machine learning er en samlebetegnelse for metoder, der reducerer, begrænser eller formelt afgrænser informationseksponering under machine learning. De væsentligste tilgange omfatter federated learning, differential privacy, homomorf kryptering og secure multi-party computation, men de beskytter forskellige aktiver og giver forskellige slags garantier.

Er federated learning nok til at beskytte privatlivet?

Nej. Federated learning holder rådata ved kilden, men de parameteropdateringer, den deler, kan via gradient inversion-angreb regnes tilbage til træningsposter. Alene giver den ingen formel privatlivsgaranti. Differential privacy kan tilføje en formel lækagegrænse, hvilket giver den kombination, man normalt kalder DP-FL.

Hvilken epsilon-værdi skal jeg bruge til differential privacy?

Der findes ingen universel værdi. Epsilon er en af hovedparametrene i afvejningen mellem privatliv og nøjagtighed: lavere værdier betyder som regel stærkere privatliv og mere støj, mens højere værdier som regel betyder svagere privatliv og mindre støj. Den rigtige indstilling afhænger af datas følsomhed og af den risiko, du kan acceptere. Der er ingen universel grænse, der gør en epsilon-værdi "sikker". Vurdér epsilon sammen med privatlivsenheden, DP-varianten og eventuelle ekstra parametre som delta, kompositionsmetoden og systemets trusselsmodel.

Hvad er forskellen på PPML og anonymisering?

Anonymisering fjerner identifikatorer fra et datasæt, men anonymiserede poster kan re-identificeres ved at koble dem til hjælpedata fra andre kilder. Nogle PPML-teknikker giver formelle garantier, som almindelig anonymisering ikke gør. Differential privacy kan afgrænse, hvor meget én persons data påvirker et offentliggjort resultat, mens FHE og SMPC giver andre former for kryptografisk fortrolighed.

Kan man udtrække træningsdata fra en machine learning-model?

Ja. Membership inference-angreb afslører, om en bestemt post var i træningssættet, modelinversion og gradientlækage kan rekonstruere poster, og store sprogmodeller kan huske og udsende træningsdata ordret. Det er demonstrerede angreb dokumenteret i sikkerhedslitteraturen, ikke hypotetiske risici.

Garanterer selv-hosting af en model dataprivatliv?

Nej. Selv-hosting holder data på infrastruktur, du styrer, hvilket er adgangskontrol og datalokalisering, en reel gevinst for at styre, hvem der kan nå data. Det er ikke privatlivsbevarende machine learning og stopper hverken membership inference eller lækage fra memorisering. Det spiller godt sammen med PPML-teknikker, men erstatter dem ikke.

Hvilke open source-værktøjer findes der til privatlivsbevarende machine learning?

Flere open source-værktøjer dækker forskellige dele af PPML. TensorFlow Federated understøtter federated learning og beregninger på decentraliserede data, TensorFlow Privacy leverer værktøjer til differentielt privat træning, og Concrete ML dækker machine learning med FHE. PySyft fokuserer nu på privatlivsbevarende remote data science, hvor beregninger kører mod data, som ejeren kontrollerer, og kun godkendte resultater deles.